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. You have: > --- > include/net/dst.h | 12 +----------- > include/net/xfrm.h | 14 ++++++++++++-- > net/core/dst.c | 2 +- > net/core/pktgen.c | 12 ++++++------ > 4 files changed, 20 insertions(+), 20 deletions(-) > And: > --- > include/net/dst.h | 3 +-- > include/net/xfrm.h | 13 +++++++++---- > net/core/dst.c | 9 ++++++--- > net/core/pktgen.c | 12 ++++++------ > net/netfilter/xt_policy.c | 3 ++- > net/xfrm/xfrm_device.c | 2 +- > 6 files changed, 25 insertions(+), 17 deletions(-) >
