linux-kernel - Re: [PATCH 1/2] fs/super: Add a flag to mark super block defunc

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] [day] [month] [year] [list]

Message-ID: <CAONX=-cW9Or1eEVUg3H669tEDW+1v16zZUGRQCaF3DAuLmgFvw@mail.gmail.com>
Date:   Thu, 12 May 2022 07:33:27 +1000
From:   Daniil Lunev <dlunev@...omium.org>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     linux-fsdevel@...r.kernel.org, fuse-devel@...ts.sourceforge.net,
        linux-kernel@...r.kernel.org,
        Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH 1/2] fs/super: Add a flag to mark super block defunc

On Thu, May 12, 2022 at 12:54 AM Christoph Hellwig <hch@...radead.org> wrote:
>
> On Wed, May 11, 2022 at 11:30:56AM +1000, Daniil Lunev wrote:
> > File system can mark a block "defunc" in order to prevent matching
> > against it in a new mount.
>
> Why use a bool instead of using s_iflags?
Oh, I was looking at the flag field, but for some reason got confused
about its values.
Looking again, I totally can use it. However, the other option, that
Miklos proposed in
a thread on the cover letter mail, is to remove the superblock from
"type->fs_supers".
I plan to upload a new version with that option. Which of those two
would you prefer?

> Also I suspect we should never reuse a force mounted superblock,
> but at least for block devices we should also not allow allocating
> a new one for that case but just refuse the mount.
Re-use of a force unmounted superblock "just works" for at least ext4
- in fact, it
continues to work as if nothing happened to it. Changing that may
break existing use
cases. For FUSE that unfortunately unachievable, given the daemon is
disconnected
from the driver and likely killed after force unmount, but ability to
re-mount is essential,
because force unmount is the only way to reliably achieve suspend
while using FUSE,
and if re-mount doesn't work, the connected device/share is missing
after resume.

Thanks,
Daniil