[git pull] vfs part 3

[git pull] vfs part 3

[Al Viro]

	->direct_IO() changes from Omar + saner generic_write_checks() +
dealing with fcntl()/{read,write}() races (mirroring O_APPEND/O_DIRECT
into iocb->ki_flags and instead of repeatedly looking at ->f_flags, which
can be changed by fcntl(2), check ->ki_flags - which cannot) + infrastructure
bits for dhowells' d_inode annotations + Christophs switch of /dev/loop to
vfs_iter_write().

	That leaves only the actual d_inode annotations series out of the
stuff already in for-next; there are several piles of stuff from various
folks I'm going to add there tonight, leave it all to stew until the middle
of the next week or so and send the final pull request then.  I hoped to do
that last bit on Monday, but since there won't be -next on Thursday and
Friday, this will probably have to happen a couple of days later ;-/

	Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus

Shortlog:
Al Viro (17):
      new_sync_write(): discard ->ki_pos unless the return value is positive
      ntfs: move iov_iter_truncate() closer to generic_write_checks()
      cifs: fold cifs_iovec_write() into the only caller
      __generic_file_write_iter: keep ->ki_pos and return value consistent
      lift generic_write_checks() into callers of __generic_file_write_iter()
      blkdev_write_iter: expand generic_file_checks() call in there
      generic_write_checks(): drop isblk argument
      xfs_file_aio_write_checks: switch to iocb/iov_iter
      ext4_file_write_iter: move generic_write_checks() up
      fuse: ->direct_IO() doesn't need generic_write_checks()
      udf_file_write_iter: reorder and simplify
      ocfs2_file_write_iter: stop messing with ppos
      ocfs2: move generic_write_checks() before the alignment checks
      switch generic_write_checks() to iocb and iter
      mirror O_APPEND and O_DIRECT into iocb->ki_flags
      ocfs2: use __generic_file_write_iter()
      nfs: generic_write_checks() shouldn't be done on swapout...

Christoph Hellwig (1):
      block: loop: switch to VFS ITER_BVEC

David Howells (7):
      VFS: Add owner-filesystem positive/negative dentry checks
      VFS: Impose ordering on accesses of d_inode and d_flags
      NFS: Don't use d_inode as a variable name
      VFS: Combine inode checks with d_is_negative() and d_is_positive() in pathwalk
      VFS: Fix up debugfs to use d_is_dir() in place of S_ISDIR()
      VFS: Make pathwalk use d_is_reg() rather than S_ISREG()
      configfs: Fix inconsistent use of file_inode() vs file->f_path.dentry->d_inode

Omar Sandoval (5):
      new helper: iov_iter_rw()
      Remove rw from {,__,do_}blockdev_direct_IO()
      Remove rw from dax_{do_,}io()
      direct_IO: use iov_iter_rw() instead of rw everywhere
      direct_IO: remove rw from a_ops->direct_IO()

Diffstat:
 Documentation/filesystems/Locking          |   2 +-
 Documentation/filesystems/vfs.txt          |   2 +-
 drivers/block/loop.c                       | 294 ++++++++++++-----------------
 drivers/staging/lustre/lustre/llite/rw26.c |  22 +--
 fs/9p/vfs_addr.c                           |   5 +-
 fs/9p/vfs_file.c                           |  26 +--
 fs/affs/file.c                             |   9 +-
 fs/aio.c                                   |   2 +-
 fs/block_dev.c                             |  21 ++-
 fs/btrfs/file.c                            |  26 +--
 fs/btrfs/inode.c                           |  22 +--
 fs/ceph/addr.c                             |   3 +-
 fs/ceph/file.c                             |  22 +--
 fs/cifs/file.c                             |  93 ++++-----
 fs/configfs/dir.c                          |   2 +-
 fs/dax.c                                   |  27 ++-
 fs/dcache.c                                |  47 ++++-
 fs/debugfs/inode.c                         |   2 +-
 fs/direct-io.c                             |  39 ++--
 fs/exofs/inode.c                           |   4 +-
 fs/ext2/inode.c                            |  11 +-
 fs/ext3/inode.c                            |  14 +-
 fs/ext4/ext4.h                             |   4 +-
 fs/ext4/file.c                             |  33 ++--
 fs/ext4/indirect.c                         |  25 +--
 fs/ext4/inode.c                            |  28 +--
 fs/f2fs/data.c                             |  22 +--
 fs/fat/inode.c                             |   9 +-
 fs/fuse/file.c                             |  51 ++---
 fs/gfs2/aops.c                             |  16 +-
 fs/gfs2/file.c                             |   2 +-
 fs/hfs/inode.c                             |   8 +-
 fs/hfsplus/inode.c                         |   9 +-
 fs/jfs/inode.c                             |   8 +-
 fs/namei.c                                 |   8 +-
 fs/ncpfs/file.c                            |  14 +-
 fs/nfs/direct.c                            |  36 ++--
 fs/nfs/file.c                              |  15 +-
 fs/nfs/read.c                              |   8 +-
 fs/nilfs2/inode.c                          |  10 +-
 fs/ntfs/file.c                             |  80 +++-----
 fs/ocfs2/aops.c                            |  22 +--
 fs/ocfs2/file.c                            | 124 ++++--------
 fs/read_write.c                            |   3 +-
 fs/reiserfs/inode.c                        |   8 +-
 fs/udf/file.c                              |  25 ++-
 fs/udf/inode.c                             |   7 +-
 fs/xfs/xfs_aops.c                          |  12 +-
 fs/xfs/xfs_file.c                          |  39 ++--
 include/linux/dcache.h                     |  59 ++++--
 include/linux/fs.h                         |  41 ++--
 include/linux/nfs_fs.h                     |   5 +-
 include/linux/uio.h                        |   8 +
 mm/filemap.c                               | 114 ++++-------
 mm/page_io.c                               |   4 +-
 55 files changed, 691 insertions(+), 861 deletions(-)

Re: [git pull] vfs part 3

[Linus Torvalds]

On Wed, Apr 15, 2015 at 9:04 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
>         That leaves only the actual d_inode annotations series out of the
> stuff already in for-next; there are several piles of stuff from various
> folks I'm going to add there tonight, leave it all to stew until the middle
> of the next week or so and send the final pull request then.  I hoped to do
> that last bit on Monday, but since there won't be -next on Thursday and
> Friday, this will probably have to happen a couple of days later ;-/

We can just leave that for next time.

I abhor this "feed things in chunks _during_ the merge window".

If this had been four different and separate branches that did
separate cleanups and had all been independently of each other in
linux-next since before the merge window, and had been in a "ready to
merge" state, that would be one thing. But this kind of "let's feed
Linus one chunk, then work on the next one" is not how it is supposed
to work. Not during the merge window,

            Linus

Re: [git pull] vfs part 3

[Al Viro]

On Thu, Apr 16, 2015 at 11:26:48PM -0400, Linus Torvalds wrote:
> On Wed, Apr 15, 2015 at 9:04 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> >         That leaves only the actual d_inode annotations series out of the
> > stuff already in for-next; there are several piles of stuff from various
> > folks I'm going to add there tonight, leave it all to stew until the middle
> > of the next week or so and send the final pull request then.  I hoped to do
> > that last bit on Monday, but since there won't be -next on Thursday and
> > Friday, this will probably have to happen a couple of days later ;-/
> 
> We can just leave that for next time.
> 
> I abhor this "feed things in chunks _during_ the merge window".
> 
> If this had been four different and separate branches that did
> separate cleanups and had all been independently of each other in
> linux-next since before the merge window, and had been in a "ready to
> merge" state, that would be one thing. But this kind of "let's feed
> Linus one chunk, then work on the next one" is not how it is supposed
> to work. Not during the merge window,

Actually, the pull requests so far (as well as d_inode annotation patches)
had been in -next - the main reason for not sending a single pull request
was the fact that such single pull would bring in a large part of net-next.
Separation between #2 and #3 wasn't due to "work on the next one" kind of
thing either - both had been there at the same time...

How do you prefer to deal with the situations like one with net-next?
I really don't know - mostly I've managed to avoid that kind of merges
from other trees, so it hadn't come up.  This time the topology inside
vfs.git#for-next had ended up much trickier than usual...

And do you have problems with actual d_inode/d_backing_inode annotation
patches left in for-next?