linux-kernel - Re: [GIT PULL] bcachefs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 29 Jun 2023 11:00:35 +1000
From:   Dave Chinner <david@...morbit.com>
To:     Kent Overstreet <kent.overstreet@...ux.dev>
Cc:     Jens Axboe <axboe@...nel.dk>, torvalds@...ux-foundation.org,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-bcachefs@...r.kernel.org, Christoph Hellwig <hch@....de>,
        Christian Brauner <brauner@...nel.org>,
        Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [GIT PULL] bcachefs

On Wed, Jun 28, 2023 at 07:50:18PM -0400, Kent Overstreet wrote:
> On Wed, Jun 28, 2023 at 05:14:09PM -0600, Jens Axboe wrote:
> > On 6/28/23 4:55?PM, Kent Overstreet wrote:
> > >> But it's not aio (or io_uring or whatever), it's simply the fact that
> > >> doing an fput() from an exiting task (for example) will end up being
> > >> done async. And hence waiting for task exits is NOT enough to ensure
> > >> that all file references have been released.
> > >>
> > >> Since there are a variety of other reasons why a mount may be pinned and
> > >> fail to umount, perhaps it's worth considering that changing this
> > >> behavior won't buy us that much. Especially since it's been around for
> > >> more than 10 years:
> > > 
> > > Because it seems that before io_uring the race was quite a bit harder to
> > > hit - I only started seeing it when things started switching over to
> > > io_uring. generic/388 used to pass reliably for me (pre backpointers),
> > > now it doesn't.
> > 
> > I literally just pasted a script that hits it in one second with aio. So
> > maybe generic/388 doesn't hit it as easily, but it's surely TRIVIAL to
> > hit with aio. As demonstrated. The io_uring is not hard to bring into
> > parity on that front, here's one I posted earlier today for 6.5:
> > 
> > https://lore.kernel.org/io-uring/20230628170953.952923-4-axboe@kernel.dk/
> > 
> > Doesn't change the fact that you can easily hit this with io_uring or
> > aio, and probably more things too (didn't look any further). Is it a
> > realistic thing outside of funky tests? Probably not really, or at least
> > if those guys hit it they'd probably have the work-around hack in place
> > in their script already.
> > 
> > But the fact is that it's been around for a decade. It's somehow a lot
> > easier to hit with bcachefs than XFS, which may just be because the
> > former has a bunch of workers and this may be deferring the delayed fput
> > work more. Just hand waving.
> 
> Not sure what you're arguing here...?
> 
> We've had a long standing bug, it's recently become much easier to hit
> (for multiple reasons); we seem to be in agreement on all that. All I'm
> saying is that the existence of that bug previously is not reason to fix
> it now.

I agree with Kent here  - the kernel bug needs to be fixed
regardless of how long it has been around. Blaming the messenger
(userspace, fstests, etc) and saying it should work around a
spurious, unpredictable, undesirable and user-undebuggable kernel
behaviour is not an acceptible solution here...

I don't care how the kernel bug gets fixed, I just want the spurious
unmount failures when there are no userspace processes actively
using the filesytsem to go away forever.

-Dave.
-- 
Dave Chinner
david@...morbit.com