Merge tag 'vfs-6.8-rc1.fixes' of gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs
authorLinus Torvalds <torvalds@linux-foundation.org>
Wed, 17 Jan 2024 17:34:25 +0000 (09:34 -0800)
committerLinus Torvalds <torvalds@linux-foundation.org>
Wed, 17 Jan 2024 17:34:25 +0000 (09:34 -0800)
commitc2459ce011f65487231c6340486d5acdaceac6a7
tree970bae01a7783d5717e3ea44254807ac2152bc6a
parent7f5e47f785140c2d7948bee6fc387f939f68dbb8
parentba5afb9a84df2e6b26a1b6389b98849cd16ea757
Merge tag 'vfs-6.8-rc1.fixes' of gitolite.pub/scm/linux/kernel/git/vfs/vfs

Pull vfs fixes from Christian Brauner:
 "This contains two fixes for the current merge window. The listmount
  changes that you requested and a fix for a fsnotify performance
  regression:

   - The proposed listmount changes are currently under my authorship. I
     wasn't sure whether you'd wanted to be author as the patch wasn't
     signed off. If you do I'm happy if you just apply your own patch.

     I've tested the patch with my sh4 cross-build setup. And confirmed
     that a) the build failure with sh on current upstream is
     reproducible and that b) the proposed patch fixes the build
     failure. That should only leave the task of fixing put_user on sh.

   - The fsnotify regression was caused by moving one of the hooks out
     of the security hook in preparation for other fsnotify work. This
     meant that CONFIG_SECURITY would have compiled out the fsnotify
     hook before but didn't do so now.

     That lead to up to 6% performance regression in some io_uring
     workloads that compile all fsnotify and security checks out. Fix
     this by making sure that the relevant hooks are covered by the
     already existing CONFIG_FANOTIFY_ACCESS_PERMISSIONS where the
     relevant hook belongs"

* tag 'vfs-6.8-rc1.fixes' of gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs:
  fs: rework listmount() implementation
  fsnotify: compile out fsnotify permission hooks if !FANOTIFY_ACCESS_PERMISSIONS