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:   Tue, 4 Aug 2020 07:52:47 +0200
From:   Stefano Brivio <sbrivio@...hat.com>
To:     David Ahern <dsahern@...il.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Florian Westphal <fw@...len.de>,
        Aaron Conole <aconole@...hat.com>,
        Numan Siddique <nusiddiq@...hat.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Pravin B Shelar <pshelar@....org>,
        Roopa Prabhu <roopa@...ulusnetworks.com>,
        Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
        Lourdes Pedrajas <lu@...o.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 1/6] ipv4: route: Ignore output interface in
 FIB lookup for PMTU route

On Mon, 3 Aug 2020 17:30:46 -0600
David Ahern <dsahern@...il.com> wrote:

> On 8/3/20 2:52 PM, Stefano Brivio wrote:
> > diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> > index a01efa062f6b..c14fd8124f57 100644
> > --- a/net/ipv4/route.c
> > +++ b/net/ipv4/route.c
> > @@ -1050,6 +1050,7 @@ static void ip_rt_update_pmtu(struct dst_entry *dst, struct sock *sk,
> >  	struct flowi4 fl4;
> >  
> >  	ip_rt_build_flow_key(&fl4, sk, skb);
> > +	fl4.flowi4_oif = 0;	/* Don't make lookup fail for encapsulations */
> >  	__ip_rt_update_pmtu(rt, &fl4, mtu);
> >  }
> >  
> 
> Can this be limited to:
> 	if (skb &&
> 	    netif_is_bridge_port(skb->dev) || netif_is_ovs_port(skb->dev))
> 		fl4.flowi4_oif = 0;
> 
> I'm not sure we want to reset oif for all MTU updates.

I think that generally speaking we might, because this is about the
*path* MTU after all, so the output interface doesn't look very
relevant.

On the other hand, I couldn't find any other case where this makes a
difference, and I guess it's better to eventually find out about those
other cases if any, rather than fixing things by accident possibly in
the wrong way.

Changed in v2, thanks.

-- 
Stefano

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ