netdev - Re: [PATCH RFC] NFSD: Convert filecache to rhltable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

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