[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZmrteDHF_HlWHFth@kbusch-mbp>
Date: Thu, 13 Jun 2024 07:00:40 -0600
From: Keith Busch <kbusch@...nel.org>
To: Christoph Hellwig <hch@....de>
Cc: Nilay Shroff <nilay@...ux.ibm.com>, Keith Busch <kbusch@...a.com>,
linux-nvme@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org, sagi@...mberg.me,
paulmck@...nel.org, davidgow@...gle.com, akpm@...ux-foundation.org,
venkat88@...ux.vnet.ibm.com
Subject: Re: [PATCH 1/2] list: introduce a new cutting helper
On Thu, Jun 13, 2024 at 10:10:16AM +0200, Christoph Hellwig wrote:
> On Thu, Jun 13, 2024 at 10:26:11AM +0530, Nilay Shroff wrote:
> > I am wondering whether we really need the _rcu version of list_cut here?
> > I think that @head could point to an _rcu protected list and that's true
> > for this patch. So there might be concurrent readers accessing @head using
> > _rcu list-traversal primitives, such as list_for_each_entry_rcu().
>
> Yes, I can't see how this works for a RCU lists without very careful
> memory ordering.
>
> Btw, another thing - the old vs new list ordering is reversed vs
> list_splice*, which is a bit confusing (as are the parameter names
> both for list_splice* and this new helper). Can you switch them
> around to match?
The parameters follow the existing conventions from list_cut_back and
list_cut_position. Those functions cut off from the head to the "entry",
and this one cuts off the "entry" to the tail instead.
Powered by blists - more mailing lists