Re: [PATCH] bcache: fix uninitialized closure object

> 2026=E5=B9=B44=E6=9C=887=E6=97=A5 21:24=EF=BC=8CJens Axboe <axboe@kernel.=
dk> =E5=86=99=E9=81=93=EF=BC=9A
>=20
> On 4/7/26 7:19 AM, Coly Li wrote:
>>> 2026?4?7? 20:44?Jens Axboe <[email protected]> ???
>>>=20
>>> On 4/7/26 3:28 AM, Coly Li wrote:
>>>>> 2026?4?3? 19:11?Jens Axboe <[email protected]> ???
>>>>>=20
>>>>> On 4/2/26 10:21 PM, [email protected] wrote:
>>>>>> From: Mingzhe Zou <[email protected]>
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> But in actual testing, we found an extreme case where the device is
>>>>>> stopped before calling bch_write_bdev_super().
>>>>>>=20
>>>>>> 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.
>>>>>=20
>>>>> Presumably this should have a:
>>>>>=20
>>>>> Fixes: fec114a98b87 ("bcache: fix cached_dev.sb_bio use-after-free an=
d crash")
>>>>>=20
>>>>> but for some reason it does not. I'll add it.
>>>>=20
>>>> 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 c=
ommit id.
>>>>=20
>>>> This is why the patch title is mentioned in commit log, but commit id =
skipped.
>>>=20
>>> Why is the patch in stable and not in mainline?! That should generally
>>> never happen.
>>=20
>> Oops, My fingers movement diverged from my brain. I thought
>> linux-block, but typed linux-stable?.
>>=20
>> 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.
>=20
> 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