Re: [PATCH v7 1/3] llist: Add a lock-less list variant terminated by a sentinel node

[Waiman Long]

On 10/3/22 13:40, Waiman Long wrote:
> On 10/3/22 13:36, Tejun Heo wrote:
> > Hello,
> >
> > 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 
> > > sentinel
> > > terminated lockless list. Users who wish to use the sentinel terminated
> > > version will have to use special sentinel version of LLIST_HEAD() 
> > > macro and
> > > llist_del_all() and __llist_del_all() functions. In this way, I 
> > > don't need
> > > to touch an existing users of llist while minimizing code 
> > > redundancy. What
> > > do you think?
> > Wouldn't that be more error-prone in the long term? I'd just bite the 
> > bullet
> > and convert the empty tests. It is a hassle to find them but given 
> > that it's
> > 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,

1) arch/powerpc/include/asm/kvm_book3s_64.h:
   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
   with kprobe.

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.

Regards,
Longman