[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <41E7AC96-4570-4379-A998-C4E71977E374@oracle.com>
Date: Mon, 30 Jan 2023 15:21:23 +0000
From: Chuck Lever III <chuck.lever@...cle.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
CC: Thomas Graf <tgraf@...g.ch>, netdev <netdev@...r.kernel.org>,
Linux NFS Mailing List <linux-nfs@...r.kernel.org>
Subject: Re: [PATCH RFC] NFSD: Convert filecache to rhltable
> On Jan 30, 2023, at 1:09 AM, Herbert Xu <herbert@...dor.apana.org.au> wrote:
>
> On Tue, Jan 24, 2023 at 02:57:35PM +0000, Chuck Lever III wrote:
>>
>>> I could be wrong, but it looks like you're safe to traverse the list
>>> even in the case of removals, assuming the objects themselves are
>>> rcu-freed. AFAICT, the object's ->next pointer is not changed when it's
>>> removed from the table. After all, we're not holding a "real" lock here
>>> so the object could be removed by another task at any time.
>>>
>>> It would be nice if this were documented though.
>
> Yes this is correct. As long as rcu_read_lock is still held,
> the list will continue to be valid for walking even if you remove
> entries from it.
>
>> Is there a preferred approach for this with rhltable? Can we just
>> hold rcu_read_lock and call rhltable_remove repeatedly without getting
>> a fresh copy of the list these items reside on?
>
> Yes you can walk the whole returned list while removing the nodes
> one by one, assuming that you hold the RCU read lock throughout.
> The unhashed nodes are only freed after the RCU grace period so the
> list remains valid after removal.
Thanks for the feedback!
--
Chuck Lever
Powered by blists - more mailing lists