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 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.