From: Dongsheng Yang <dongsheng.yang@linux.dev>
To: Li Chen <me@linux.beauty>
Cc: Zheng Gu <cengku@gmail.com>, dm-devel <dm-devel@lists.linux.dev>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/3] dm-pcache: avoid leaking invalid metadata in pcache_meta_find_latest()
Date: Wed, 5 Nov 2025 09:16:12 +0800 [thread overview]
Message-ID: <fcfae11d-8719-4641-9db9-43806d971668@linux.dev> (raw)
In-Reply-To: <19a4f153cdf.4d1effd9893048.2344913209212358613@linux.beauty>
在 11/4/2025 9:36 PM, Li Chen 写道:
> Hi Dongsheng,
>
>
> ---- On Tue, 04 Nov 2025 14:46:33 +0800 Dongsheng Yang <dongsheng.yang@linux.dev> wrote ---
> >
> > 在 11/1/2025 9:10 PM, Li Chen 写道:
> > > Hi Zheng,
> > >
> > > ---- On Fri, 31 Oct 2025 10:01:23 +0800 Zheng Gu <cengku@gmail.com> wrote ---
> > > >> On Thu, Oct 30, 2025 at 8:36 PM Li Chen <me@linux.beauty> wrote:From: Li Chen <chenl311@chinatelecom.cn>
> > > >>
> > > >> Before this change pcache_meta_find_latest() was copying each
> > > >> slot directly into meta_ret while scanning. If no valid slot
> > > >> was found and the function returned NULL, meta_ret still held
> > > >> whatever was last copied (possibly CRC-bad). Later users
> > > >> (e.g. cache_segs_init) could mistakenly trust that data.
> > > >
> > > > This functions is * __must_check*, users must check the return value first before touching the meta_ret, so it should not be a problem here.
> > >
> > > Right now, the callers only check the return value with IS_ERR(). If the
> > > function returns NULL instead of an error pointer, a caller like
> > > cache_info_init() will assume that no valid cache_info was found because all cache_info are
> > > corrupted. Instead, it will try to init a new one, and then return 0 (success),
> > > https://github.com/torvalds/linux/blob/master/drivers/md/dm-pcache/cache.c#L61
> > >
> > > Later, cache_tail_init() will access cache->cache_info.flags. But in this
> > > path all cache_info may have already been corrupted, and the CRCs are mismatched
> > > (https://github.com/torvalds/linux/blob/ba36dd5ee6fd4643ebbf6ee6eefcecf0b07e35c7/drivers/md/dm-pcache/pcache_internal.h#L97),
> > > so flags may contain garbage.
> > >
> > > This commit fixes this issue by allocating a temp buffer with kvmalloc, so meta_ret would never
> > > contain corrupted values.
> >
> > Hi
> >
> > Thanx for your fix. So the better change should be reseting
> > cache_info in cache_info_init_default() firstly by memset() with 0.
> >
> > Allocating a temp buffer in pcache_meta_find_latest() is really not a
> > good idea.
>
> I considered using memset before sending the patch, but a temporary buffer seems more elegant.
> Since the variable is relatively large, I avoided stack allocation. If you prefer memset, should it be implemented
> within pcache_meta_find_latest or all its callers?
callers should do this thing, it's about default value initialization,
the callers understand what to do, but pcache_meta_find_latest() does not.
So the usage looks like below:
meta = pcache_meta_find_latest();
If meta is error, return error.
If meta is not NULL, meta is valid, just use it.
If meta is NULL, that means there is no valid meta onmedia, just init it
with default value (including cache_info.flags you mentioned, the
default of this flags should be 0).
BTW, when you memset cache_info with 0 in cache_info_init_default();,
you can remove this line: cache_info->header.seq = 0;
Thanx
>
> Regards,
>
> Li
>
next prev parent reply other threads:[~2025-11-05 1:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-30 12:33 [PATCH 0/3] dm-pcache: built-in support and metadata hardening Li Chen
2025-10-30 12:33 ` [PATCH 1/3] dm-pcache: allow built-in build and rename flush helper Li Chen
2025-10-30 12:33 ` [PATCH 2/3] dm-pcache: reuse meta_addr in pcache_meta_find_latest Li Chen
2025-10-30 12:33 ` [PATCH 3/3] dm-pcache: avoid leaking invalid metadata in pcache_meta_find_latest() Li Chen
[not found] ` <CADSj-VoQerDc2UUfBOknRMGetSddMEqRKaC3VDniD+xCq0pH1g@mail.gmail.com>
2025-11-01 13:10 ` Li Chen
2025-11-04 6:46 ` Dongsheng Yang
2025-11-04 13:36 ` Li Chen
2025-11-05 1:16 ` Dongsheng Yang [this message]
2025-11-03 11:38 ` Jonathan Cameron
2025-11-04 12:19 ` Li Chen
-- strict thread matches above, loose matches on Subject: below --
2025-11-05 8:46 [PATCH 0/3] dm-pcache: built-in support and metadata hardening Li Chen
2025-11-05 8:46 ` [PATCH 3/3] dm-pcache: avoid leaking invalid metadata in pcache_meta_find_latest() Li Chen
2025-11-10 11:18 ` Dongsheng Yang
2025-11-10 12:32 ` Li Chen
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=fcfae11d-8719-4641-9db9-43806d971668@linux.dev \
--to=dongsheng.yang@linux.dev \
--cc=cengku@gmail.com \
--cc=dm-devel@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=me@linux.beauty \
/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