Re: [PATCH] bcache: fix uninitialized closure object

> 2026=E5=B9=B44=E6=9C=887=E6=97=A5 20:44=EF=BC=8CJens Axboe <axboe@kernel.=
dk> =E5=86=99=E9=81=93=EF=BC=9A
>=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 a=
nd
>>>> crash"), we adopted a simple modification suggestion from AI to fix th=
e
>>>> 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 and =
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 ma=
inline,
>> I am not sure whether it is proper to reference the linux-block tree com=
mit id.
>>=20
>> This is why the patch title is mentioned in commit log, but commit id sk=
ipped.
>=20
> 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, bu=
t typed linux-stable=E2=80=A6.

I meant, when the patch merged from linux-block to Linus tree, maybe the co=
mmit id changes
for some unexpected reason. So I didn=E2=80=99t reference the Fixes tag wit=
h linux-block tree commit
id.

Coly Li