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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <34cbdb0b-28f4-4408-83b1-198f55427b5c@linux.alibaba.com>
Date: Tue, 8 Oct 2024 20:10:45 +0800
From: Gao Xiang <hsiangkao@...ux.alibaba.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: Christian Brauner <brauner@...nel.org>,
 Alexander Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>,
 Allison Karlitskaya <allison.karlitskaya@...hat.com>,
 Chao Yu <chao@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
 linux-fsdevel@...r.kernel.org, linux-erofs@...ts.ozlabs.org
Subject: Re: [PATCH 1/2] fs/super.c: introduce get_tree_bdev_by_dev()

Hi Christoph,

On 2024/10/8 19:49, Christoph Hellwig wrote:
> On Tue, Oct 08, 2024 at 05:56:05PM +0800, Gao Xiang wrote:
>> As Allison reported [1], currently get_tree_bdev() will store
>> "Can't lookup blockdev" error message.  Although it makes sense for
>> pure bdev-based fses, this message may mislead users who try to use
>> EROFS file-backed mounts since get_tree_nodev() is used as a fallback
>> then.
>>
>> Add get_tree_bdev_by_dev() to specify a device number explicitly
>> instead of the hardcoded fc->source as mentioned in [2], there are
>> other benefits like:
>>    - Filesystems can have other ways to get a bdev-based sb
>>      in addition to the current hard-coded source path;
>>
>>    - Pseudo-filesystems can utilize this method to generate a
>>      filesystem from given device numbers too.
>>
>>    - Like get_tree_nodev(), it doesn't strictly tie to fc->source
>>      either.
> 
> Do you have concrete plans for any of those?  If so send pointers.

Thanks for your comment.

I don't have any pointer for now, just listing the potential use
cases for reference.

But the error message out of get_tree_bdev() is inflexible and
IMHO it's too coupled to `fc->source`.

> Otherwise just passing a quiet flag of some form feels like a much
> saner interface.

I'm fine with this way, but that will be a treewide change, I
will send out a version with a flag later.

Thanks,
Gao Xiang

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ