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]
Message-ID: <CA+FuTSd=x3TDKjmtZZv3Hv1L=zMKSoSc4nt3wgcFhvJc-KB+tA@mail.gmail.com>
Date:   Sun, 16 Feb 2020 21:19:24 -0800
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Martin Varghese <martinvarghesenokia@...il.com>
Cc:     Willem de Bruijn <willemdebruijn.kernel@...il.com>,
        Network Development <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Jonathan Corbet <corbet@....net>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        scott.drennan@...ia.com, Jiri Benc <jbenc@...hat.com>,
        martin.varghese@...ia.com
Subject: Re: [PATCH net-next v7 1/2] net: UDP tunnel encapsulation module for
 tunnelling different protocols like MPLS,IP,NSH etc.

> > > diff --git a/include/net/ipv6.h b/include/net/ipv6.h
> > > index cec1a54..1bf8065 100644
> > > --- a/include/net/ipv6.h
> > > +++ b/include/net/ipv6.h
> > > @@ -1027,6 +1027,12 @@ struct dst_entry *ip6_dst_lookup_flow(struct net *net, const struct sock *sk, st
> > >  struct dst_entry *ip6_sk_dst_lookup_flow(struct sock *sk, struct flowi6 *fl6,
> > >                                          const struct in6_addr *final_dst,
> > >                                          bool connected);
> > > +struct dst_entry *ip6_dst_lookup_tunnel(struct sk_buff *skb,
> > > +                                       struct net_device *dev,
> > > +                                       struct net *net, struct socket *sock,
> > > +                                       struct in6_addr *saddr,
> > > +                                       const struct ip_tunnel_info *info,
> > > +                                       u8 protocol, bool use_cache);
> > >  struct dst_entry *ip6_blackhole_route(struct net *net,
> > >                                       struct dst_entry *orig_dst);
> > >
> > > diff --git a/include/net/route.h b/include/net/route.h
> > > index a9c60fc..81750ae 100644
> > > --- a/include/net/route.h
> > > +++ b/include/net/route.h
> > > @@ -128,6 +128,12 @@ static inline struct rtable *__ip_route_output_key(struct net *net,
> > >
> > >  struct rtable *ip_route_output_flow(struct net *, struct flowi4 *flp,
> > >                                     const struct sock *sk);
> > > +struct rtable *ip_route_output_tunnel(struct sk_buff *skb,
> > > +                                     struct net_device *dev,
> > > +                                     struct net *net, __be32 *saddr,
> > > +                                     const struct ip_tunnel_info *info,
> > > +                                     u8 protocol, bool use_cache);
> > > +
> > >  struct dst_entry *ipv4_blackhole_route(struct net *net,
> > >                                        struct dst_entry *dst_orig);
> > >
> >
> > Ah, I now see where the difference between net/ipv4/route.c and
> > net/ipv6/ip6_output.c come from. It follows from existing locations of
> >  ip6_sk_dst_lookup_flow and ip_route_output_flow.
> >
> > Looking for the ipv6 analog of ip_route_output_flow, I see that, e.g.,
> > ipvlan uses ip6_route_output from net/ipv6/route.c without a NULL sk.
> > But ping calls ip6_sk_dst_lookup_flow.
> >
> > It might be a better fit behind ip6_route_output_flags, but it's
> > probably moot, really.
>
> Actually i considered both the files but i felt this function
> should naturally sit with ip6_sk_dst_lookup_flow.
> If you dont have strong objection i would like to keep the
> function in ip6_output.c

Yes, sounds good, thanks. The difference stood out to me in an initial
git show --stat, but on closer reading both choices can be argued for.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ