Re: [PATCH 2/2] generic: only enable io_uring in fsstress explicitly

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]



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
> 




[Index of Archives]     [Linux Filesystems Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux