On Thu, Mar 29, 2018 at 12:19:10PM +1100, NeilBrown wrote: > When a walk of an rhashtable is interrupted with rhastable_walk_stop() > and then rhashtable_walk_start(), the location to restart from is based > on a 'skip' count in the current hash chain, and this can be incorrect > if insertions or deletions have happened. This does not happen when > the walk is not stopped and started as iter->p is a placeholder which > is safe to use while holding the RCU read lock. > > In rhashtable_walk_start() we can revalidate that 'p' is still in the > same hash chain. If it isn't then the current method is still used. > > With this patch, if a rhashtable walker ensures that the current > object remains in the table over a stop/start period (possibly by > elevating the reference count if that is sufficient), it can be sure > that a walk will not miss objects that were in the hashtable for the > whole time of the walk. > > rhashtable_walk_start() may not find the object even though it is > still in the hashtable if a rehash has moved it to a new table. In > this case it will (eventually) get -EAGAIN and will need to proceed > through the whole table again to be sure to see everything at least > once. > > Signed-off-by: NeilBrown <ne...@suse.com>
Very nice! Acked-by: Herbert Xu <herb...@gondor.apana.org.au> -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
