[git pull] more vfs.git stuff

[git pull] more vfs.git stuff

[Al Viro]

A couple of fixes + getting rid of __blkdev_put() return value.
Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (4):
      hfs: SMP race on directory close()
      mtd_blktrans_ops->release() should return void
      block_device_operations->release() should return void
      make blkdev_put() return void

Geert Uytterhoeven (1):
      proc: Use PDE attribute setting accessor functions

Diffstat:
 arch/arm/mach-msm/last_radio_log.c  |    2 +-
 arch/cris/kernel/profile.c          |    2 +-
 arch/um/drivers/ubd_kern.c          |    5 ++---
 arch/xtensa/platforms/iss/simdisk.c |    3 +--
 drivers/block/amiflop.c             |    3 +--
 drivers/block/aoe/aoeblk.c          |    6 ++----
 drivers/block/ataflop.c             |    5 ++---
 drivers/block/cciss.c               |    5 ++---
 drivers/block/cpqarray.c            |    6 ++----
 drivers/block/drbd/drbd_main.c      |    5 ++---
 drivers/block/floppy.c              |    4 +---
 drivers/block/loop.c                |    6 ++----
 drivers/block/paride/pcd.c          |    3 +--
 drivers/block/paride/pd.c           |    4 +---
 drivers/block/paride/pf.c           |    9 ++++-----
 drivers/block/pktcdvd.c             |    4 +---
 drivers/block/rbd.c                 |    4 +---
 drivers/block/swim.c                |    4 +---
 drivers/block/swim3.c               |    5 ++---
 drivers/block/xen-blkfront.c        |    3 +--
 drivers/block/xsysace.c             |    3 +--
 drivers/block/z2ram.c               |    6 ++----
 drivers/cdrom/gdrom.c               |    3 +--
 drivers/ide/ide-cd.c                |    4 +---
 drivers/ide/ide-gd.c                |    4 +---
 drivers/ide/ide-tape.c              |    4 +---
 drivers/md/dm.c                     |    4 +---
 drivers/md/md.c                     |    4 +---
 drivers/memstick/core/mspro_block.c |    8 +++-----
 drivers/message/i2o/i2o_block.c     |    8 ++------
 drivers/mmc/card/block.c            |    3 +--
 drivers/mtd/mtd_blkdevs.c           |    9 ++++-----
 drivers/mtd/mtdblock.c              |    4 +---
 drivers/mtd/sm_ftl.c                |    3 +--
 drivers/s390/block/dasd.c           |   18 +++++++-----------
 drivers/s390/block/dcssblk.c        |   12 ++++--------
 drivers/s390/block/scm_blk.c        |    3 +--
 drivers/scsi/sd.c                   |    3 +--
 drivers/scsi/sr.c                   |    3 +--
 fs/block_dev.c                      |   16 +++++++---------
 fs/ext3/super.c                     |   11 ++++-------
 fs/ext4/super.c                     |   11 ++++-------
 fs/hfs/dir.c                        |    2 ++
 fs/nfs/blocklayout/blocklayout.h    |    2 +-
 fs/nfs/blocklayout/blocklayoutdev.c |    4 ++--
 fs/nfs/blocklayout/blocklayoutdm.c  |    8 +-------
 fs/reiserfs/journal.c               |   16 +++-------------
 include/linux/blkdev.h              |    2 +-
 include/linux/fs.h                  |    2 +-
 include/linux/mtd/blktrans.h        |    2 +-
 50 files changed, 93 insertions(+), 177 deletions(-)

[git pull] more vfs.git stuff

[Al Viro]

	Regression fix from Geert + yet another open-coded kernel_read().
Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (1):
      ecryptfs: don't open-code kernel_read()

Geert Uytterhoeven (1):
      xtensa simdisk: Fix proc_create_data() conversion fallout

Diffstat:
 arch/xtensa/platforms/iss/simdisk.c |    4 ++--
 fs/ecryptfs/read_write.c            |    9 +--------
 2 files changed, 3 insertions(+), 10 deletions(-)

Re: [git pull] more vfs.git stuff

[Linus Torvalds]

On Thu, May 9, 2013 at 12:26 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>         Regression fix from Geert + yet another open-coded kernel_read().

Hmm. I get one more commit - a racy usbmon thing. Which looks fine per
se, but would look even better if it just made mmap_active an atomic_t
instead, wouldn't you say?

So I didn't pull, waiting for clarification.

         Linus

Re: [git pull] more vfs.git stuff

[Linus Torvalds]

On Thu, May 9, 2013 at 1:12 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Hmm. I get one more commit - a racy usbmon thing. Which looks fine per
> se, but would look even better if it just made mmap_active an atomic_t
> instead, wouldn't you say?

Oh, I see, the spinlock protects the read too and the logic there. Not
that I'm at all sure we care, since if that code races with somebody
else doing an mmap, there's a race at a much higher level anyway. So I
don't think the spinlock really gives any more serialization between
the reading/writing of that mmap_active count. You're going to get
either the old or the new value anyway, and an atomic will do that
too.

So whatever. I just don't want to pull stuff that gets me unexpected
patches that weren't in the pull request.

                 Linus

Re: [git pull] more vfs.git stuff

[Al Viro]

On Thu, May 09, 2013 at 01:12:43PM -0700, Linus Torvalds wrote:
> On Thu, May 9, 2013 at 12:26 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >         Regression fix from Geert + yet another open-coded kernel_read().
> 
> Hmm. I get one more commit - a racy usbmon thing.

Oops - pull stats not updated...  My apologies.

> Which looks fine per
> se, but would look even better if it just made mmap_active an atomic_t
> instead, wouldn't you say?

The only place checking that sucker is in a fairly large area protected by
->b_lock (in mon_bin_event()); I really don't want to dig deep enough to
tell if having it changed right after it had been checked is safe.  OTOH,
from a cursory look through that code it appears that the whole map_count
thing is completely misguided - it seems to assume that ->open() is called for
each VMA, including the one created by mmap(2).  Sigh...

OK, it might make more sense to drop that last commit for now.  It's obviously
more broken in mmap-related code than just a buggered locking for counter
and it probably doesn't make much sense to patch just that one.  And I'll
have several more fixes of similar turds tomorrow, when mchehab finishes
testing videobuf ones.  Up to you, really.

Re: [git pull] more vfs.git stuff

[Al Viro]

On Thu, May 09, 2013 at 09:28:15PM +0100, Al Viro wrote:

> The only place checking that sucker is in a fairly large area protected by
> ->b_lock (in mon_bin_event()); I really don't want to dig deep enough to
> tell if having it changed right after it had been checked is safe.  OTOH,
> from a cursory look through that code it appears that the whole map_count
> thing is completely misguided - it seems to assume that ->open() is called for
> each VMA, including the one created by mmap(2).  Sigh...

Less cursory one shows that they do call their ->open() from their ->mmap().
OTOH, the code looking and ->mmap_active looks fishy - what happens if we
do allocation before mmap() happens?

Anyway, let's just drop that commit for now; it clearly needs more RTFS.
Could you pull for-linus^?

Re: [git pull] more vfs.git stuff

[Linus Torvalds]

On Thu, May 9, 2013 at 1:34 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> Anyway, let's just drop that commit for now; it clearly needs more RTFS.
> Could you pull for-linus^?

Done.

         Linus

[git pull] more vfs.git stuff

[Al Viro]

	O_TMPFILE ABI changes, Oleg's fput() series, misc cleanups,
including making simple_lookup() usable for filesystems with non-NULL,
which allows to get rid of quite a bit of ugliness.  Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus

Shortlog:
Al Viro (8):
      Safer ABI for O_TMPFILE
      rpc_create_*_dir: don't bother with qstr
      __rpc_lookup_create_exclusive: pass string instead of qstr
      configfs: don't open-code d_alloc_name()
      make simple_lookup() usable for filesystems that set ->s_d_op
      efivarfs: we can use simple_lookup() now
      cgroup: we can use simple_lookup() now
      sunrpc: now we can just set ->s_d_op

Andrew Morton (1):
      fs/file_table.c:fput(): add comment

Oleg Nesterov (3):
      fput: turn "list_head delayed_fput_list" into llist_head
      llist: fix/simplify llist_add() and llist_add_batch()
      llist: llist_add() can use llist_add_batch()

Diffstat:
 arch/alpha/include/uapi/asm/fcntl.h  |    2 +-
 arch/parisc/include/uapi/asm/fcntl.h |    2 +-
 arch/sparc/include/uapi/asm/fcntl.h  |    2 +-
 fs/configfs/dir.c                    |   13 +--------
 fs/efivarfs/inode.c                  |   14 +----------
 fs/file_table.c                      |   31 ++++++++++++-----------
 fs/libfs.c                           |    3 +-
 fs/namei.c                           |    2 +-
 fs/open.c                            |    4 +-
 include/linux/fs.h                   |    2 +
 include/linux/llist.h                |   19 +++-----------
 include/linux/sunrpc/rpc_pipe_fs.h   |    4 +-
 include/uapi/asm-generic/fcntl.h     |    8 ++++-
 kernel/cgroup.c                      |   11 +-------
 lib/llist.c                          |   15 ++++-------
 net/sunrpc/cache.c                   |   18 ++++----------
 net/sunrpc/clnt.c                    |   20 ++++++---------
 net/sunrpc/rpc_pipe.c                |   45 +++++++++++----------------------
 18 files changed, 75 insertions(+), 140 deletions(-)

[git pull] more vfs.git stuff

[Al Viro]

[trying to use git request-pull; result looks more or less sane, AFAICT...]
Embarrassing braino fix + pipe page accounting + fixing an eyesore in
find_filesystem() (checking that s1 is equal to prefix of s2 of given length
can be done in many ways, but "compare strlen(s1) with length and then do
strncmp()" is not a good one...)

The following changes since commit c7b6c5fe67d1519759de2014a2c44f50fb1426f3:

  Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs (2016-01-15 12:41:32 -0800)

are available in the git repository at:

  gitolite@ra.kernel.org:/pub/scm/linux/kernel/git/viro/vfs.git for-linus

for you to fetch changes up to 117aa41e8020fe493bbb677ebe828c3a4b380185:

  [regression] fix braino in fs/dlm/user.c (2016-01-21 17:45:15 -0500)

----------------------------------------------------------------
Al Viro (2):
      find_filesystem(): simplify comparison
      [regression] fix braino in fs/dlm/user.c

Willy Tarreau (1):
      pipe: limit the per-user amount of pages allocated in pipes

 Documentation/sysctl/fs.txt | 23 ++++++++++++++++++++++
 fs/dlm/user.c               |  2 +-
 fs/filesystems.c            |  6 +++---
 fs/pipe.c                   | 47 +++++++++++++++++++++++++++++++++++++++++++--
 include/linux/pipe_fs_i.h   |  4 ++++
 include/linux/sched.h       |  1 +
 kernel/sysctl.c             | 14 ++++++++++++++
 7 files changed, 91 insertions(+), 6 deletions(-)

Re: [git pull] more vfs.git stuff

[Linus Torvalds]

On Thu, Jan 21, 2016 at 3:04 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> [trying to use git request-pull; result looks more or less sane, AFAICT...]

Looks fine, if you can just fix this part:

>   gitolite@ra.kernel.org:/pub/scm/linux/kernel/git/viro/vfs.git for-linus

and have it point to the public git://git.kernel.org/.. thing.

Either by just using "pushurl" for origin, or by having separate
push/pull names entirely.

           Linus

Re: [git pull] more vfs.git stuff

[Al Viro]

On Fri, Jan 22, 2016 at 10:26:18AM -0800, Linus Torvalds wrote:
> On Thu, Jan 21, 2016 at 3:04 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> > [trying to use git request-pull; result looks more or less sane, AFAICT...]
> 
> Looks fine, if you can just fix this part:
> 
> >   gitolite@ra.kernel.org:/pub/scm/linux/kernel/git/viro/vfs.git for-linus
> 
> and have it point to the public git://git.kernel.org/.. thing.
> 
> Either by just using "pushurl" for origin, or by having separate
> push/pull names entirely.

Sorry about that - pushurl added, both git push and git request-pull seem
to be working now.

BTW, looks like ext4 is the only pending i_mutex-sensitive tree; once
it's pulled, I'll regenerate the inode_{lock,unlock,trylock,...} patch
and send it your way.

Re: [git pull] more vfs.git stuff

[Linus Torvalds]

On Fri, Jan 22, 2016 at 10:42 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> BTW, looks like ext4 is the only pending i_mutex-sensitive tree; once
> it's pulled, I'll regenerate the inode_{lock,unlock,trylock,...} patch
> and send it your way.

I have the ext4 pull pending now, I'm doing some test-builds before
pulling that and xfs. So it should be all done in half an hour or so.

              Linus