From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH resend] rhashtable: detect when object movement might have invalidated a lookup Date: Wed, 11 Jul 2018 22:46:58 -0700 (PDT) Message-ID: <20180711.224658.2077863065492745521.davem@davemloft.net> References: <152782824943.30340.8224535954517915320.stgit@noble> <20180601160613.7ud25g2ux55k3bma@gondor.apana.org.au> <87k1q8yh70.fsf@notabene.neil.brown.name> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: herbert@gondor.apana.org.au, tgraf@suug.ch, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, eric.dumazet@gmail.com To: neilb@suse.com Return-path: In-Reply-To: <87k1q8yh70.fsf@notabene.neil.brown.name> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org From: NeilBrown 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 Applied to net-next.