On Thu, Aug 31, 2023 at 09:10:00AM +1000, Dave Chinner wrote: > On Tue, Aug 29, 2023 at 04:15:59PM -0700, Darrick J. Wong wrote: > > From: Darrick J. Wong <djwong@xxxxxxxxxx> > > > > Don't enable io_uring in fsstress unless someone asks for it explicitly, > > just like fsx. I think both tools should require explicit opt-in to > > facilitate A/B testing between the old IO paths and this new one. > > > > While I was playing with fstests+io_uring, I noticed quite a few > > regressions in fstests, which fell into two classes: > > > > The first class is umount failing with EBUSY. Apparently this is due to > > the kernel uring code hanging on to file references even after the > > userspace program exits. Tests that run fsstress and immediately > > unmount now fail sporadically due to the EBUSY. Unfortunately, the > > metadata update stress tests, the recovery loop tests, the xfs online > > fsck functional tests, and the xfs fuzz tests make heavy use of > > "fsstress; umount" and they fail all over the place now. > > > > Something's broken, Jens and Christian said it should get fixed, but in > > the meantime this is getting in the way of me testing my own code. > > I'm not seeing regular problems with io_uring on my test machines. Me neither. > Occasionally there will be a filesystem unmount issue, but that's > not causing anything but a single test here or there to fail. It's > not a big deal. > > > The second problem I noticed is that fsstress now lodges complaints > > about sporadic heap corruption. I /think/ this is due to some kind of > > memory mishandling bug when uring is active but IO requests fail, but I > > haven't had the time to go figure out what's up with that. > > Yes, I've seen that happen in ~6.4 kernels, but current TOT doesn't > seem to do that anymore on my test machines. > > Regardless, I don't think turning off io_uring support by default is > the right thing to do. That's just shooting the messenger. We really Agree, we'd better to give io_uring a test by default. I've found several regression issues on io_uring by fsstress. If someone feels io_uring breaks his testing, remove the liburing and liburing-devel package, then fsstress won't build io_uring things. Or export FSSTRESS_AVOID="-f uring_read=0 -f uring_write=0". Sometimes, I even removed the IO_URING kernel config then rebuild kernel, to avoid the effection of io_uring code totally. Thanks, Zorro > do need this code to be exercised as much as possible because it is > so full of bugs. Sure, add a flag to turn it off if you need it off > (and add it to FSSTRESS_AVOID for your test environments), but > otherwise we really should be exercising io_uring. Ignorance doesn't > prevent bugs or CVEs.... > > Realistically, what we actually need is to require io_uring > developers to focus on testing io_uring functionality with > filesystems and fsstress and *to fix the regressions* rather than > endlessly adding more features and complexity that create more bugs. > Turning the code off certainly won't help us acheive that.... > > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx >
