Received-SPF: pass (google.com: domain of linux-kernel+bounces-213762-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Thu, 13 Jun 2024 10:39:12 -0700
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Keith Busch <kbusch@kernel.org>
Cc: Nilay Shroff <nilay@linux.ibm.com>, Keith Busch <kbusch@meta.com>,
	linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-kselftest@vger.kernel.org, hch@lst.de, sagi@grimberg.me,
	davidgow@google.com, akpm@linux-foundation.org,
	venkat88@linux.vnet.ibm.com
Subject: Re: [PATCH 1/2] list: introduce a new cutting helper
Message-ID: <c65e7fef-cfee-4360-b03c-cfdd832912a4@paulmck-laptop>
Reply-To: paulmck@kernel.org
References: <f0e4c51c-8227-4f5c-876f-38fbb4a0e1bf@linux.ibm.com>
 <ZmrscxG51gFRDVlM@kbusch-mbp>
 <c475f0d8-3bc9-4d65-8fce-586f4b75b4fc@linux.ibm.com>
 <ZmsD_HDLBQAqOOU3@kbusch-mbp.dhcp.thefacebook.com>
 <31eb40f9-d68d-4348-b1fd-3cf057939297@paulmck-laptop>
 <ZmsGfle1aZQauzRb@kbusch-mbp.dhcp.thefacebook.com>
 <73b994eb-c689-48e0-b09c-a414041a0525@paulmck-laptop>
 <ZmsS9DZWl8TccvKz@kbusch-mbp.dhcp.thefacebook.com>
 <046f42c5-34b5-41a2-9680-5ef86ef25c01@paulmck-laptop>
 <ZmsZ_lKgOlB6Wypy@kbusch-mbp.dhcp.thefacebook.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZmsZ_lKgOlB6Wypy@kbusch-mbp.dhcp.thefacebook.com>

On Thu, Jun 13, 2024 at 10:10:38AM -0600, Keith Busch wrote:
> On Thu, Jun 13, 2024 at 09:01:47AM -0700, Paul E. McKenney wrote:
> > 
> > Is there a way to avoid this issue by making this be a statement parameter
> > to a macro?
> 
> Something like this? It appears to work for the intended use, at least.
> 
> ---
> diff --git a/include/linux/rculist.h b/include/linux/rculist.h
> index 3dc1e58865f77..cdd2e5c0d5cdb 100644
> --- a/include/linux/rculist.h
> +++ b/include/linux/rculist.h
> @@ -204,6 +204,30 @@ static inline void list_replace_rcu(struct list_head *old,
>  	old->prev = LIST_POISON2;
>  }
>  
> +
> +static inline void __list_cut_start(struct list_head *list,
> +				    struct list_head *head,
> +				    struct list_head *entry)
> +{
> +	list->next = entry;
> +	list->prev = head->prev;
> +	__list_del(entry->prev, head);
> +}
> +
> +static inline void __list_cut_end(struct list_head *list,
> +				  struct list_head *entry)
> +{
> +	entry->prev = list;
> +	list->prev->next = list;
> +}
> +
> +#define list_cut_rcu(list, head, entry, sync)		\
> +	do {						\
> +		__list_cut_start(list, head, entry);	\

At this point, old readers might see the new list starting from "head"
and new readers see the new (shorter) list, again, starting from "head".
Presumably no readers can yet see "list".

> +		sync;					\

There are now no old readers, and thus no readers that can see
any elements in the list starting from "entry".

> +		__list_cut_end(list, entry); 		\

And this fixes up the list now headed by "list".

So:

Reviewed-by: Paul E. McKenney <paulmck@kernel.org>

And another argument for lambdas, not that there is a shortage of
arguments against them.  ;-)

> +	} while (0)
> +
>  /**
>   * __list_splice_init_rcu - join an RCU-protected list into an existing list.
>   * @list:	the RCU-protected list to splice
> --