Re: [PATCH] bcache: fix uninitialized closure object

On 4/7/26 7:19 AM, Coly Li wrote:
>> 2026?4?7? 20:44?Jens Axboe <[email protected]> ???
>>
>> On 4/7/26 3:28 AM, Coly Li wrote:
>>>> 2026?4?3? 19:11?Jens Axboe <[email protected]> ???
>>>>
>>>> On 4/2/26 10:21 PM, [email protected] wrote:
>>>>> From: Mingzhe Zou <[email protected]>
>>>>>
>>>>> 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.

-- 
Jens Axboe