linux-kernel - Re: INFO: rcu detected stall in xfrm_hash

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]

Date:   Fri, 14 Dec 2018 11:07:05 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     fw@...len.de
Cc:     christophe.gouault@...nd.com, linux@...m.de,
        herbert@...dor.apana.org.au, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org, steffen.klassert@...unet.com
Subject: Re: INFO: rcu detected stall in xfrm_hash_rebuild

From: Florian Westphal <fw@...len.de>
Date: Fri, 14 Dec 2018 17:23:33 +0100

> Christophe Gouault <christophe.gouault@...nd.com> wrote:
>> The main use cases I have encountered and tried to address with the
>> hash-based lookup were network operator use cases:
>> - a lot of dynamic /32 <=> /32 policies (protecting GTP tunnels)
>> - or a lot of dynamic policies with the same prefix lengths (e.g. /16 <=> /24)
>> and a few non-hashed policies stored in the linked list.
> 
> Thanks for the detailed information.
> 
> [..]
> 
>> Could you verify how the configuration time would behave in such use
>> cases if the hash-based lookup was replaced by a tree-based lookup?
> 
> I won't send a patch to remove your work, at least not at this time.
> 
> In case I'd do this removal (thresholds, hash table, or both)
> i will make these tests to see how large the impact is.

Florian, thanks for working so hard on this.

The operational feedback is absolutely essential for figuring out how
to move forward on this issue, otherwise we'll just keep going back
and forth on the approach.