netdev - Re: [RFC PATCH 07/12] xfrm: Move child route linkage into xfrm

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: <20171026.164450.1372666046811272701.davem@davemloft.net>
Date:   Thu, 26 Oct 2017 16:44:50 +0900 (KST)
From:   David Miller <davem@...emloft.net>
To:     steffen.klassert@...unet.com
Cc:     netdev@...r.kernel.org
Subject: Re: [RFC PATCH 07/12] xfrm: Move child route linkage into xfrm_dst.

From: Steffen Klassert <steffen.klassert@...unet.com>
Date: Thu, 26 Oct 2017 09:03:11 +0200

> On Wed, Oct 25, 2017 at 11:03:59PM +0900, David Miller wrote:
>> 
>> XFRM bundle child chains look like this:
>> 
>> 	xdst1 --> xdst2 --> xdst3 --> path_dst
>> 
>> All of xdstN are xfrm_dst objects and xdst->u.dst.xfrm is non-NULL.
>> The final child pointer in the chain, here called 'path_dst', is some
>> other kind of route such as an ipv4 or ipv6 one.
>> 
>> The xfrm output path pops routes, one at a time, via the child
>> pointer, until we hit one which has a dst->xfrm pointer which
>> is NULL.
>> 
>> We can easily preserve the above mechanisms with child sitting
>> only in the xfrm_dst structure.  All children in the chain
>> before we break out of the xfrm_output() loop have dst->xfrm
>> non-NULL and are therefore xfrm_dst objects.
>> 
>> Since we break out of the loop when we find dst->xfrm NULL, we
>> will not try to dereference 'dst' as if it were an xfrm_dst.
>> 
>> Signed-off-by: David S. Miller <davem@...emloft.net>
> 
> This one seems to be somewhat screwed up, it does not apply.
> Looks like your mail contains two patches, both have some overlap.

Weird, it's exactly like that in the *.patch file I generated
too.

I just tried to regenerate it using:

	git format-patch master..dst-shrink

'dst-shrink' is the branch where I work on this stuff.  And I
get the same exact result.

Weird.

Can't say that I've ever seen anything like this before :-)