Re: [PATCH v7 1/3] llist: Add a lock-less list variant terminated by a sentinel node
From: Waiman Long
Date: Mon Oct 03 2022 - 15:39:17 EST
On 10/3/22 13:40, Waiman Long wrote:
On 10/3/22 13:36, Tejun Heo wrote:
On Mon, Oct 03, 2022 at 01:32:49PM -0400, Waiman Long wrote:
What my current thinking is to make llist works with both NULL and
Wouldn't that be more error-prone in the long term? I'd just bite the
terminated lockless list. Users who wish to use the sentinel terminated
version will have to use special sentinel version of LLIST_HEAD()
llist_del_all() and __llist_del_all() functions. In this way, I
to touch an existing users of llist while minimizing code
do you think?
and convert the empty tests. It is a hassle to find them but given
just the head node testing, it hopefully wouldn't be too bad.
OK, I will take a further look at what changes will be needed by the
existing llist users.
After a further look, I think the task of making sentinel llist the
default will be more time consuming that I initially thought. For example,
It has its own llist iterator for_each_nest_rmap_safe.
2) kprobe use llist but not the full set of APIs and the
various arch code put NULL in their llist_node to communicate
3) drivers/vhost/scsi.c uses llist but it doesn't use LLIST_HEAD
nor init_llist_head to initialize the llist_head. I suspect that
it may relies on NULL being the initial value.
There are 123 instances where llist_head is referenced in arch, driver,
filesystem and kernel code. Going through all these to make sure that it
will all work will be a major effort. I think it will be safer to allow
both NULL and the sentinel node as the initializers and gradually
convert them to use the proper llist APIs over time to complete the
conversion. I am sorry that I can't spend that much time upfront for
this conversion effort.