[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aJ_rqOrxMsi3nDqq@fedora>
Date: Sat, 16 Aug 2025 10:23:36 +0800
From: Ming Lei <ming.lei@...hat.com>
To: Yu Kuai <yukuai@...nel.org>
Cc: Yu Kuai <yukuai1@...weicloud.com>, axboe@...nel.dk, hare@...e.de,
nilay@...ux.ibm.com, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org, yukuai3@...wei.com,
yi.zhang@...wei.com, yangerkun@...wei.com, johnny.chenyi@...wei.com
Subject: Re: [PATCH 04/10] blk-mq: serialize updating nr_requests with
update_nr_hwq_lock
On Sat, Aug 16, 2025 at 08:49:41AM +0800, Yu Kuai wrote:
> Hi,
>
> 在 2025/8/15 22:47, Ming Lei 写道:
> > On Fri, Aug 15, 2025 at 04:02:10PM +0800, Yu Kuai wrote:
> > > From: Yu Kuai <yukuai3@...wei.com>
> > >
> > > request_queue->nr_requests can be changed by:
> > >
> > > a) switching elevator by update nr_hw_queues
> > > b) switching elevator by elevator sysfs attribute
> > > c) configue queue sysfs attribute nr_requests
> > ->elevator_lock is grabbed for updating ->nr_requests except for queue
> > initialization, so what is the real problem you are trying to solve?
> >
> In order to fix the regression and prevent deadlock, we'll have to allocate
> memory
>
> in the case bitmap tags grow before freezing the queue, also prevent
> nr_requests
>
> to be updated by case a and b concurrently.
Yeah, that is potential deadlock issue in updating nr_request.
I feel the patch title is a bit confusing because q->nr_requests updating
is already serialized.
Thanks,
Ming
Powered by blists - more mailing lists