linux-kernel - Re: [PATCH net-next] rhashtable: further improve stability of rhashtable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181211051755.modgomqzszkbiihe@gondor.apana.org.au>
Date:   Tue, 11 Dec 2018 13:17:55 +0800
From:   Herbert Xu <herbert@...dor.apana.org.au>
To:     NeilBrown <neilb@...e.com>
Cc:     Thomas Graf <tgraf@...g.ch>, Tom Herbert <tom@...ntonium.net>,
        David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] rhashtable: further improve stability of
 rhashtable_walk

Hi Neil:

On Mon, Dec 10, 2018 at 09:50:43AM +1100, NeilBrown wrote:
>  I think it was agreed that I would not pursue features that were only
>  of use to out-of-tree code, but I don't think that applies here.  This
>  is not a feature, this is a quality-of-implementation improvement.
>  There are users in the kernel today which use
>    rhashtable_walk_stop()/rhashtable_walk_start()
>  to drop out of RCU protection for periods during the walk.
>  Any such user might miss seeing an object that has been in the table
>  for a while - sure that is less than optimal, and should be fixed if
>  the cost is small.
> 
>  There are currently no rhlist users which use stop/start to drop out
>  of RCU, so there is no clear value in fixing that case, or cost in not
>  fixing it.

I think the complexities of this patch outweighs any benefit.

Walking an rhashtable is inherently unreliable, due to rehashing.
If you need an 100% reliable walking mechanism, then add your own
linked list alongside the hash table like xfrm does.

Having said that, if the current code is missing items that existed
prior to the start of the walk (in the absence of a rehash) then
that would be a bug that we should fix.  Anything else like
duplicates just needs to be accepted by the caller.

So please explain how can an object be missed then we can work on
fixing that and that only.

Thanks,
-- 
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