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

Date:   Fri, 14 Dec 2018 15:35:32 +0100
From:   Florian Westphal <fw@...len.de>
To:     Wolfgang Walter <linux@...m.de>
Cc:     Florian Westphal <fw@...len.de>,
        David Miller <davem@...emloft.net>,
        herbert@...dor.apana.org.au, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org, steffen.klassert@...unet.com,
        christophe.gouault@...nd.com
Subject: Re: INFO: rcu detected stall in xfrm_hash_rebuild

Wolfgang Walter <linux@...m.de> wrote:

[ CCing Christophe ]

> Am Montag, 10. Dezember 2018, 09:58:56 schrieb David Miller:
> > From: Florian Westphal <fw@...len.de>
> > Date: Mon, 10 Dec 2018 13:47:24 +0100
> > 
> > > After recent tree conversion, we could probably make the exact policies
> > > part of the 'inexact tree' (which would be renamed to 'policy tree' or
> > > some such).
> > > 
> > > Special-casing the exact policies made a lot of sense when we had
> > > a single list for the inexact policies (to keep its length down).
> > > 
> > > But now I think we could try to unify all of this and only maintain
> > > the existing tree-based storage.
> > > 
> > > Would also remove the need to do lookups in two different
> > > data structures (bydst-hash-then-inexact-tree).
> > > 
> > > What do you think?
> > 
> > I think this makes a lot of sense.
> 
> Sites mainly using tunnel mode this certainly makes sense.

Ok.  An alternative would be to remove the support for
policy hash table thresholds (which decide what kinds of policies
go to exact table and which ones go into inexact ones), i.e.
partially revert 880a6fab8f6ba5b5abe59ea6
("xfrm: configure policy hash table thresholds by netlink").

This would remove the need for the rehashing support that
re-sorts the policies into either exact/inexact lists) when the
those tunables are changed.

We could also easily convert the exact table to an rhashtable
then if we wanted to.

I guess we should probably wait to get some operational feedback on the
inexact storage first to see if it really improves things enough to
make threshold tuning unneccessary.

Christophe, whats your take?