Re: [PATCH 12/11 TESTSUITE] audit_testsuite: Add stress test for tree watches

On Thu 11-10-18 19:03:53, Paul Moore wrote: > On October 11, 2018 7:39:39 AM Jan Kara <jack(a)suse.cz&gt; wrote: > > On Wed 10-10-18 02:43:46, Paul Moore wrote: > >> On Tue, Oct 9, 2018 at 3:40 AM Jan Kara <jack(a)suse.cz&gt; wrote: > >>> On Fri 05-10-18 17:06:22, Paul Moore wrote: > >>>> On Tue, Sep 4, 2018 at 12:06 PM Jan Kara <jack(a)suse.cz&gt; wrote: > >>>>> Add stress test for stressing audit tree watches by adding and deleting > >>>>> rules while events are generated and watched filesystems are mounted and > >>>>> unmounted in parallel. > >>>>> > >>>>> Signed-off-by: Jan Kara <jack(a)suse.cz&gt; > >>>>> --- > >>>>> tests/stress_tree/Makefile | 8 +++ > >>>>> tests/stress_tree/test | 171 +++++++++++++++++++++++++++++++++++++++++++++ > >>>>> 2 files changed, 179 insertions(+) > >>>>> create mode 100644 tests/stress_tree/Makefile > >>>>> create mode 100755 tests/stress_tree/test > >>>> > >>>> No commentary on the test itself, other than perhaps it should live > >>>> under test_manual/, but in running the tests in a loop today I am > >>>> reliably able to panic my test kernel after ~30m or so. > >>> > >>> Interesting. How do you run the test? > >> > >> Nothing fancy, just a simple bash loop: > >> > >> # cd tests/stress_tree > >> # while ./test; do /bin/true; done > > > > OK, I did succeed in reproducing some problems with my patches - once I was > > able to trigger a livelock and following softlockup warning - this is > > actually a problem introduced by my patches, and once a use after free > > issue (not sure what that was since after I've added some debugging I > > wasn't able to trigger it anymore). Anyway, I'll try more after fixing the > > livelock. Do you want me to add fixes on top of my series or just fixup the > > original series? > > Since these are pretty serious bugs, and I try to avoid merging > known-broken patches which will go up to Linus, why don't you go ahead > and respin the patchset with the new fixes included. You can also use > the opportunity to squash in the rename patch and fix that mid-patchset > compilation problem that I fixed up during the merge. OK, I'm now testing a version with the softlockup fixed and some locking around untag_chunk() simplified when I had to meddle with that anyway. I'll see if I can hit further failures...