The Linux Kernel Mailing List
 help / color / mirror / Atom feed
* [PATCH 0/3] blk-ioc: convert ioc_lookup_icq() to lockless version
@ 2025-07-25  7:05 Yu Kuai
  2025-07-25  7:05 ` [PATCH 1/3] blk-ioc: add a new helper ioc_lookup_icq_rcu() Yu Kuai
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Yu Kuai @ 2025-07-25  7:05 UTC (permalink / raw)
  To: jack, dlemoal, axboe
  Cc: linux-block, linux-kernel, yukuai3, yukuai1, yi.zhang, yangerkun,
	johnny.chenyi

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.

This set first add a lockless helper ioc_lookup_icq_rcu() and then
covert to use the new helper.

Noted this is also a prep set to support request batch dispatching[1].

1. https://lore.kernel.org/all/20250722072431.610354-1-yukuai1@huaweicloud.com/

Yu Kuai (3):
  blk-ioc: add a new helper ioc_lookup_icq_rcu()
  block, bfq: convert to use ioc_lookup_icq_rcu()
  blk-ioc: convert to use ioc_lookup_icq_rcu()

 block/bfq-iosched.c | 23 ++++++-----------------
 block/blk-ioc.c     | 46 ++++++++++++++++++++++-----------------------
 block/blk.h         |  2 +-
 3 files changed, 29 insertions(+), 42 deletions(-)

-- 
2.39.2


^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH 1/3] blk-ioc: add a new helper ioc_lookup_icq_rcu()
  2025-07-25  7:05 [PATCH 0/3] blk-ioc: convert ioc_lookup_icq() to lockless version Yu Kuai
@ 2025-07-25  7:05 ` Yu Kuai
  2025-07-25 10:21   ` Damien Le Moal
  2025-07-25  7:05 ` [PATCH 2/3] block, bfq: convert to use ioc_lookup_icq_rcu() Yu Kuai
  2025-07-25  7:05 ` [PATCH 3/3] blk-ioc: " Yu Kuai
  2 siblings, 1 reply; 7+ messages in thread
From: Yu Kuai @ 2025-07-25  7:05 UTC (permalink / raw)
  To: jack, dlemoal, axboe
  Cc: linux-block, linux-kernel, yukuai3, yukuai1, yi.zhang, yangerkun,
	johnny.chenyi

From: Yu Kuai <yukuai3@huawei.com>

ioc_lookup_icq() is used by bfq to lookup bfqq from IO path, the helper
have to be protected by queue_lock, which is too heavy. Hence add a new
helper that is lookless, this is safe because both request_queue and ioc
can be pinged by IO that is still issuing.

Signed-off-by: Yu Kuai <yukuai3@huawei.com>
---
 block/blk-ioc.c | 34 ++++++++++++++++++++++++++++++++++
 block/blk.h     |  1 +
 2 files changed, 35 insertions(+)

diff --git a/block/blk-ioc.c b/block/blk-ioc.c
index ce82770c72ab..4945b48dfdb6 100644
--- a/block/blk-ioc.c
+++ b/block/blk-ioc.c
@@ -343,6 +343,40 @@ struct io_cq *ioc_lookup_icq(struct request_queue *q)
 }
 EXPORT_SYMBOL(ioc_lookup_icq);
 
+/**
+ * ioc_lookup_icq_rcu - lookup io_cq from ioc in io path
+ * @q: the associated request_queue
+ *
+ * Look up io_cq associated with @ioc - @q pair from @ioc. Must be called 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_rcu(struct request_queue *q)
+{
+	struct io_context *ioc = current->io_context;
+	struct io_cq *icq;
+
+	WARN_ON_ONCE(percpu_ref_is_zero(&q->q_usage_counter));
+
+	if (!ioc)
+		return NULL;
+
+	icq = rcu_dereference(ioc->icq_hint);
+	if (icq && icq->q == q)
+		return icq;
+
+	icq = radix_tree_lookup(&ioc->icq_tree, q->id);
+	if (!icq)
+		return NULL;
+
+	if (WARN_ON_ONCE(icq->q != q))
+		return NULL;
+
+	rcu_assign_pointer(ioc->icq_hint, icq);
+	return icq;
+}
+EXPORT_SYMBOL(ioc_lookup_icq_rcu);
+
 /**
  * ioc_create_icq - create and link io_cq
  * @q: request_queue of interest
diff --git a/block/blk.h b/block/blk.h
index 468aa83c5a22..ef31b3ec1c69 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -461,6 +461,7 @@ static inline void req_set_nomerge(struct request_queue *q, struct request *req)
  */
 struct io_cq *ioc_find_get_icq(struct request_queue *q);
 struct io_cq *ioc_lookup_icq(struct request_queue *q);
+struct io_cq *ioc_lookup_icq_rcu(struct request_queue *q);
 #ifdef CONFIG_BLK_ICQ
 void ioc_clear_queue(struct request_queue *q);
 #else
-- 
2.39.2


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [PATCH 2/3] block, bfq: convert to use ioc_lookup_icq_rcu()
  2025-07-25  7:05 [PATCH 0/3] blk-ioc: convert ioc_lookup_icq() to lockless version Yu Kuai
  2025-07-25  7:05 ` [PATCH 1/3] blk-ioc: add a new helper ioc_lookup_icq_rcu() Yu Kuai
@ 2025-07-25  7:05 ` Yu Kuai
  2025-07-25  7:05 ` [PATCH 3/3] blk-ioc: " Yu Kuai
  2 siblings, 0 replies; 7+ messages in thread
From: Yu Kuai @ 2025-07-25  7:05 UTC (permalink / raw)
  To: jack, dlemoal, axboe
  Cc: linux-block, linux-kernel, yukuai3, yukuai1, yi.zhang, yangerkun,
	johnny.chenyi

From: Yu Kuai <yukuai3@huawei.com>

ioc_lookup_icq() are all called from IO issue path with queue_lock held,
convert to use ioc_lookup_icq_rcu() to get rid of the disk level spin
lock.

Signed-off-by: Yu Kuai <yukuai3@huawei.com>
---
 block/bfq-iosched.c | 23 ++++++-----------------
 1 file changed, 6 insertions(+), 17 deletions(-)

diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 0cb1e9873aab..b3b9dbbc16d2 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -454,17 +454,13 @@ static struct bfq_io_cq *icq_to_bic(struct io_cq *icq)
  */
 static struct bfq_io_cq *bfq_bic_lookup(struct request_queue *q)
 {
-	struct bfq_io_cq *icq;
-	unsigned long flags;
-
-	if (!current->io_context)
-		return NULL;
+	struct io_cq *icq;
 
-	spin_lock_irqsave(&q->queue_lock, flags);
-	icq = icq_to_bic(ioc_lookup_icq(q));
-	spin_unlock_irqrestore(&q->queue_lock, flags);
+	rcu_read_lock();
+	icq = ioc_lookup_icq_rcu(q);
+	rcu_read_unlock();
 
-	return icq;
+	return icq_to_bic(icq);
 }
 
 /*
@@ -2457,15 +2453,8 @@ static bool bfq_bio_merge(struct request_queue *q, struct bio *bio,
 		unsigned int nr_segs)
 {
 	struct bfq_data *bfqd = q->elevator->elevator_data;
-	struct request *free = NULL;
-	/*
-	 * bfq_bic_lookup grabs the queue_lock: invoke it now and
-	 * store its return value for later use, to avoid nesting
-	 * queue_lock inside the bfqd->lock. We assume that the bic
-	 * returned by bfq_bic_lookup does not go away before
-	 * bfqd->lock is taken.
-	 */
 	struct bfq_io_cq *bic = bfq_bic_lookup(q);
+	struct request *free = NULL;
 	bool ret;
 
 	spin_lock_irq(&bfqd->lock);
-- 
2.39.2


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [PATCH 3/3] blk-ioc: convert to use ioc_lookup_icq_rcu()
  2025-07-25  7:05 [PATCH 0/3] blk-ioc: convert ioc_lookup_icq() to lockless version Yu Kuai
  2025-07-25  7:05 ` [PATCH 1/3] blk-ioc: add a new helper ioc_lookup_icq_rcu() Yu Kuai
  2025-07-25  7:05 ` [PATCH 2/3] block, bfq: convert to use ioc_lookup_icq_rcu() Yu Kuai
@ 2025-07-25  7:05 ` Yu Kuai
  2 siblings, 0 replies; 7+ messages in thread
From: Yu Kuai @ 2025-07-25  7:05 UTC (permalink / raw)
  To: jack, dlemoal, axboe
  Cc: linux-block, linux-kernel, yukuai3, yukuai1, yi.zhang, yangerkun,
	johnny.chenyi

From: Yu Kuai <yukuai3@huawei.com>

Now ioc_lookup_icq() is only called from bfq_prepare_request() from
IO issue path, if it's the first time current issue IO to the disk,
'queue_lock' will be held to creat new icq, otherwise it's safe to
use the new helper. Noted if multiple task share one ioc, and
ioc_create_icq() raced, queue_lock is used to serialize them and only
the first one can succeed inserting icq to ioc.

Also remove ioc_lookup_icq() that is not used now.

Signed-off-by: Yu Kuai <yukuai3@huawei.com>
---
 block/blk-ioc.c | 44 ++++----------------------------------------
 block/blk.h     |  1 -
 2 files changed, 4 insertions(+), 41 deletions(-)

diff --git a/block/blk-ioc.c b/block/blk-ioc.c
index 4945b48dfdb6..27dd65957853 100644
--- a/block/blk-ioc.c
+++ b/block/blk-ioc.c
@@ -307,42 +307,6 @@ int __copy_io(unsigned long clone_flags, struct task_struct *tsk)
 }
 
 #ifdef CONFIG_BLK_ICQ
-/**
- * ioc_lookup_icq - lookup io_cq from ioc
- * @q: the associated request_queue
- *
- * Look up io_cq associated with @ioc - @q pair from @ioc.  Must be called
- * with @q->queue_lock held.
- */
-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
-	 * 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.
-	 */
-	rcu_read_lock();
-	icq = rcu_dereference(ioc->icq_hint);
-	if (icq && icq->q == q)
-		goto out;
-
-	icq = radix_tree_lookup(&ioc->icq_tree, q->id);
-	if (icq && icq->q == q)
-		rcu_assign_pointer(ioc->icq_hint, icq);	/* allowed to race */
-	else
-		icq = NULL;
-out:
-	rcu_read_unlock();
-	return icq;
-}
-EXPORT_SYMBOL(ioc_lookup_icq);
-
 /**
  * ioc_lookup_icq_rcu - lookup io_cq from ioc in io path
  * @q: the associated request_queue
@@ -420,7 +384,7 @@ static struct io_cq *ioc_create_icq(struct request_queue *q)
 			et->ops.init_icq(icq);
 	} else {
 		kmem_cache_free(et->icq_cache, icq);
-		icq = ioc_lookup_icq(q);
+		icq = ioc_lookup_icq_rcu(q);
 		if (!icq)
 			printk(KERN_ERR "cfq: icq link failed!\n");
 	}
@@ -454,9 +418,9 @@ struct io_cq *ioc_find_get_icq(struct request_queue *q)
 	} else {
 		get_io_context(ioc);
 
-		spin_lock_irq(&q->queue_lock);
-		icq = ioc_lookup_icq(q);
-		spin_unlock_irq(&q->queue_lock);
+		rcu_read_lock();
+		icq = ioc_lookup_icq_rcu(q);
+		rcu_read_unlock();
 	}
 
 	if (!icq) {
diff --git a/block/blk.h b/block/blk.h
index ef31b3ec1c69..3c078e517d59 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -460,7 +460,6 @@ static inline void req_set_nomerge(struct request_queue *q, struct request *req)
  * Internal io_context interface
  */
 struct io_cq *ioc_find_get_icq(struct request_queue *q);
-struct io_cq *ioc_lookup_icq(struct request_queue *q);
 struct io_cq *ioc_lookup_icq_rcu(struct request_queue *q);
 #ifdef CONFIG_BLK_ICQ
 void ioc_clear_queue(struct request_queue *q);
-- 
2.39.2


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH 1/3] blk-ioc: add a new helper ioc_lookup_icq_rcu()
  2025-07-25  7:05 ` [PATCH 1/3] blk-ioc: add a new helper ioc_lookup_icq_rcu() Yu Kuai
@ 2025-07-25 10:21   ` Damien Le Moal
  2025-07-25 12:03     ` Jan Kara
  0 siblings, 1 reply; 7+ messages in thread
From: Damien Le Moal @ 2025-07-25 10:21 UTC (permalink / raw)
  To: Yu Kuai, jack, axboe
  Cc: linux-block, linux-kernel, yukuai3, yi.zhang, yangerkun,
	johnny.chenyi

On 7/25/25 16:05, Yu Kuai wrote:
> From: Yu Kuai <yukuai3@huawei.com>
> 
> ioc_lookup_icq() is used by bfq to lookup bfqq from IO path, the helper
> have to be protected by queue_lock, which is too heavy. Hence add a new
> helper that is lookless, this is safe because both request_queue and ioc
> can be pinged by IO that is still issuing.
> 
> Signed-off-by: Yu Kuai <yukuai3@huawei.com>
> ---
>  block/blk-ioc.c | 34 ++++++++++++++++++++++++++++++++++
>  block/blk.h     |  1 +
>  2 files changed, 35 insertions(+)
> 
> diff --git a/block/blk-ioc.c b/block/blk-ioc.c
> index ce82770c72ab..4945b48dfdb6 100644
> --- a/block/blk-ioc.c
> +++ b/block/blk-ioc.c
> @@ -343,6 +343,40 @@ struct io_cq *ioc_lookup_icq(struct request_queue *q)
>  }
>  EXPORT_SYMBOL(ioc_lookup_icq);
>  
> +/**
> + * ioc_lookup_icq_rcu - lookup io_cq from ioc in io path
> + * @q: the associated request_queue
> + *
> + * Look up io_cq associated with @ioc - @q pair from @ioc. Must be called 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_rcu(struct request_queue *q)
> +{
> +	struct io_context *ioc = current->io_context;
> +	struct io_cq *icq;
> +
> +	WARN_ON_ONCE(percpu_ref_is_zero(&q->q_usage_counter));

I do not think this is necessary.

> +
> +	if (!ioc)
> +		return NULL;
> +
> +	icq = rcu_dereference(ioc->icq_hint);
> +	if (icq && icq->q == q)
> +		return icq;
> +
> +	icq = radix_tree_lookup(&ioc->icq_tree, q->id);
> +	if (!icq)
> +		return NULL;
> +
> +	if (WARN_ON_ONCE(icq->q != q))
> +		return NULL;
> +
> +	rcu_assign_pointer(ioc->icq_hint, icq);
> +	return icq;
> +}
> +EXPORT_SYMBOL(ioc_lookup_icq_rcu);

Patch 2 calls this function with the rcu_read_lock() held. Why not move that rcu
read lock here inside this function ? That is how ioc_lookup_icq() was doing
things, with code that is more compact than this.

And since ioc_lookup_icq() was already using RCU, it seems that the only change
you need is to remove the "lockdep_assert_held(&q->queue_lock);" from that
function to endup with the same above functionality. So why all the churn ?

Another question is: is it safe to call radix_tree_lookup() without any lock
held ? What if this races with a radix tree insertion ? (I may be wrong here as
I am not familiar with that code).

> +
>  /**
>   * ioc_create_icq - create and link io_cq
>   * @q: request_queue of interest
> diff --git a/block/blk.h b/block/blk.h
> index 468aa83c5a22..ef31b3ec1c69 100644
> --- a/block/blk.h
> +++ b/block/blk.h
> @@ -461,6 +461,7 @@ static inline void req_set_nomerge(struct request_queue *q, struct request *req)
>   */
>  struct io_cq *ioc_find_get_icq(struct request_queue *q);
>  struct io_cq *ioc_lookup_icq(struct request_queue *q);
> +struct io_cq *ioc_lookup_icq_rcu(struct request_queue *q);
>  #ifdef CONFIG_BLK_ICQ
>  void ioc_clear_queue(struct request_queue *q);
>  #else


-- 
Damien Le Moal
Western Digital Research

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH 1/3] blk-ioc: add a new helper ioc_lookup_icq_rcu()
  2025-07-25 10:21   ` Damien Le Moal
@ 2025-07-25 12:03     ` Jan Kara
  2025-07-25 17:46       ` Yu Kuai
  0 siblings, 1 reply; 7+ messages in thread
From: Jan Kara @ 2025-07-25 12:03 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: Yu Kuai, jack, axboe, linux-block, linux-kernel, yukuai3,
	yi.zhang, yangerkun, johnny.chenyi

On Fri 25-07-25 19:21:06, Damien Le Moal wrote:
> On 7/25/25 16:05, Yu Kuai wrote:
> > From: Yu Kuai <yukuai3@huawei.com>
> > 
> > ioc_lookup_icq() is used by bfq to lookup bfqq from IO path, the helper
> > have to be protected by queue_lock, which is too heavy. Hence add a new
> > helper that is lookless, this is safe because both request_queue and ioc
> > can be pinged by IO that is still issuing.
> > 
> > Signed-off-by: Yu Kuai <yukuai3@huawei.com>
> > ---
> >  block/blk-ioc.c | 34 ++++++++++++++++++++++++++++++++++
> >  block/blk.h     |  1 +
> >  2 files changed, 35 insertions(+)
> > 
> > diff --git a/block/blk-ioc.c b/block/blk-ioc.c
> > index ce82770c72ab..4945b48dfdb6 100644
> > --- a/block/blk-ioc.c
> > +++ b/block/blk-ioc.c
> > @@ -343,6 +343,40 @@ struct io_cq *ioc_lookup_icq(struct request_queue *q)
> >  }
> >  EXPORT_SYMBOL(ioc_lookup_icq);
> >  
> > +/**
> > + * ioc_lookup_icq_rcu - lookup io_cq from ioc in io path
> > + * @q: the associated request_queue
> > + *
> > + * Look up io_cq associated with @ioc - @q pair from @ioc. Must be called 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_rcu(struct request_queue *q)
> > +{
> > +	struct io_context *ioc = current->io_context;
> > +	struct io_cq *icq;
> > +
> > +	WARN_ON_ONCE(percpu_ref_is_zero(&q->q_usage_counter));
> 
> I do not think this is necessary.
> 
> > +
> > +	if (!ioc)
> > +		return NULL;
> > +
> > +	icq = rcu_dereference(ioc->icq_hint);
> > +	if (icq && icq->q == q)
> > +		return icq;
> > +
> > +	icq = radix_tree_lookup(&ioc->icq_tree, q->id);
> > +	if (!icq)
> > +		return NULL;
> > +
> > +	if (WARN_ON_ONCE(icq->q != q))
> > +		return NULL;
> > +
> > +	rcu_assign_pointer(ioc->icq_hint, icq);
> > +	return icq;
> > +}
> > +EXPORT_SYMBOL(ioc_lookup_icq_rcu);
> 
> Patch 2 calls this function with the rcu_read_lock() held. Why not move that rcu
> read lock here inside this function ? That is how ioc_lookup_icq() was doing
> things, with code that is more compact than this.
> 
> And since ioc_lookup_icq() was already using RCU, it seems that the only change
> you need is to remove the "lockdep_assert_held(&q->queue_lock);" from that
> function to endup with the same above functionality. So why all the churn ?

Yes, I agree, just dropping the assert and updating callers should be fine.

> Another question is: is it safe to call radix_tree_lookup() without any lock
> held ? What if this races with a radix tree insertion ? (I may be wrong here as
> I am not familiar with that code).

Yes, radix_tree_lookup() is fine to call with just rcu protection.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH 1/3] blk-ioc: add a new helper ioc_lookup_icq_rcu()
  2025-07-25 12:03     ` Jan Kara
@ 2025-07-25 17:46       ` Yu Kuai
  0 siblings, 0 replies; 7+ messages in thread
From: Yu Kuai @ 2025-07-25 17:46 UTC (permalink / raw)
  To: Jan Kara, Damien Le Moal
  Cc: Yu Kuai, axboe, linux-block, linux-kernel, yukuai3, yi.zhang,
	yangerkun, johnny.chenyi

Hi,

在 2025/7/25 20:03, Jan Kara 写道:
> On Fri 25-07-25 19:21:06, Damien Le Moal wrote:
>> On 7/25/25 16:05, Yu Kuai wrote:
>>> From: Yu Kuai <yukuai3@huawei.com>
>>>
>>> ioc_lookup_icq() is used by bfq to lookup bfqq from IO path, the helper
>>> have to be protected by queue_lock, which is too heavy. Hence add a new
>>> helper that is lookless, this is safe because both request_queue and ioc
>>> can be pinged by IO that is still issuing.
>>>
>>> Signed-off-by: Yu Kuai <yukuai3@huawei.com>
>>> ---
>>>   block/blk-ioc.c | 34 ++++++++++++++++++++++++++++++++++
>>>   block/blk.h     |  1 +
>>>   2 files changed, 35 insertions(+)
>>>
>>> diff --git a/block/blk-ioc.c b/block/blk-ioc.c
>>> index ce82770c72ab..4945b48dfdb6 100644
>>> --- a/block/blk-ioc.c
>>> +++ b/block/blk-ioc.c
>>> @@ -343,6 +343,40 @@ struct io_cq *ioc_lookup_icq(struct request_queue *q)
>>>   }
>>>   EXPORT_SYMBOL(ioc_lookup_icq);
>>>   
>>> +/**
>>> + * ioc_lookup_icq_rcu - lookup io_cq from ioc in io path
>>> + * @q: the associated request_queue
>>> + *
>>> + * Look up io_cq associated with @ioc - @q pair from @ioc. Must be called 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_rcu(struct request_queue *q)
>>> +{
>>> +	struct io_context *ioc = current->io_context;
>>> +	struct io_cq *icq;
>>> +
>>> +	WARN_ON_ONCE(percpu_ref_is_zero(&q->q_usage_counter));
>> I do not think this is necessary.
This is used to indicate this is from IO issue path, I can remove it.
>>> +
>>> +	if (!ioc)
>>> +		return NULL;
>>> +
>>> +	icq = rcu_dereference(ioc->icq_hint);
>>> +	if (icq && icq->q == q)
>>> +		return icq;
>>> +
>>> +	icq = radix_tree_lookup(&ioc->icq_tree, q->id);
>>> +	if (!icq)
>>> +		return NULL;
>>> +
>>> +	if (WARN_ON_ONCE(icq->q != q))
>>> +		return NULL;
>>> +
>>> +	rcu_assign_pointer(ioc->icq_hint, icq);
>>> +	return icq;
>>> +}
>>> +EXPORT_SYMBOL(ioc_lookup_icq_rcu);
>> Patch 2 calls this function with the rcu_read_lock() held. Why not move that rcu
>> read lock here inside this function ? That is how ioc_lookup_icq() was doing
>> things, with code that is more compact than this.
>>
>> And since ioc_lookup_icq() was already using RCU, it seems that the only change
>> you need is to remove the "lockdep_assert_held(&q->queue_lock);" from that
>> function to endup with the same above functionality. So why all the churn ?
> Yes, I agree, just dropping the assert and updating callers should be fine.
Yes, this is much simpler.
>> Another question is: is it safe to call radix_tree_lookup() without any lock
>> held ? What if this races with a radix tree insertion ? (I may be wrong here as
>> I am not familiar with that code).
> Yes, radix_tree_lookup() is fine to call with just rcu protection.

The insertion is protected by queue_lock, and look up is fine with rcu 
protection.

Thanks,
Kuai

>
> 								Honza


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2025-07-25 17:47 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-07-25  7:05 [PATCH 0/3] blk-ioc: convert ioc_lookup_icq() to lockless version Yu Kuai
2025-07-25  7:05 ` [PATCH 1/3] blk-ioc: add a new helper ioc_lookup_icq_rcu() Yu Kuai
2025-07-25 10:21   ` Damien Le Moal
2025-07-25 12:03     ` Jan Kara
2025-07-25 17:46       ` Yu Kuai
2025-07-25  7:05 ` [PATCH 2/3] block, bfq: convert to use ioc_lookup_icq_rcu() Yu Kuai
2025-07-25  7:05 ` [PATCH 3/3] blk-ioc: " Yu Kuai

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox