On 5/22/22 6:13 PM, Dave Chinner wrote: > On Sat, May 21, 2022 at 08:19:51PM -0600, Jens Axboe wrote: >> On 5/21/22 7:07 PM, Jens Axboe wrote: >>> On 5/21/22 5:13 PM, Dave Chinner wrote: >>>> [cc io_uring] >>>> >>>> On Thu, May 12, 2022 at 06:52:37PM +0200, Christian Brauner wrote: >>>>> From: "Christian Brauner (Microsoft)" <brauner@xxxxxxxxxx> >>>>> >>>>> Hey everyone, >>>>> >>>>> Please note that this patch series contains patches that will be >>>>> rejected by the fstests mailing list because of the amount of changes >>>>> they contain. So tools like b4 will not be able to find the whole patch >>>>> series on a mailing list. In case it's helpful I've added the >>>>> "fstests.vfstest.for-next" tag which can be pulled. Otherwise it's >>>>> possible to simply use the patch series as it appears in your inbox. >>>>> >>>>> All vfstests pass: >>>> >>>> [...] >>>> >>>>> #### xfs #### >>>>> ubuntu@imp1-vm:~/src/git/xfstests$ sudo ./check -g idmapped >>>>> FSTYP -- xfs (debug) >>>>> PLATFORM -- Linux/x86_64 imp1-vm 5.18.0-rc4-fs-mnt-hold-writers-8a2e2350494f #107 SMP PREEMPT_DYNAMIC Mon May 9 12:12:34 UTC 2022 >>>>> MKFS_OPTIONS -- -f /dev/sda4 >>>>> MOUNT_OPTIONS -- /dev/sda4 /mnt/scratch >>>>> >>>>> generic/633 58s ... 58s >>>>> generic/644 62s ... 60s >>>>> generic/645 161s ... 161s >>>>> generic/656 62s ... 63s >>>>> xfs/152 133s ... 133s >>>>> xfs/153 94s ... 92s >>>>> Ran: generic/633 generic/644 generic/645 generic/656 xfs/152 xfs/153 >>>>> Passed all 6 tests >>>> >>>> I'm not sure if it's this series that has introduced a test bug or >>>> triggered a latent issue in the kernel, but I've started seeing >>>> generic/633 throw audit subsystem warnings on a single test machine >>>> as of late Friday: >>>> >>>> [ 7285.015888] WARNING: CPU: 3 PID: 2147118 at kernel/auditsc.c:2035 __audit_syscall_entry+0x113/0x140 >>> >>> Does your kernel have this commit? >>> >>> commit 69e9cd66ae1392437234a63a3a1d60b6655f92ef >>> Author: Julian Orth <ju.orth@xxxxxxxxx> >>> Date: Tue May 17 12:32:53 2022 +0200 >>> >>> audit,io_uring,io-wq: call __audit_uring_exit for dummy contexts > > No, that wasn't in -rc7. > >> I could not reproduce either with or without your patch when I finally >> got that test going and figure out how to turn on audit and get it >> enabled. I don't run with that. > > Ok. Given that this has been broken for over a year and nobody > has noticed until late .18-rcX, it might be worth adding an audit > enabled VM to your io-uring test farm.... It was in the 5.16 release, so it's ~4 months ago. Don't disagree on the testing, though I do think that's mostly on the audit side. I had no hand in any of that code. >From my experience trying to reproduce it yesterday, my test distros don't even enable it and you have to both fiddle the config and add a boot parameter to even turn it on. And then it still didn't trigger for me. I'll see if I can add something to the testing mix for this. -- Jens Axboe
