lkml.org 
[lkml]   [2018]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH resend] rhashtable: detect when object movement might have invalidated a lookup
From
From: NeilBrown <neilb@suse.com>
Date: Fri, 06 Jul 2018 17:08:35 +1000

>
> Some users of rhashtable might need to change the key
> of an object and move it to a different location in the table.
> Other users might want to allocate objects using
> SLAB_TYPESAFE_BY_RCU which can result in the same memory allocation
> being used for a different (type-compatible) purpose and similarly
> end up in a different hash-chain.
>
> 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 is repeated.
>
> The unique NULLS_MARKER is derived from the address of the
> head of the chain.
>
> If an object is removed and re-added to the same hash chain, we won't
> notice by looking that the NULLS marker. In this case we must be sure
> that it was not re-added *after* its original location, or a lookup may
> incorrectly fail. The easiest solution is to ensure it is inserted at
> the start of the chain. insert_slow() already does that,
> insert_fast() does not. So this patch changes insert_fast to always
> insert at the head of the chain.
>
> Note that such a user must do their own double-checking of
> the object found by rhashtable_lookup_fast() after ensuring
> mutual exclusion which anything that might change the key, such as
> successfully taking a new reference.
>
> Signed-off-by: NeilBrown <neilb@suse.com>

Applied to net-next.
\
 
 \ /
  Last update: 2018-07-15 22:05    [W:0.098 / U:0.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site