mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Zizhi Wo <wozizhi@huawei.com>
To: Christoph Hellwig <hch@lst.de>, Zizhi Wo <wozizhi@huaweicloud.com>
Cc: kernel test robot <lkp@intel.com>, <viro@zeniv.linux.org.uk>,
	<jack@suse.com>, <brauner@kernel.org>, <axboe@kernel.dk>,
	<llvm@lists.linux.dev>, <oe-kbuild-all@lists.linux.dev>,
	<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: Mon, 21 Jul 2025 15:05:28 +0800	[thread overview]
Message-ID: <076aefb1-ec3a-471b-b299-5fa9a2a9495d@huawei.com> (raw)
In-Reply-To: <20250721064712.GA28899@lst.de>



在 2025/7/21 14:47, Christoph Hellwig 写道:
> On Mon, Jul 21, 2025 at 09:20:27AM +0800, Zizhi Wo wrote:
>> Sorry, disk_live() is only declared but not defined when CONFIG_BLOCK is
>> not set...
> 
> You can just add a if (IS_ENABLED(CONFIG_BLOCK)) check around it.

Yes, adding this judgment directly is also fine.

> 
> 
> But the layering here feels wrong.  sget_dev and it's helper operate
> purely on the dev_t.  Anything actually dealing with a block device /
> gendisk should be in the helpers that otherwise use it.
> 
> 

Do you mean performing the check outside of sget_dev()? That is, after
we obtain an existing superblock, we then check whether the block device
exists, and if it doesn't, we report the error in the outer layer (e.g.,
in get_tree_bdev_flags(), this function seems to be targeted at bdev
rather than just dev)?

Thanks,
Zizhi Wo

  reply	other threads:[~2025-07-21  7:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-19  2:44 Zizhi Wo
2025-07-19  4:17 ` Al Viro
2025-07-19  4:46   ` Zizhi Wo
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 [this message]
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=076aefb1-ec3a-471b-b299-5fa9a2a9495d@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=lkp@intel.com \
    --cc=llvm@lists.linux.dev \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=viro@zeniv.linux.org.uk \
    --cc=wozizhi@huaweicloud.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®