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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 14 Dec 2018 14:11:05 +0100
From:   Wolfgang Walter <linux@...m.de>
To:     Florian Westphal <fw@...len.de>
Cc:     David Miller <davem@...emloft.net>, 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

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.

I'm not so sure for transport mode. With transport mode the netmask usually is 
/32 or /128, respectively (there may also be trap-rules). So a site only using 
transport mode (road warrior scenario, for example) may see a large 
performance regression if this is changed. They may do not have many entries 
in the inexact list if any at all.

Maybe there are a lot more transport mode users than tunnel mode users, this 
would explain why the removal of the flowcache did not hit that many people.

We do not use transport mode, so I'm not familiar how strongswan for example 
handles that. I think that since 5.3 or so strongwans allows a catch rule 
(inexact) and then inserts exact policy rules on the fly. But I don't know for 
sure. There are a lot of tests on strongswan for different scenarios which 
also demonstrate how policy and state table finally will look like on all 
hosts.

Here is one with such a scenario (transport mode trap policy on a gateway, 
three road warriors):

https://www.strongswan.org/testing/testresults/ikev2/trap-any/

So I would try to find users who are heavy users of transport mode and see how 
this change would impact there performance.

Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts