From: NeilBrown <ne...@suse.com> Date: Fri, 30 Nov 2018 10:26:50 +1100
> > Some users of rhashtables might need to move an object from one table > to another - this appears to be the reason for the incomplete usage > of NULLS markers. > > To support these, we store a unique NULLS_MARKER at the end of > each chain, and when a search fails to find a match, we check > if the NULLS marker found was the expected one. If not, the search > may not have examined all objects in the target bucket, so it is > repeated. > > The unique NULLS_MARKER is derived from the address of the > head of the chain. As this cannot be derived at load-time the > static rhnull in rht_bucket_nested() needs to be initialised > at run time. > > Any caller of a lookup function must still be prepared for the > possibility that the object returned is in a different table - it > might have been there for some time. > > Note that this does NOT provide support for other uses of > NULLS_MARKERs such as allocating with SLAB_TYPESAFE_BY_RCU or changing > the key of an object and re-inserting it in the same table. > These could only be done safely if new objects were inserted > at the *start* of a hash chain, and that is not currently the case. > > Signed-off-by: NeilBrown <ne...@suse.com> Applied to net-next.
