kernel.git/fs/nfs/dir.c, branch linux-3.3.y

switch ->mknod() to umode_t

2012-01-04T03:54:54Z

Signed-off-by: Al Viro

switch ->create() to umode_t

2012-01-04T03:54:53Z

vfs_create() ignores everything outside of 16bit subset of its mode argument; switching it to umode_t is obviously equivalent and it's the only caller of the method Signed-off-by: Al Viro

switch vfs_mkdir() and ->mkdir() to umode_t

2012-01-04T03:54:53Z

vfs_mkdir() gets int, but immediately drops everything that might not fit into umode_t and that's the only caller of ->mkdir()... Signed-off-by: Al Viro

pull manipulations of rpc_cred inside alloc_nfs_open_context()

2012-01-04T03:52:34Z

No need to duplicate them in both callers; make it return ERR_PTR(-ENOMEM) on allocation failure instead of NULL and it'll be able to report rpc_lookup_cred() failures just fine. Callers are much happier that way... Signed-off-by: Al Viro

nfs: when attempting to open a directory, fall back on normal lookup (try #5)

2011-11-04T20:39:04Z

commit d953126 changed how nfs_atomic_lookup handles an -EISDIR return from an OPEN call. Prior to that patch, that caused the client to fall back to doing a normal lookup. When that patch went in, the code began returning that error to userspace. The d_revalidate codepath however never had the corresponding change, so it was still possible to end up with a NULL ctx->state pointer after that. That patch caused a regression. When we attempt to open a directory that does not have a cached dentry, that open now errors out with EISDIR. If you attempt the same open with a cached dentry, it will succeed. Fix this by reverting the change in nfs_atomic_lookup and allowing attempts to open directories to fall back to a normal lookup Also, add a NFSv4-specific f_ops->open routine that just returns -ENOTDIR. This should never be called if things are working properly, but if it ever is, then the dprintk may help in debugging. To facilitate this, a new file_operations field is also added to the nfs_rpc_ops struct. Cc: stable@kernel.org Signed-off-by: Jeff Layton Signed-off-by: Trond Myklebust

Additional readdir cookie loop information

2011-07-30T18:37:14Z

Print out the name of the file that triggers the cookie loop message to make it slightly easier to track down the cause. Signed-off-by: Bryan Schumaker Signed-off-by: Trond Myklebust

NFS: Fix spurious readdir cookie loop messages

2011-07-30T18:34:50Z

If the directory contents change, then we have to accept that the file->f_pos value may shrink if we do a 'search-by-cookie'. In that case, we should turn off the loop detection and let the NFS client try to recover. The patch also fixes a second loop detection bug by ensuring that after turning on the ctx->duped flag, we read at least one new cookie into ctx->dir_cookie before attempting to match with ctx->dup_cookie. Reported-by: Petr Vandrovec Cc: stable@kernel.org [2.6.39+] Signed-off-by: Trond Myklebust

fs: push i_mutex and filemap_write_and_wait down into ->fsync() handlers

2011-07-21T00:47:59Z

Btrfs needs to be able to control how filemap_write_and_wait_range() is called in fsync to make it less of a painful operation, so push down taking i_mutex and the calling of filemap_write_and_wait() down into the ->fsync() handlers. Some file systems can drop taking the i_mutex altogether it seems, like ext3 and ocfs2. For correctness sake I just pushed everything down in all cases to make sure that we keep the current behavior the same for everybody, and then each individual fs maintainer can make up their mind about what to do from there. Thanks, Acked-by: Jan Kara Signed-off-by: Josef Bacik Signed-off-by: Al Viro

nfs: LOOKUP_{OPEN,CREATE,EXCL} is set only on the last step

2011-07-20T05:44:02Z

Signed-off-by: Al Viro

no need to check for LOOKUP_OPEN in ->create() instances

2011-07-20T05:43:56Z

... it will be set in nd->flag for all cases with non-NULL nd (i.e. when called from do_last()). Signed-off-by: Al Viro