[PATCH v2 00/15] vfs: add the ability to retry on ESTALE to several syscalls

[Jeff Layton]

This patchset is the second version of the patchset to add ESTALE
handling to several syscalls. The previous version is here:

    http://lwn.net/Articles/496103/

I spoke with Al Viro about my previous set and he pointed out something
I had not considered. getname() has side effects when auditing is
enabled, so if we end up calling it multiple times for the same names,
we'll make a mess of the audit handling.

This patchset is a revised version that should fix that by ensuring that
we only call getname() once per __user path, per syscall. In order to do
that, I had to break up some of the nice user_path_* wrappers.

I've tried to keep this patchset pretty granular. Some of these patches
could be combined if that's desirable. It's probably too late for 3.5
here, but I'd like to see this considered for 3.6 if possible.

Jeff Layton (15):
  vfs: add a retry_estale helper function to handle retries on ESTALE
  vfs: add a kern_path_at function
  vfs: make fstatat retry on ESTALE errors from getattr call
  vfs: fix readlinkat to retry on ESTALE
  vfs: remove user_path_at_empty
  vfs: turn "empty" arg in getname_flags into a bool
  vfs: add new "reval" argument to kern_path_create
  vfs: fix mknodat to retry on ESTALE errors
  vfs: fix mkdir to retry on ESTALE errors
  vfs: fix symlinkat to retry on ESTALE errors
  vfs: fix linkat to retry on ESTALE errors
  vfs: make rmdir retry on ESTALE errors
  vfs: make do_unlinkat retry on ESTALE errors
  vfs: fix renameat to retry on ESTALE errors
  vfs: remove user_path_parent

 drivers/base/devtmpfs.c |    7 +-
 fs/namei.c              |  407 ++++++++++++++++++++++++++++-------------------
 fs/stat.c               |   44 ++++--
 include/linux/fs.h      |   24 +++-
 include/linux/namei.h   |    4 +-
 net/unix/af_unix.c      |    3 +-
 6 files changed, 310 insertions(+), 179 deletions(-)

-- 
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/