> 2022年6月20日 18:10，Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> 写道：
>
> On Sat, Jun 18, 2022 at 07:57:01PM +0800, Coly Li wrote:
>>
>>
>>> 2022年6月18日 19:37，Pavel Machek <pavel@xxxxxx> 写道：
>>>
>>> Hi!
>>>
>>>>>> Fixes: bc082a55d25c ("bcache: fix inaccurate io state for detached
>>>>> ...
>>>>>
>>>>>> +++ b/drivers/md/bcache/request.c
>>>>>> @@ -1107,6 +1107,12 @@ static void detached_dev_do_request(struct
>>>>>> bcache_device *d, struct bio *bio,
>>>>>> * which would call closure_get(&dc->disk.cl)
>>>>>> */
>>>>>> ddip = kzalloc(sizeof(struct detached_dev_io_private), GFP_NOIO);
>>>>>> + if (!ddip) {
>>>>>> + bio->bi_status = BLK_STS_RESOURCE;
>>>>>> + bio->bi_end_io(bio);
>>>>>> + return;
>>>>>> + }
>>>>>> +
>>>>>> ddip->d = d;
>>>>>> /* Count on the bcache device */
>>>>>> ddip->orig_bdev = orig_bdev;
>>>>>>
>>>>>
>>>>> So... for patch to make any difference, memory allocation has to fail
>>>>> and ddip has to be NULL.
>>>>>
>>>>> Before the patch, it would oops in "ddip->d = d;". With the patch, you
>>>>> do some kind of error handling. Even if it is buggy, it should not do
>>>>> more harm than immediate oops.
>>>>
>>>> I just receive this single email and don’t have any idea for the context and what the problem is. Where can I see the whole conversation?
>>>>
>>>
>>> Discussion happened on stable@xxxxxxxxxxxxxxx mailing lists, archives
>>> should be easily available. Copy went to lkml, too.
>>
>> Hi Pavel and Greg,
>>
>> Thanks for the hint, I see the context. I cannot tell the direct reason of the kfence regression, but it is worthy to have this patch in,
>> - commit 7d6b902ea0e0 ("bcache: memset on stack variables in bch_btree_check() and bch_sectors_dirty_init()”)
>>
>> I am not sure whether it is directly related to the kfence issue, it corrects potential unexpected stack state in some condition. Hope it may help a bit.
>
> Added where?
>
> confused,
I will post the patch to stable list for specific version. Thanks.
Coly Li
