[PATCH 0/33 v5] fsnotify: Avoid SRCU stalls with fanotify permission events

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

This is the fifth revision of my patches to avoid SRCU stalls when fanotify
waits for response to permission events from userspace processes. Thanks to
Amir, Paul, and Miklos for review! It also passes a new LTP test that tries to
provoke hangs in fanotify subsystem when there are unanswered fanotify
permission events. If nobody has more objections, I'll push the changes to my
tree.

Amir, since some of the patches were split, I didn't add your ack/reviewed-by
to those patches (although you reviewed overall result). Just have a look
whether you are fine with the result. I have made sure that final result is
the same as original series (modulo couple small changes suggested by Miklos).
I have to say I'm now more confident with the series than I was before so the
splitting Miklos suggested really helped. Thanks!

Miklos, is the split like this better for you?

Changes since v4:
* Further split up of patches as requested by Miklos
* Moved some hunks between patches to make things more logical
* Couple of smaller improvements suggested by Miklos
* Rebased on top of 4.11-rc2

Changes since v3:
* added Reviewed-by tags
* split adding of fsnotify_mark_connector into 4 smaller parts as Miklos asked
* simplified API of fsnotify_prepare/finish_user_wait()

Changes since v2:
* added Reviewed-by tags
* dropped fsnotify_put_list() abstraction
* use rcu_assign_pointer() where appropriate

Changes since v1:
* renamed fsnotify_mark_list to fsnotify_mark_connector and couple other
  things
* updated some comments and changelogs to better explain what is going on
* made audit use inode pointer as a key again
* added Reviewed-by tags
* dropped two audit fixes that got already merged
* added cleanup of mark destruction functions

Patch set overview
------------------

Currently, fanotify waits for response to a permission even from userspace
process while holding fsnotify_mark_srcu lock. That has a consequence that
when userspace process takes long to respond or does not respond at all,
fsnotify_mark_srcu period cannot ever complete blocking reclaim of any
notification marks and also blocking any process that did synchronize_srcu()
on fsnotify_mark_srcu. Effectively, this eventually blocks anybody interacting
with the notification subsystem. Miklos has some real world reports of this
happening. Although this in principle a problem of broken userspace
application (which futhermore has to have CAP_SYS_ADMIN in init_user_ns, so
it is not a security problem), it is still nasty that a simple error can
block the kernel like this.

This patch set solves this problem. The basic idea of the solution is that
when fanotify needs to wait for response from userspace process, it grabs
reference to the mark which generated the event and drops fsnotify_mark_srcu
lock. When userspace responds, we grab fsnotify_mark_srcu again, drop
the mark reference, and continue iterating the list of marks attached to the
inode / vfsmount delivering the event to other notification groups. What
complicates this simple approach is that the mark for which we wait for
response has to stay pinned in the list of marks attached to the inode /
vfsmount so that we can resume iteration of the list when userspace responds
but on the other hand when the inode gets unlinked while we wait for userspace
reponse, we need to destroy the mark (or at least detach it from the inode).

The first 5 patches contain some initial fixes and cleanups. Patches 6-17
implement attaching of marks to inode / vfsmount via a dedicated structure
which allows us to detach list of marks from the object without having to
destroy the list itself. Patches 18-20 implement removal of mark from the
list of marks attached to an object when last mark reference is dropped.
Patches 21-24 then implement dropping of SRCU lock when waiting on response
from userspace. Patches 25-33 are mostly trivial cleanups that get rid of
trivial wrappers and one pointer in the mark structure.

Patches have survived testing with inotify/fanotify tests in LTP.

Finally, to ease experimenting with the patches I've pushed them out to
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git for_testing

								Honza



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux