Message-ID: <5d7904e8-977e-499c-b877-901facac5dea@linux.dev>
Date: Fri, 26 Sep 2025 11:23:02 +0800
From: luoxuanqiang <xuanqiang.luo@...ux.dev>
To: Kuniyuki Iwashima <kuniyu@...gle.com>
Cc: edumazet@...gle.com, "Paul E. McKenney" <paulmck@...nel.org>,
 kerneljasonxing@...il.com, davem@...emloft.net, kuba@...nel.org,
 netdev@...r.kernel.org, Xuanqiang Luo <luoxuanqiang@...inos.cn>,
 Frederic Weisbecker <frederic@...nel.org>,
 Neeraj Upadhyay <neeraj.upadhyay@...nel.org>
Subject: Re: [PATCH net-next v6 1/3] rculist: Add hlist_nulls_replace_rcu()
 and hlist_nulls_replace_init_rcu()


在 2025/9/26 01:56, Kuniyuki Iwashima 写道:
> On Wed, Sep 24, 2025 at 7:18 PM <xuanqiang.luo@...ux.dev> wrote:
>> From: Xuanqiang Luo <luoxuanqiang@...inos.cn>
>>
>> Add two functions to atomically replace RCU-protected hlist_nulls entries.
>>
>> Keep using WRITE_ONCE() to assign values to ->next and ->pprev, as
>> mentioned in the patch below:
>> commit efd04f8a8b45 ("rcu: Use WRITE_ONCE() for assignments to ->next for
>> rculist_nulls")
>> commit 860c8802ace1 ("rcu: Use WRITE_ONCE() for assignments to ->pprev for
>> hlist_nulls")
>>
>> Signed-off-by: Xuanqiang Luo <luoxuanqiang@...inos.cn>
>> ---
>>   include/linux/rculist_nulls.h | 52 +++++++++++++++++++++++++++++++++++
>>   1 file changed, 52 insertions(+)
>>
>> diff --git a/include/linux/rculist_nulls.h b/include/linux/rculist_nulls.h
>> index 89186c499dd4..c3ba74b1890d 100644
>> --- a/include/linux/rculist_nulls.h
>> +++ b/include/linux/rculist_nulls.h
>> @@ -152,6 +152,58 @@ static inline void hlist_nulls_add_fake(struct hlist_nulls_node *n)
>>          n->next = (struct hlist_nulls_node *)NULLS_MARKER(NULL);
>>   }
>>
>> +/**
>> + * hlist_nulls_replace_rcu - replace an old entry by a new one
>> + * @old: the element to be replaced
>> + * @new: the new element to insert
>> + *
>> + * Description:
>> + * Replace the old entry with the new one in a RCU-protected hlist_nulls, while
>> + * permitting racing traversals.
>> + *
>> + * The caller must take whatever precautions are necessary (such as holding
>> + * appropriate locks) to avoid racing with another list-mutation primitive, such
>> + * as hlist_nulls_add_head_rcu() or hlist_nulls_del_rcu(), running on this same
>> + * list.  However, it is perfectly legal to run concurrently with the _rcu
>> + * list-traversal primitives, such as hlist_nulls_for_each_entry_rcu().
>> + */
>> +static inline void hlist_nulls_replace_rcu(struct hlist_nulls_node *old,
>> +                                            struct hlist_nulls_node *new)
> nit: checkpatch complains here..
> https://patchwork.kernel.org/project/netdevbpf/patch/20250925021628.886203-2-xuanqiang.luo@linux.dev/
>
> CHECK: Alignment should match open parenthesis
> #46: FILE: include/linux/rculist_nulls.h:171:
> +static inline void hlist_nulls_replace_rcu(struct hlist_nulls_node *old,
> +     struct hlist_nulls_node *new)

Thanks for pointing it out, I'll fix it in the next version.

Appreciate it!

>
>> +{
>> +       struct hlist_nulls_node *next = old->next;
>> +
>> +       WRITE_ONCE(new->next, next);
>> +       WRITE_ONCE(new->pprev, old->pprev);
>> +       rcu_assign_pointer(*(struct hlist_nulls_node __rcu **)new->pprev, new);
> nit: define hlist_nulls_prev_rcu() like hlist_nulls_next_rcu().

I'm wondering if defining a macro called hlist_nulls_prev_rcu() might
be controversial, since it should actually be getting the prev->next
rather than the prev itself.

Would it be more appropriate to rename it to hlist_nulls_prev_next_rcu()
instead?

Like this:

diff --git a/include/linux/rculist_nulls.h b/include/linux/rculist_nulls.h
index c3ba74b1890d..9399ec9dc82d 100644
--- a/include/linux/rculist_nulls.h
+++ b/include/linux/rculist_nulls.h
@@ -52,6 +52,14 @@ static inline void hlist_nulls_del_init_rcu(struct hlist_nulls_node *n)
  #define hlist_nulls_next_rcu(node) \
         (*((struct hlist_nulls_node __rcu __force **)&(node)->next))
+/**
+ * hlist_nulls_prev_next_rcu - returns the next pointer of the previous
+ * element.
+ * @node: element of the list.
+ */
+#define hlist_nulls_prev_next_rcu(node) \
+       (*((struct hlist_nulls_node __rcu __force **)(node)->pprev))
+
  /**
   * hlist_nulls_del_rcu - deletes entry from hash list without re-initialization
   * @n: the element to delete from the hash list.

However, I noticed that in the definition of hlist_pprev_rcu(), it directly
uses pprev:

#define hlist_pprev_rcu(node)    (*((struct hlist_node __rcu **)((node)->pprev)))

This part seems a bit confusing to me. It's possible I'm missing some
historical context here. If so, please feel free to point it out.

Thanks!

>
>> +       if (!is_a_nulls(next))
>> +               WRITE_ONCE(new->next->pprev, &new->next);
> nit: s/new->next->pprev/next->pprev/

I'll update it in the next version.

Thank you!

>> +}
>> +
>> +/**
>> + * hlist_nulls_replace_init_rcu - replace an old entry by a new one and
>> + * initialize the old
>> + * @old: the element to be replaced
>> + * @new: the new element to insert
>> + *
>> + * Description:
>> + * Replace the old entry with the new one in a RCU-protected hlist_nulls, while
>> + * permitting racing traversals, and reinitialize the old entry.
>> + *
>> + * Note: @old must be hashed.
>> + *
>> + * The caller must take whatever precautions are necessary (such as holding
>> + * appropriate locks) to avoid racing with another list-mutation primitive, such
>> + * as hlist_nulls_add_head_rcu() or hlist_nulls_del_rcu(), running on this same
>> + * list. However, it is perfectly legal to run concurrently with the _rcu
>> + * list-traversal primitives, such as hlist_nulls_for_each_entry_rcu().
>> + */
>> +static inline void hlist_nulls_replace_init_rcu(struct hlist_nulls_node *old,
>> +                                               struct hlist_nulls_node *new)
>> +{
>> +       hlist_nulls_replace_rcu(old, new);
>> +       WRITE_ONCE(old->pprev, NULL);
>> +}
>> +
>>   /**
>>    * hlist_nulls_for_each_entry_rcu - iterate over rcu list of given type
>>    * @tpos:      the type * to use as a loop cursor.
>> --
>> 2.25.1
>>

Powered by blists - more mailing lists