File system can mark a block "defunc" in order to prevent matching
against it in a new mount.
Signed-off-by: Daniil Lunev <[email protected]>
---
fs/super.c | 4 ++--
include/linux/fs.h | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/super.c b/fs/super.c
index f1d4a193602d6..fc5b3efe0cd01 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -1216,7 +1216,7 @@ static int set_bdev_super_fc(struct super_block *s, struct fs_context *fc)
static int test_bdev_super_fc(struct super_block *s, struct fs_context *fc)
{
- return s->s_bdev == fc->sget_key;
+ return !s->s_defunc && s->s_bdev == fc->sget_key;
}
/**
@@ -1307,7 +1307,7 @@ EXPORT_SYMBOL(get_tree_bdev);
static int test_bdev_super(struct super_block *s, void *data)
{
- return (void *)s->s_bdev == data;
+ return !s->s_defunc && (void *)s->s_bdev == data;
}
struct dentry *mount_bdev(struct file_system_type *fs_type,
diff --git a/include/linux/fs.h b/include/linux/fs.h
index bbde95387a23a..76feb3fe9bb9e 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1448,6 +1448,7 @@ struct super_block {
struct rw_semaphore s_umount;
int s_count;
atomic_t s_active;
+ bool s_defunc;
#ifdef CONFIG_SECURITY
void *s_security;
#endif
--
2.31.0
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.
Spelling nit: s/defunc/defunct/
I would suggest changing s_defunc to s_defunct in the patch below, to
ease in readability.
Cheers,
- Ted
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?
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.
On Thu, May 12, 2022 at 12:54 AM Christoph Hellwig <[email protected]> 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