From: "Coly Li" <colyli@fnnas.com>
To: "Jens Axboe" <axboe@kernel.dk>
Cc: <linux-block@vger.kerenl.org>, <linux-bcache@vger.kernel.org>,
"Mingzhe Zou" <mingzhe.zou@easystack.cn>
Subject: Re: [PATCH] bcache: fix uninitialized closure object
Date: Tue, 7 Apr 2026 22:09:56 +0800 [thread overview]
Message-ID: <F899796B-67C2-4131-AF4E-1A7AC8C7DA4B@fnnas.com> (raw)
In-Reply-To: <9e030c6f-f894-4794-81ca-e3c1a3ce5787@kernel.dk>
> 2026年4月7日 21:24,Jens Axboe <axboe@kernel.dk> 写道:
>
> On 4/7/26 7:19 AM, Coly Li wrote:
>>> 2026?4?7? 20:44?Jens Axboe <axboe@kernel.dk> ???
>>>
>>> On 4/7/26 3:28 AM, Coly Li wrote:
>>>>> 2026?4?3? 19:11?Jens Axboe <axboe@kernel.dk> ???
>>>>>
>>>>> On 4/2/26 10:21 PM, colyli@fnnas.com wrote:
>>>>>> From: Mingzhe Zou <mingzhe.zou@easystack.cn>
>>>>>>
>>>>>> In the previous patch ("bcache: fix cached_dev.sb_bio use-after-free and
>>>>>> crash"), we adopted a simple modification suggestion from AI to fix the
>>>>>> use-after-free.
>>>>>>
>>>>>> But in actual testing, we found an extreme case where the device is
>>>>>> stopped before calling bch_write_bdev_super().
>>>>>>
>>>>>> At this point, struct closure sb_write has not been initialized yet.
>>>>>> For this patch, we ensure that sb_bio has been completed via
>>>>>> sb_write_mutex.
>>>>>
>>>>> Presumably this should have a:
>>>>>
>>>>> Fixes: fec114a98b87 ("bcache: fix cached_dev.sb_bio use-after-free and crash")
>>>>>
>>>>> but for some reason it does not. I'll add it.
>>>>
>>>> I did it on purpose. Because this patch is in Linux-stable and not in mainline,
>>>> I am not sure whether it is proper to reference the linux-block tree commit id.
>>>>
>>>> This is why the patch title is mentioned in commit log, but commit id skipped.
>>>
>>> Why is the patch in stable and not in mainline?! That should generally
>>> never happen.
>>
>> Oops, My fingers movement diverged from my brain. I thought
>> linux-block, but typed linux-stable?.
>>
>> I meant, when the patch merged from linux-block to Linus tree, maybe
>> the commit id changes for some unexpected reason. So I didn?t
>> reference the Fixes tag with linux-block tree commit id.
>
> It'll never change going into Linus's tree, that's how git works. If I
> have a rare rebase for whatever reason, I fixup the Fixes shas. So
> always put them in there, there's never a reason NOT to do so.
This is a clear hint. Thanks.
Coly Li
next prev parent reply other threads:[~2026-04-07 14:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-03 4:21 [PATCH] bcache: fix uninitialized closure object colyli
2026-04-03 11:11 ` Jens Axboe
2026-04-07 9:28 ` Coly Li
2026-04-07 12:44 ` Jens Axboe
2026-04-07 13:19 ` Coly Li
2026-04-07 13:24 ` Jens Axboe
2026-04-07 14:09 ` Coly Li [this message]
2026-04-03 11:11 ` Jens Axboe
-- strict thread matches above, loose matches on Subject: below --
2026-04-02 13:03 mingzhe.zou
2026-04-03 4:04 ` Coly Li
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=F899796B-67C2-4131-AF4E-1A7AC8C7DA4B@fnnas.com \
--to=colyli@fnnas.com \
--cc=axboe@kernel.dk \
--cc=linux-bcache@vger.kernel.org \
--cc=linux-block@vger.kerenl.org \
--cc=mingzhe.zou@easystack.cn \
/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