On Fri, Jun 30, 2023 at 11:40:32AM +0200, Christian Brauner wrote: > We're all not very impressed with that's going on here. I think everyone > has made that pretty clear. > > It's worrying that this reply is so quickly and happily turning to > "I'm a real engineer" and "you're confused" tropes and then isn't even > making a clear point. Going forward this should stop otherwise I'll > cease replying. > > Nothing I said was confused. The discussion was initially trying to fix > this in umount and we're not going to fix async aio behavior in umount. Christain, why on earth would we be trying to fix this in umount? All you posted was a stack trace and something handwavy about how fixing it in umount would be hard, and yes it would be! That's crazy! This is a basic lifetime issue, where we just need to make sure that refcounts are getting released at the appropriate place and not being delayed for arbitrarily long (i.e. the global delayed fput list, which honestly we should probably try to get rid of). Furthermore, when issues with fput have caused umount to fail in the past it's always been considered a bug - see the addition of __fput_sync(), if you do some searching you should be able to find multiple patches where this has been dealt with. > My earlier mail clearly said that io_uring can be changed by Jens pretty > quickly to not cause such test failures. Jens posted a fix that didn't actually fix anything, and after that it seemed neither of you were interested in actually fixing this. So based on that, maybe we need to consider switching fstests back to AIO just so we can get work done...
