All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zizhi Wo <wozizhi@huawei.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: <jack@suse.com>, <brauner@kernel.org>, <axboe@kernel.dk>,
	<hch@lst.de>, <linux-fsdevel@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <yukuai3@huawei.com>,
	<yangerkun@huawei.com>
Subject: Re: [PATCH] fs: Add additional checks for block devices during mount
Date: Sat, 19 Jul 2025 12:46:32 +0800	[thread overview]
Message-ID: <3bec1e49-e833-4e51-8bf5-3fa7f3defa86@huawei.com> (raw)
In-Reply-To: <20250719041709.GI2580412@ZenIV>



在 2025/7/19 12:17, Al Viro 写道:
> On Sat, Jul 19, 2025 at 10:44:03AM +0800, Zizhi Wo wrote:
> 
>> mkfs.ext4 -F /dev/sdb
>> mount /dev/sdb /mnt
>> mknod /dev/test b 8 16    # [sdb 8:16]
>> echo 1 > /sys/block/sdb/device/delete
>> mount /dev/test /mnt1    # -> mount success
>>
>> Therefore, it is necessary to add an extra check. Solve this problem by
>> checking disk_live() in super_s_dev_test().
> 
> That smells like a wrong approach...  You are counting upon the failure
> of setup_bdev_super() after the thing is forced on the "no reuse" path,
> and that's too convoluted and brittle...
> 

Since this problem can only occur in the superblock reuse scenario, and
the .test function used in sget_fc() for bdev filesystems is
super_s_dev_test(), I considered adding an additional condition check
within that function.

I'm wondering if there's a better way to handle this...

Thanks,
Zizhi Wo

  reply	other threads:[~2025-07-19  4:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-19  2:44 [PATCH] fs: Add additional checks for block devices during mount Zizhi Wo
2025-07-19  4:17 ` Al Viro
2025-07-19  4:46   ` Zizhi Wo [this message]
2025-07-19 12:32 ` kernel test robot
2025-07-21  1:20   ` Zizhi Wo
2025-07-21  6:47     ` Christoph Hellwig
2025-07-21  7:05       ` Zizhi Wo
2025-07-23 12:51       ` Christian Brauner
2025-07-24  7:28         ` Christoph Hellwig
2025-07-24 11:26 ` Zizhi Wo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3bec1e49-e833-4e51-8bf5-3fa7f3defa86@huawei.com \
    --to=wozizhi@huawei.com \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=hch@lst.de \
    --cc=jack@suse.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=yangerkun@huawei.com \
    --cc=yukuai3@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.