[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <871sc3uah9.fsf@notabene.neil.brown.name>
Date: Mon, 16 Jul 2018 13:26:42 +1000
From: NeilBrown <neilb@...e.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: David Miller <davem@...emloft.net>, tgraf@...g.ch,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
eric.dumazet@...il.com
Subject: Re: [PATCH - revised] rhashtable: detect when object movement might have invalidated a lookup
On Mon, Jul 16 2018, Herbert Xu wrote:
> On Mon, Jul 16, 2018 at 11:23:43AM +1000, NeilBrown wrote:
>>
>> kmem_cache_free() directly. For this, I need rhashtable to be safe if
>> an object is deleted and immediately re-inserted into the same hash
>> chain.
>
> This means that
>
> rcu_read_lock();
> A = rhashtable_lookup();
> use(A);
> rcu_read_unlock();
>
> A can turn into object B when it is used. That is just too strange
> for words. Can we see some actual code on how this works?
Look in Documenation/RCU/rculist_nulls.txt.
The very first example is a typical lookup for a nulls list.
The above sample code would read:
rcu_read_lock();
begin:
A = rhashtable_lookup(table, key);
if (IS_ERR(A)) {
rcu_read_unlock();
goto not_found;
}
if (!try_get_ref(A))
goto again;
if (A->key != key) {
put_ref(A);
goto again;
}
rcu_read_unlock();
use(A);
If you particularly need to see real code rather than sample code, I can
have something for you in a day or so.
Thanks,
NeilBrown
>
> For comparison, the existing net code where this happens A doesn't
> actually change and it simply moves from one hashtable to another.
>
> I'm relucant to add semantics that would restrain on how rhashtable
> works unless we have real and valid use-cases for it.
>
> Cheers,
> --
> Email: Herbert Xu <herbert@...dor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)
Powered by blists - more mailing lists