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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ