From: Steffen Klassert <steffen.klass...@secunet.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 <da...@davemloft.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 :-)
