On Thu, Dec 22, 2016 at 4:15 AM, Jan Kara <jack@xxxxxxx> 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. -- paul moore www.paul-moore.com -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
