Linux NFS development
 help / color / mirror / Atom feed
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Thomas Graf <tgraf@suug.ch>, netdev <netdev@vger.kernel.org>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: Fwd: [PATCH RFC] NFSD: Convert filecache to rhltable
Date: Mon, 30 Jan 2023 14:09:11 +0800	[thread overview]
Message-ID: <Y9dfB322nu5d3fB1@gondor.apana.org.au> (raw)
In-Reply-To: <7456FF95-0C16-45C7-8CD9-B4436BE80B71@oracle.com>

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.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

  reply	other threads:[~2023-01-30  6:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-05 14:58 [PATCH RFC] NFSD: Convert filecache to rhltable Chuck Lever
2023-01-06  6:00 ` Wang Yugui
2023-01-06 14:13   ` Chuck Lever III
2023-01-06 15:56 ` Jeff Layton
2023-01-23 20:15 ` Jeff Layton
2023-01-23 20:34   ` Chuck Lever III
2023-01-23 21:38     ` Jeff Layton
2023-01-24 14:57       ` Fwd: " Chuck Lever III
2023-01-30  6:09         ` Herbert Xu [this message]
2023-01-30 15:21           ` Chuck Lever III
2023-01-30 18:10       ` Chuck Lever III

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y9dfB322nu5d3fB1@gondor.apana.org.au \
    --to=herbert@gondor.apana.org.au \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=tgraf@suug.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox