From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: Chao Yu <chao@kernel.org>
Cc: linux-kernel@vger.kernel.org,
Hongzhen Luo <hongzhen@linux.alibaba.com>,
linux-erofs mailing list <linux-erofs@lists.ozlabs.org>
Subject: Re: [PATCH v5] erofs: use Z_EROFS_LCLUSTER_TYPE_MAX to simplify switches
Date: Mon, 17 Mar 2025 14:15:16 +0800 [thread overview]
Message-ID: <18767765-53b5-4e78-b50d-9305fe1cb2d0@linux.alibaba.com> (raw)
In-Reply-To: <04050888-7abf-40fa-98d6-6215b8ba989e@kernel.org>
Hi Chao,
On 2025/3/17 14:03, Chao Yu wrote:
> On 3/17/25 01:17, Gao Xiang wrote:
>> Hi Chao,
>>
...
>>
>> Previously, it was useful before Z_EROFS_LCLUSTER_TYPE_HEAD2 was
>> introduced, but the `default:` case is already deadcode now.
>
> Xiang, thanks for the explanation.
>
> So seems it can happen when mounting last image w/ old kernel which can not
> support newly introduced Z_EROFS_LCLUSTER_TYPE_* type, then it makes sense to
> return EOPNOTSUPP.
Yeah.
>
>>
>>>
>>> Btw, we'd better to do sanity check for m->type in z_erofs_load_full_lcluster(),
>>> then we can treat m->type as reliable variable later.
>>>
>>> advise = le16_to_cpu(di->di_advise);
>>> m->type = advise & Z_EROFS_LI_LCLUSTER_TYPE_MASK;
>>> if (m->type >= Z_EROFS_LCLUSTER_TYPE_MAX) {
>>
>> It's always false here.
>
> So, what do you think of this?
>
> From af584b2eacd468f145e9ee31ccdeedb7355d5afd Mon Sep 17 00:00:00 2001
> From: Chao Yu <chao@kernel.org>
> Date: Mon, 17 Mar 2025 13:57:55 +0800
> Subject: [PATCH] erofs: remove dead codes for cleanup
>
> z_erofs_extent_lookback() and z_erofs_get_extent_decompressedlen() tries
> to do sanity check on m->type, however their caller z_erofs_map_blocks_fo()
> has already checked that, so let's remove those dead codes.
z_erofs_extent_lookback() will (lookback) read new lcn in
z_erofs_load_lcluster_from_disk() so it won't be covered by
the original z_erofs_map_blocks_fo().
I think this check can be resolved in
z_erofs_load_lcluster_from_disk() instead but maybe address
for the next cycle? since there are already enough features
for this cycle and I have to make sure no major issues....
Thanks,
Gao Xiang
next prev parent reply other threads:[~2025-03-17 6:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-10 3:29 [PATCH v5] erofs: use Z_EROFS_LCLUSTER_TYPE_MAX to simplify switches Hongzhen Luo
2025-02-10 8:27 ` Gao Xiang
2025-03-16 2:36 ` Chao Yu
2025-03-16 17:17 ` Gao Xiang
2025-03-16 17:19 ` Gao Xiang
2025-03-17 6:03 ` Chao Yu
2025-03-17 6:15 ` Gao Xiang [this message]
2025-03-17 6:42 ` Chao Yu
2025-03-17 6:43 ` Gao Xiang
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=18767765-53b5-4e78-b50d-9305fe1cb2d0@linux.alibaba.com \
--to=hsiangkao@linux.alibaba.com \
--cc=chao@kernel.org \
--cc=hongzhen@linux.alibaba.com \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-kernel@vger.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;
as well as URLs for NNTP newsgroup(s).