[PATCH 00/11] atomic open related fixes

[Miklos Szeredi]

Found an atomic open related fix in the 9p tree (b6f4bee02f); tured out, it
didn't fully fix 9p and introduced another bug in the process and also several
other filesystems are affected by the same bug.  Then I reviewed all the atomic
open implementations and found more bugs.  This series tries to address these.

Only tested the fuse fix, the others are compile tested only.

One issue that crops up several times, and which is not strictly related to
atomic open, is that a non-NULL return value of d_splice_alias() (or ->lookup(),
etc..)  are not handled properly by filesystems.  The reason for this is that a
non-NULL return gets very little testing (only if exported and even then not
easy to trigger).  There should be some way to more easily expose such bugs or
improve the API so that these bugs are harder to introduce.

Thanks,
Miklos

---
Miklos Szeredi (11):
      vfs: improve i_op->atomic_open() documentation
      9p: fix dentry leak in v9fs_vfs_atomic_open_dotl()
      9p: fix O_EXCL in v9fs_vfs_atomic_open()
      fuse: fix O_EXCL in fuse_atomic_open()
      cifs: fix filp leak in cifs_atomic_open()
      gfs2: d_splice_alias() cant return error
      gfs2: pass correct dentry to finish_open() in __gfs2_lookup()
      gfs2: fix dentry leaks
      gfs2: set FILE_CREATED
      nfs: set FILE_CREATED
      vfs: don't set FILE_CREATED before calling ->atomic_open()

---
 Documentation/filesystems/vfs.txt | 14 +++++++-------
 fs/9p/vfs_inode.c                 |  9 ++++++++-
 fs/9p/vfs_inode_dotl.c            |  9 +++++----
 fs/cifs/dir.c                     |  1 +
 fs/fuse/dir.c                     | 10 +++++++++-
 fs/gfs2/inode.c                   | 40 ++++++++++++++++++++++-----------------
 fs/namei.c                        | 11 ++++++++---
 fs/nfs/dir.c                      |  3 +++
 fs/open.c                         | 21 +++++++++++++++++---
 9 files changed, 82 insertions(+), 36 deletions(-)

--
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/