Linux block layer
 help / color / mirror / Atom feed
From: Yu Kuai <yukuai@kernel.org>
To: Jan Kara <jack@suse.cz>
Cc: dlemoal@kernel.org, axboe@kernel.dk, linux-block@vger.kernel.org,
	linux-kernel@vger.kernel.org, yukuai3@huawei.com,
	yi.zhang@huawei.com, yangerkun@huawei.com,
	johnny.chenyi@huawei.com
Subject: Re: [PATCH v2] blk-ioc: don't hold queue_lock for ioc_lookup_icq()
Date: Tue, 29 Jul 2025 01:08:40 +0800	[thread overview]
Message-ID: <9dc51c34-1e5d-4da2-bc00-a89e7c173073@kernel.org> (raw)
In-Reply-To: <64sbgvovtubkm2zelenee6pjkdciqlgqmri3bmycce6y265sy4@uptdqvz7g2lk>

Hi,

在 2025/7/28 17:28, Jan Kara 写道:
> On Sat 26-07-25 02:03:34, Yu Kuai wrote:
>> From: Yu Kuai <yukuai3@huawei.com>
>>
>> Currently issue io can grab queue_lock three times from bfq_bio_merge(),
>> bfq_limit_depth() and bfq_prepare_request(), the queue_lock is not
>> necessary if icq is already created because both queue and ioc can't be
>> freed before io issuing is done, hence remove the unnecessary queue_lock
>> and use rcu to protect radix tree lookup.
>>
>> Noted this is also a prep patch to support request batch dispatching[1].
>>
>> [1] https://lore.kernel.org/all/20250722072431.610354-1-yukuai1@huaweicloud.com/
>> Signed-off-by: Yu Kuai <yukuai3@huawei.com>
> Looks good! Just one small comment below. With that fixed feel free to add:
>
> Reviewed-by: Jan Kara <jack@suse.cz>
>
>> diff --git a/block/blk-ioc.c b/block/blk-ioc.c
>> index ce82770c72ab..ea9c975aaef7 100644
>> --- a/block/blk-ioc.c
>> +++ b/block/blk-ioc.c
>> @@ -308,19 +308,18 @@ int __copy_io(unsigned long clone_flags, struct task_struct *tsk)
>>   
>>   #ifdef CONFIG_BLK_ICQ
>>   /**
>> - * ioc_lookup_icq - lookup io_cq from ioc
>> + * ioc_lookup_icq - lookup io_cq from ioc in io issue path
>>    * @q: the associated request_queue
>>    *
>>    * Look up io_cq associated with @ioc - @q pair from @ioc.  Must be called
>> - * with @q->queue_lock held.
>> + * from io issue path, either return NULL if current issue io to @q for the
>> + * first time, or return a valid icq.
>>    */
>>   struct io_cq *ioc_lookup_icq(struct request_queue *q)
>>   {
>>   	struct io_context *ioc = current->io_context;
>>   	struct io_cq *icq;
>>   
>> -	lockdep_assert_held(&q->queue_lock);
>> -
>>   	/*
>>   	 * icq's are indexed from @ioc using radix tree and hint pointer,
>>   	 * both of which are protected with RCU.  All removals are done
> In this comment there's still reference to holding 'q lock'. I think you
> should replace that with justification why when called from IO issue path
> we are guaranteed found pointer is safe to use.
Thanks for the review! How about:

diff --git a/block/blk-ioc.c b/block/blk-ioc.c
index ea9c975aaef7..fd77e655544f 100644
--- a/block/blk-ioc.c
+++ b/block/blk-ioc.c
@@ -322,9 +322,9 @@ struct io_cq *ioc_lookup_icq(struct request_queue *q)

         /*
          * icq's are indexed from @ioc using radix tree and hint pointer,
-        * both of which are protected with RCU.  All removals are done
-        * holding both q and ioc locks, and we're holding q lock - if we
-        * find a icq which points to us, it's guaranteed to be valid.
+        * both of which are protected with RCU, io issue path ensures that
+        * both request_queue and current task are valid, the founded icq
+        * is guaranteed to be valid until the io is done.
          */
         rcu_read_lock();
         icq = rcu_dereference(ioc->icq_hint);

>
> 								Honza


  reply	other threads:[~2025-07-28 17:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-25 18:03 [PATCH v2] blk-ioc: don't hold queue_lock for ioc_lookup_icq() Yu Kuai
2025-07-28  3:53 ` Damien Le Moal
2025-07-28  9:28 ` Jan Kara
2025-07-28 17:08   ` Yu Kuai [this message]
2025-07-28 21:45     ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9dc51c34-1e5d-4da2-bc00-a89e7c173073@kernel.org \
    --to=yukuai@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=dlemoal@kernel.org \
    --cc=jack@suse.cz \
    --cc=johnny.chenyi@huawei.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yangerkun@huawei.com \
    --cc=yi.zhang@huawei.com \
    --cc=yukuai3@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox