Thread (25 messages) flat view 25 messages, 5 authors, 2018-12-13

Re: [PATCH net-next] rhashtable: further improve stability of rhashtable_walk

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: 2018-12-11 05:18:10
Also in: lkml

Hi Neil:

On Mon, Dec 10, 2018 at 09:50:43AM +1100, NeilBrown wrote:
 I think it was agreed that I would not pursue features that were only
 of use to out-of-tree code, but I don't think that applies here.  This
 is not a feature, this is a quality-of-implementation improvement.
 There are users in the kernel today which use
   rhashtable_walk_stop()/rhashtable_walk_start()
 to drop out of RCU protection for periods during the walk.
 Any such user might miss seeing an object that has been in the table
 for a while - sure that is less than optimal, and should be fixed if
 the cost is small.

 There are currently no rhlist users which use stop/start to drop out
 of RCU, so there is no clear value in fixing that case, or cost in not
 fixing it.
I think the complexities of this patch outweighs any benefit.

Walking an rhashtable is inherently unreliable, due to rehashing.
If you need an 100% reliable walking mechanism, then add your own
linked list alongside the hash table like xfrm does.

Having said that, if the current code is missing items that existed
prior to the start of the walk (in the absence of a rehash) then
that would be a bug that we should fix.  Anything else like
duplicates just needs to be accepted by the caller.

So please explain how can an object be missed then we can work on
fixing that and that only.

Thanks,
-- 
Email: Herbert Xu [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help