linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: neilb@suse.com
Cc: herbert@gondor.apana.org.au, tgraf@suug.ch,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	eric.dumazet@gmail.com
Subject: Re: [PATCH - revised] rhashtable: detect when object movement might have invalidated a lookup
Date: Thu, 19 Jul 2018 05:14:40 +0900 (KST)	[thread overview]
Message-ID: <20180719.051440.931407144963903326.davem@davemloft.net> (raw)
In-Reply-To: <87fu0kt5m0.fsf@notabene.neil.brown.name>

From: NeilBrown <neilb@suse.com>
Date: Mon, 16 Jul 2018 09:57:11 +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>

Neil I have to be honest with you.

During this whole ordeal I was under the impression that this was all
going to be used for something in-tree.  But now I see that you want
to use all of this stuff for lustre which is out of tree.

It would be extremely hard for me to accept adding this kind of
complexity and weird semantics to an already extremely complicated
and delicate piece of infrastructure if something in-tree would use
it.

But for something out-of-tree?  I'm sorry, no way.

  parent reply	other threads:[~2018-07-18 20:14 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-01  4:44 [RFC PATCH 00/18] Assorted rhashtable improvements NeilBrown
2018-06-01  4:44 ` [PATCH 11/18] rhashtable: further improve stability of rhashtable_walk NeilBrown
2018-06-01  4:44 ` [PATCH 17/18] rhashtable: rename rht_for_each*continue as *from NeilBrown
2018-06-01  4:44 ` [PATCH 10/18] rhashtable: remove rhashtable_walk_peek() NeilBrown
2018-06-02 15:48   ` Herbert Xu
2018-06-04  0:30     ` NeilBrown
2018-06-04  1:18       ` Tom Herbert
2018-06-04  2:09         ` NeilBrown
2018-06-04 21:31           ` Tom Herbert
2018-06-04 22:13             ` Tom Herbert
2018-06-05  1:24               ` NeilBrown
2018-06-05  1:00             ` NeilBrown
     [not found]               ` <CALx6S36Ce-rXQMzmFYZVPGD10Bo6udvRAHiZ5gWwnzVwoTVv0w@mail.gmail.com>
2018-06-06  5:07                 ` NeilBrown
2018-06-07  2:45                   ` [PATCH - RFC] rhashtable: add rhashtable_walk_last_seen() NeilBrown
2018-06-07  2:46                     ` [PATCH - RFC] rhashtable: implement rhashtable_walk_peek() using rhashtable_walk_last_seen() NeilBrown
     [not found]                       ` <CALx6S35GgUOd0dPgv7P96wNNTv5pN7fij0pcAoccqcSWZhvY7Q@mail.gmail.com>
2018-06-12  2:48                         ` [PATCH RFC v2] " NeilBrown
2018-06-14 17:41                           ` Tom Herbert
2018-06-15  4:23                             ` Herbert Xu
2018-06-15  5:31                               ` NeilBrown
2018-06-01  4:44 ` [PATCH 18/18] rhashtable: add rhashtable_walk_delay_rehash() NeilBrown
2018-06-01  4:44 ` [PATCH 14/18] rhashtable: allow rht_bucket_var to return NULL NeilBrown
2018-06-01  4:44 ` [PATCH 15/18] rhashtable: use bit_spin_locks to protect hash bucket NeilBrown
2018-06-02  5:03   ` Herbert Xu
2018-06-02  9:53     ` Eric Dumazet
2018-06-04  0:25       ` NeilBrown
2018-06-04  2:52         ` [PATCH 15a/18] rhashtables: add lockdep tracking to bucket bit-spin-locks NeilBrown
2018-06-04 18:16           ` Simon Horman
2018-06-04 21:37             ` NeilBrown
2018-06-01  4:44 ` [PATCH 01/18] rhashtable: silence RCU warning in rhashtable_test NeilBrown
2018-06-01  4:44 ` [PATCH 07/18] rhashtable: use cmpxchg() to protect ->future_tbl NeilBrown
2018-06-01 16:44   ` Herbert Xu
2018-06-01  4:44 ` [PATCH 13/18] rhashtable: don't hold lock on first table throughout insertion NeilBrown
2018-06-01  4:44 ` [PATCH 16/18] rhashtable: allow percpu element counter NeilBrown
2018-06-01  4:44 ` [PATCH 03/18] rhashtable: remove nulls_base and related code NeilBrown
2018-06-07  2:49   ` NeilBrown
2018-06-13  6:25     ` Herbert Xu
2018-06-01  4:44 ` [PATCH 08/18] rhashtable: clean up dereference of ->future_tbl NeilBrown
2018-06-01 16:54   ` Herbert Xu
2018-06-01  4:44 ` [PATCH 06/18] rhashtable: simplify nested_table_alloc() and rht_bucket_nested_insert() NeilBrown
2018-06-01 16:28   ` Herbert Xu
2018-06-01  4:44 ` [PATCH 09/18] rhashtable: use cmpxchg() in nested_table_alloc() NeilBrown
2018-06-01  4:44 ` [PATCH 05/18] rhashtable: simplify INIT_RHT_NULLS_HEAD() NeilBrown
2018-06-01 16:24   ` Herbert Xu
2018-06-01  4:44 ` [PATCH 12/18] rhashtable: add rhashtable_walk_prev() NeilBrown
2018-06-01  4:44 ` [PATCH 02/18] rhashtable: split rhashtable.h NeilBrown
2018-06-01 10:48   ` Herbert Xu
2018-06-01  4:44 ` [PATCH 04/18] rhashtable: detect when object movement might have invalidated a lookup NeilBrown
2018-06-01 16:06   ` Herbert Xu
2018-06-04  3:38     ` NeilBrown
2018-07-06  7:08     ` [PATCH resend] " NeilBrown
2018-07-12  5:46       ` David Miller
2018-07-12  5:48         ` David Miller
2018-07-15 23:55           ` NeilBrown
2018-07-15 23:57           ` [PATCH - revised] " NeilBrown
2018-07-16  0:51             ` Herbert Xu
2018-07-16  1:23               ` NeilBrown
2018-07-16  2:16                 ` Herbert Xu
2018-07-16  3:26                   ` NeilBrown
2018-07-17  6:30                     ` Herbert Xu
2018-07-20  6:24                       ` NeilBrown
2018-07-18 20:14             ` David Miller [this message]
2018-07-20  6:30               ` NeilBrown
2018-07-20  6:43                 ` David Miller
2018-07-20  7:09                   ` NeilBrown
2018-07-23  1:56               ` [PATCH net-next] rhashtable: detect when object movement between tables " NeilBrown
2018-07-26 20:55                 ` David Miller
2018-07-26 22:04                   ` NeilBrown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180719.051440.931407144963903326.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@suse.com \
    --cc=netdev@vger.kernel.org \
    --cc=tgraf@suug.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).