On Thu, Dec 22, 2016 at 10:58 PM, Paul Moore <paul(a)paul-moore.com&gt; wrote: > On Thu, Dec 22, 2016 at 4:15 AM, Jan Kara <jack(a)suse.cz&gt; wrote: >> Hello, >> >> 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 ... >> >> Patches have survived testing with inotify/fanotify tests in LTP. I didn't test >> audit - Paul can you give these patches some testing? Since some of the >> changes are really non-trivial, I'd welcome if someone reviewed the patch set. > > I'm going to take a look at the audit related patches right now, > expect some feedback shortly. > > In the meantime, if you wanted to play a bit with some simple audit > regression tests, check out the testsuite below: > > * https://github.com/linux-audit/audit-testsuite > > ... it is still rather simplistic, but the tests in tests/file_* and > tests/exec_name should do some basic exercises of the audit code that > leverages fsnotify. If nothing else, it should give you some ideas > about how you might stress this a bit more with audit. Mmm that's interesting. I was looking for a good place to start with a proper testsuite for fsnotify. It seems like the 2 subsystems could use the same testsuite. I will look into it. Thanks!