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]

Message-ID: <20230628175204.oeek4nnqx7ltlqmg@moria.home.lan>
Date:   Wed, 28 Jun 2023 13:52:04 -0400
From:   Kent Overstreet <kent.overstreet@...ux.dev>
To:     Jens Axboe <axboe@...nel.dk>
Cc:     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>
Subject: Re: [GIT PULL] bcachefs

On Wed, Jun 28, 2023 at 10:57:02AM -0600, Jens Axboe wrote:
> I discussed this with Christian offline. I have a patch that is pretty
> simple, but it does mean that you'd wait for delayed fput flush off
> umount. Which seems kind of iffy.
> 
> I think we need to back up a bit and consider if the kill && umount
> really is sane. If you kill a task that has open files, then any fput
> from that task will end up being delayed. This means that the umount may
> very well fail.
> 
> It'd be handy if we could have umount wait for that to finish, but I'm
> not at all confident this is a sane solution for all cases. And as
> discussed, we have no way to even identify which files we'd need to
> flush out of the delayed list.
> 
> Maybe the test case just needs fixing? Christian suggested lazy/detach
> umount and wait for sb release. There's an fsnotify hook for that,
> fsnotify_sb_delete(). Obviously this is a bit more involved, but seems
> to me that this would be the way to make it more reliable when killing
> of tasks with open files are involved.

No, this is a real breakage. Any time we introduce unexpected
asynchrony there's the potential for breakage: case in point, there was
a filesystem that made rm asynchronous, then there were scripts out
there that deleted until df showed under some threshold.. whoops...

this would break anyone that does fuser; umount; and making the umount
lazy just moves the race to the next thing that uses the block device.

I'd like to know how delayed_fput() avoids this.