public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: Christian Brauner <brauner@kernel.org>, Gao Xiang <xiang@kernel.org>
Cc: Allison Karlitskaya <allison.karlitskaya@redhat.com>,
	Chao Yu <chao@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org, linux-erofs@lists.ozlabs.org,
	Alexander Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH v2 1/2] fs/super.c: introduce get_tree_bdev_flags()
Date: Mon, 21 Oct 2024 15:54:12 +0800	[thread overview]
Message-ID: <ab1a99aa-4732-4df6-97c0-e06cca2527e3@linux.alibaba.com> (raw)
In-Reply-To: <20241010-bauordnung-keramik-eb5d35f6eb28@brauner>

Hi Christian,

On 2024/10/10 17:48, Christian Brauner wrote:
> On Wed, 09 Oct 2024 11:31:50 +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_flags() to specify extensible flags [2] and
>> GET_TREE_BDEV_QUIET_LOOKUP to silence "Can't lookup blockdev" message
>> since it's misleading to EROFS file-backed mounts now.
>>
>> [...]
> 
> Applied to the vfs.misc branch of the vfs/vfs.git tree.
> Patches in the vfs.misc branch should appear in linux-next soon.
> 
> Please report any outstanding bugs that were missed during review in a
> new review to the original patch series allowing us to drop it.
> 
> It's encouraged to provide Acked-bys and Reviewed-bys even though the
> patch has now been applied. If possible patch trailers will be updated.
> 
> Note that commit hashes shown below are subject to change due to rebase,
> trailer updates or similar. If in doubt, please check the listed branch.
> 
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
> branch: vfs.misc
> 
> [1/2] fs/super.c: introduce get_tree_bdev_flags()
>        https://git.kernel.org/vfs/vfs/c/f54acb32dff2
> [2/2] erofs: use get_tree_bdev_flags() to avoid misleading messages
>        https://git.kernel.org/vfs/vfs/c/83e6e973d9c9

Anyway, I'm not sure what's your thoughts about this, so I try to
write an email again.

As Allison suggested in the email [1], "..so probably it should get
fixed before the final release.".  Although I'm pretty fine to leave
it in "vfs.misc" for the next merge window (6.13) instead, it could
cause an unnecessary backport to the stable kernel.

Or if there is some other potential concern about these two patches?
Also I hope my previous reply about a redundant blank line removal
in the first patch might be useful too [2].

[1] https://lore.kernel.org/r/CAOYeF9VQ8jKVmpy5Zy9DNhO6xmWSKMB-DO8yvBB0XvBE7=3Ugg@mail.gmail.com
[2] https://lore.kernel.org/r/8ec1896f-93da-4eca-ab69-8ae9d1645181@linux.alibaba.com

Thanks,
Gao Xiang

  reply	other threads:[~2024-10-21  7:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-09  3:31 [PATCH v2 1/2] fs/super.c: introduce get_tree_bdev_flags() Gao Xiang
2024-10-09  3:31 ` [PATCH v2 2/2] erofs: use get_tree_bdev_flags() to avoid misleading messages Gao Xiang
2024-10-09  7:31   ` Christoph Hellwig
2024-10-09  7:37     ` Gao Xiang
2024-10-09 16:57       ` Gao Xiang
2024-10-09  7:30 ` [PATCH v2 1/2] fs/super.c: introduce get_tree_bdev_flags() Christoph Hellwig
2024-10-09 15:04 ` Jan Kara
2024-10-10  9:48 ` Christian Brauner
2024-10-21  7:54   ` Gao Xiang [this message]
2024-10-21 12:27     ` Christian Brauner
2024-10-21 12:34       ` Gao Xiang
2024-10-21 12:32 ` Christian Brauner

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=ab1a99aa-4732-4df6-97c0-e06cca2527e3@linux.alibaba.com \
    --to=hsiangkao@linux.alibaba.com \
    --cc=allison.karlitskaya@redhat.com \
    --cc=brauner@kernel.org \
    --cc=chao@kernel.org \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=xiang@kernel.org \
    /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