linux-kernel - Re: [PATCH v3] rhashtable: detect when object movement between tables might have invalidated a lookup

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] [day] [month] [year] [list]

Message-Id: <20181203.153209.2147928207639502351.davem@davemloft.net>
Date:   Mon, 03 Dec 2018 15:32:09 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     neilb@...e.com
Cc:     herbert@...dor.apana.org.au, tgraf@...g.ch, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, eric.dumazet@...il.com
Subject: Re: [PATCH v3] rhashtable: detect when object movement between
 tables might have invalidated a lookup

From: NeilBrown <neilb@...e.com>
Date: Fri, 30 Nov 2018 10:26:50 +1100

> 
> Some users of rhashtables might need to move an object from one table
> to another -  this appears to be the reason for the incomplete usage
> of NULLS markers.
> 
> 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
> may not have examined all objects in the target bucket, so it is
> repeated.
> 
> The unique NULLS_MARKER is derived from the address of the
> head of the chain.  As this cannot be derived at load-time the
> static rhnull in rht_bucket_nested() needs to be initialised
> at run time.
> 
> Any caller of a lookup function must still be prepared for the
> possibility that the object returned is in a different table - it
> might have been there for some time.
> 
> Note that this does NOT provide support for other uses of
> NULLS_MARKERs such as allocating with SLAB_TYPESAFE_BY_RCU or changing
> the key of an object and re-inserting it in the same table.
> These could only be done safely if new objects were inserted
> at the *start* of a hash chain, and that is not currently the case.
> 
> Signed-off-by: NeilBrown <neilb@...e.com>

Applied to net-next.