[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e15833f9-c18b-4783-af01-42f44a9cecb3@kernel.dk>
Date: Fri, 5 Sep 2025 13:52:39 -0600
From: Jens Axboe <axboe@...nel.dk>
To: Yu Kuai <yukuai1@...weicloud.com>, bvanassche@....org,
ming.lei@...hat.com, nilay@...ux.ibm.com, hare@...e.de
Cc: linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
yi.zhang@...wei.com, yangerkun@...wei.com, johnny.chenyi@...wei.com,
"yukuai (C)" <yukuai3@...wei.com>
Subject: Re: [PATCH v3 0/2] blk-mq: fix update nr_requests regressions
On 9/5/25 1:20 AM, Yu Kuai wrote:
> Hi, Jens
>
> ? 2025/08/26 14:27, Yu Kuai ??:
>> Hi, Jens
>>
>> ? 2025/08/21 14:06, Yu Kuai ??:
>>> From: Yu Kuai <yukuai3@...wei.com>
>>>
>>> Changes in v3:
>>> - call depth_updated() directly in init_sched() method in patch 1;
>>> - fix typos in patch 2;
>>> - add review for patch 2;
>>> Changes in v2:
>>> - instead of refactor and cleanups and fix updating nr_requests
>>> thoroughly, fix the regression in patch 2 the easy way, and dealy
>>> refactor and cleanups to next merge window.
>>>
>>> patch 1 fix regression that elevator async_depth is not updated correctly
>>> if nr_requests changes, first from error path and then for mq-deadline,
>>> and recently for bfq and kyber.
>>>
>>> patch 2 fix regression that if nr_requests grow, kernel will panic due
>>> to tags double free.
>>>
>>> Yu Kuai (2):
>>> blk-mq: fix elevator depth_updated method
>>> blk-mq: fix blk_mq_tags double free while nr_requests grown
>>>
>>> block/bfq-iosched.c | 22 +++++-----------------
>>> block/blk-mq-sched.h | 11 +++++++++++
>>> block/blk-mq-tag.c | 1 +
>>> block/blk-mq.c | 23 ++++++++++++-----------
>>> block/elevator.h | 2 +-
>>> block/kyber-iosched.c | 19 +++++++++----------
>>> block/mq-deadline.c | 16 +++-------------
>>> 7 files changed, 42 insertions(+), 52 deletions(-)
>>>
>>
>> Friendly ping, please consider this set in this merge window.
>>
>> BTW, I see that for-6.18/block branch was created, however, I have
>> a pending set[1] for the next merge window that will have conflicts with
>> this set, not sure if you want to rebase for-6.18/block with block-6.17
>> or handle conflicts later for 6.18-rc1.
I think we're just a bit late on this one, given that they'd go into
-rc6 at this point. Going to queue this up for 6.18 and then we just get
it into stable instead, that gives us a lot more time to shake out any
potential issues.
--
Jens Axboe
Powered by blists - more mailing lists