diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2024-01-17 20:34:25 +0300 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2024-01-17 20:34:25 +0300 |
commit | c2459ce011f65487231c6340486d5acdaceac6a7 (patch) | |
tree | 970bae01a7783d5717e3ea44254807ac2152bc6a /security/yama | |
parent | 7f5e47f785140c2d7948bee6fc387f939f68dbb8 (diff) | |
parent | ba5afb9a84df2e6b26a1b6389b98849cd16ea757 (diff) | |
download | linux-c2459ce011f65487231c6340486d5acdaceac6a7.tar.xz |
Merge tag 'vfs-6.8-rc1.fixes' of gitolite.kernel.org: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
Diffstat (limited to 'security/yama')
0 files changed, 0 insertions, 0 deletions