[lkml]   [2018]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/2] rhashtable: improve rhashtable_walk stability when stop/start used.
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 <>

Very nice!

Acked-by: Herbert Xu <>
Email: Herbert Xu <>
Home Page:
PGP Key:

 \ /
  Last update: 2018-03-29 07:51    [W:0.111 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site