On Thu, Dec 22, 2016 at 4:05 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > On Thu, Dec 22, 2016 at 10:58 PM, Paul Moore <paul@xxxxxxxxxxxxxx> wrote: >> 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. > > 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! No problem, I'm glad it's helpful. FWIW, it's based off ideas from the selinux-testsuite (link below); the general motivation being a quick and easy regression test that can be used to verify patches and general upstream development. * https://github.com/SELinuxProject/selinux-testsuite In addition to individual commit testing, I've combined both the audit and SELinux testsuites with a semi-automated weekly kernel build to test both the -rcX releases as well the selinux/next and audit/next branches; it's proved quite beneficial. In case you're curious, I did a short presentation on it this summer (slides and video at the link below). If you are interested, I'm happy to talk about it further, but perhaps in another thread - I don't want to hijack Jan's patchset with marginally relevant testing discussion :) * http://www.paul-moore.com/blog/d/2016/08/flock-kernel-testing.html -- 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
