linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Thomas Graf <tgraf@suug.ch>, Tom Herbert <tom@quantonium.net>,
	David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next] rhashtable: further improve stability of rhashtable_walk
Date: Wed, 12 Dec 2018 17:41:29 +1100	[thread overview]
Message-ID: <87efanuu06.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <20181212054601.wbzpxjunnsfi62mz@gondor.apana.org.au>

[-- Attachment #1: Type: text/plain, Size: 1999 bytes --]

On Wed, Dec 12 2018, Herbert Xu wrote:

> On Wed, Dec 12, 2018 at 11:02:35AM +1100, NeilBrown wrote:
>> 
>> So I think this is a real bug - it is quite unlikely to hit, but
>> possibly.
>> You need a chain with at least 2 objects, you need
>> rhashtable_walk_stop() to be called after visiting an object other than
>> the last object, and you need some thread (this or some other) to remove
>> that object from the table.
>> 
>> The patch that I posted aims to fix that bug, and only that bug.
>> The only alternative that I can think of is to document that this can
>> happen and advise that a reference should be held to the last visited
>> object when stop/start is called, or in some other way ensure that it
>> doesn't get removed.
>
> Thanks for reminding me of the issue you were trying to fix.
>
> So going back into the email archives, I suggested at the very
> start that we could just insert the walker objects into the actual
> hash table.  That would solve the issue for both rhashtable and
> rhlist.
>
> Could we do that rather than using this ordered list that only
> works for rhashtable?

No. that doesn't work.
When you remove the walker object from the hash chain, you need to wait
for the RCU grace period to expire before you can safely insert back
into the chain. Inserting into a different chain isn't quite so bad now
that the nulls-marker stuff is working, a lookup thread will notice the
move and retry the lookup.

So you would substantially slow down the rhashtable_walk_start() step.
I've tried to think of various ways to over come this problem, such as
walking backwards through each chain - it is fairly safe to move and
object earlier in the chain - but all the approaches I have tried make
the code much more complex.

Thanks,
NeilBrown


>
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2018-12-12  6:41 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-06  7:11 [PATCH 0/3] rhashtable: replace rhashtable_walk_peek implementation NeilBrown
2018-07-06  7:11 ` [PATCH 3/3] rhashtable: implement rhashtable_walk_peek() using rhashtable_walk_last_seen() NeilBrown
2018-07-06  7:11 ` [PATCH 1/3] rhashtable: further improve stability of rhashtable_walk NeilBrown
2018-07-06  8:24   ` kbuild test robot
2018-07-06  9:50     ` NeilBrown
2018-07-06  8:59   ` Paolo Abeni
2018-07-06  9:55     ` NeilBrown
2018-07-06 10:12       ` Paolo Abeni
2018-07-06  9:25   ` kbuild test robot
2018-12-05  3:51   ` [PATCH net-next] " NeilBrown
2018-12-07  5:39     ` Herbert Xu
2018-12-09 22:50       ` NeilBrown
2018-12-11  5:17         ` Herbert Xu
2018-12-12  0:02           ` NeilBrown
2018-12-12  5:46             ` Herbert Xu
2018-12-12  6:41               ` NeilBrown [this message]
2018-12-12  8:00                 ` Herbert Xu
2018-12-12  8:49                   ` NeilBrown
2018-12-13  1:43                     ` Herbert Xu
2018-12-13  3:48                       ` NeilBrown
2018-12-13  8:47                         ` Herbert Xu
2018-07-06  7:11 ` [PATCH 2/3] rhashtable: add rhashtable_walk_last_seen() NeilBrown
2018-07-10 23:55   ` David Miller
2018-07-15 23:58     ` NeilBrown
2018-07-10 23:55 ` [PATCH 0/3] rhashtable: replace rhashtable_walk_peek implementation David Miller

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=87efanuu06.fsf@notabene.neil.brown.name \
    --to=neilb@suse.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=tgraf@suug.ch \
    --cc=tom@quantonium.net \
    /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;
as well as URLs for NNTP newsgroup(s).