[linux-cifs-client] [PATCH] cifs: disable serverino if server doesn't support it

[Jeff Layton]

On Thu, 23 Jul 2009 09:36:12 +0530
Suresh Jayaraman <sjayaraman at suse.de> wrote:

> Steve French wrote:
> > Makes sense - not a new problem, but important to get in before 2.6.31
> > (as you say with the new default)
> > 
> > On Wed, Jul 22, 2009 at 2:08 PM, Jeff Layton<jlayton at redhat.com> wrote:
> >> A recent regression when dealing with older servers. This bug was
> >> introduced when we made serverino the default...
> >>
> >> When the server can't provide inode numbers, disable it for the mount.
> 
> Sorry for chiming in late..
> 
> >> Signed-off-by: Jeff Layton <jlayton at redhat.com>
> >> ---
> >> �fs/cifs/inode.c | � �5 ++++-
> >> �1 files changed, 4 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
> >> index 2680a5b..b93bf00 100644
> >> --- a/fs/cifs/inode.c
> >> +++ b/fs/cifs/inode.c
> >> @@ -513,9 +513,12 @@ int cifs_get_inode_info(struct inode **pinode,
> >> � � � � � � � � � � � � � � � � � � � �cifs_sb->mnt_cifs_flags &
> >> � � � � � � � � � � � � � � � � � � � � � � � �CIFS_MOUNT_MAP_SPECIAL_CHR);
> >> � � � � � � � � � � � �if (rc1) {
> >> - � � � � � � � � � � � � � � � /* BB EOPNOSUPP disable SERVER_INUM? */
> >> � � � � � � � � � � � � � � � �cFYI(1, ("GetSrvInodeNum rc %d", rc1));
> >> � � � � � � � � � � � � � � � �fattr.cf_uniqueid = iunique(sb, ROOT_I);
> >> + � � � � � � � � � � � � � � � /* disable serverino if call not supported */
> >> + � � � � � � � � � � � � � � � if (rc1 == -EINVAL)
> 
> What is the expected error code if server is not supporting/providing
> inode numbers - -EINVAL or -EOPNOTSUPP?
> Because, we seem to use -EOPNOTSUPP in is_path_accessible(), perhaps we
> need to fix there too?
> 

It really depends on what the server returns in that situation and how
the function handles it. In this case, the server (win98se) returned an
error that translated to -EINVAL (I suppose because it didn't recognize
the infolevel).

That said, all of this "try a call and then fall back" stuff is so
ad-hoc at the moment. It could really use a fundamental rethink.

-- 
Jeff Layton <jlayton at redhat.com>