On Wed, Feb 14, 2018 at 01:22:06PM +0200, Amir Goldstein wrote: > On Wed, Feb 14, 2018 at 1:03 PM, Jan Kara <jack@xxxxxxx> wrote: > > On Mon 12-02-18 13:46:48, Xiong Zhou wrote: > >> Stress test for fanotify and inotify. Exercise fanotify and > >> inotify user interfaces in loop while other stress tests going > >> on in the watched test directory. > >> > >> Watching slab object inotify_inode_mark size, report fail > >> it increases too fast. This may lead to a crash if OOM killer > >> invoked. > >> > >> kernel commit related to the fixes in v4.15-rc1: > >> 0d6ec07 fsnotify: pin both inode and vfsmount mark > >> > >> Signed-off-by: Xiong Zhou <xzhou@xxxxxxxxxx> > > > > I'm sorry for chiming in so late but I was on vacation. Just one question: > > Currently, all inotify and fanotify tests are part of LTP. Is there any > > good reason for putting this particular test to fstests and not LTP? > > Specifically I've refrained from putting notification framework tests to > > fstests because there's practically no relation of it to implementation of > > any particular filesystem. Also I'd prefer not to have fanotify / inotify > > tests in two different frameworks... > > > > I second that. > Also, Eryu did not chime in yet (and Dave probably did not look closely), > but I think fstests in general try to refrain from single purpose test > programs such as fsnotify_stress. I have no problem with committing fsnotify tests in fstests, we do have tests that exercise the vfs level infrastructure purely, e.g. the shared subtree operations tests. But if both fanotify subsystem maintainer and main reviewer suggest putting this test to LTP, I have no problem with that too :) Thanks, Eryu -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
