netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Luebbe <jluebbe@lasnet.de>
To: David Ahern <dsahern@kernel.org>,
	Robert Shearman <robertshearman@gmail.com>,
	Andy Roulin <aroulin@nvidia.com>
Cc: Mike Manning <mvrmanning@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org, regressions@lists.linux.dev,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [REGRESSION] connection timeout with routes to VRF
Date: Wed, 15 Jun 2022 19:47:44 +0200	[thread overview]
Message-ID: <3d0991cf30d6429e8dd059f7e0d1c54a2200c5a0.camel@lasnet.de> (raw)
In-Reply-To: <6410890e-333d-5f0e-52f2-1041667c80f8@kernel.org>

On Sat, 2022-06-11 at 10:44 -0600, David Ahern wrote:
> On 6/11/22 5:14 AM, Jan Luebbe wrote:
> > Hi,
> > 
> > TL;DR: We think we have found a regression in the handling of VRF route
> > leaking
> > caused by "net: allow binding socket in a VRF when there's an unbound
> > socket"
> > (3c82a21f4320).
> 
> This is the 3rd report in the past few months about this commit.
> 
> ...

Hmm, I've not been able to find other reports. Could you point me to them?

> > 
> > Our minimized test case looks like this:
> >  ip rule add pref 32765 from all lookup local
> >  ip rule del pref 0 from all lookup local
> >  ip link add red type vrf table 1000
> >  ip link set red up
> >  ip route add vrf red unreachable default metric 8192
> >  ip addr add dev red 172.16.0.1/24
> >  ip route add 172.16.0.0/24 dev red
> >  ip vrf exec red socat -dd TCP-LISTEN:1234,reuseaddr,fork SYSTEM:"echo
> > connected" &
> >  sleep 1
> >  nc 172.16.0.1 1234 < /dev/null
> > 
> 
> ...
> Thanks for the detailed analysis and reproducer.
> 
> > 
> > The partial revert
> > diff --git a/include/net/inet_hashtables.h b/include/net/inet_hashtables.h
> > index 98e1ec1a14f0..41e7f20d7e51 100644
> > --- a/include/net/inet_hashtables.h
> > +++ b/include/net/inet_hashtables.h
> > @@ -310,8 +310,9 @@ static inline struct sock *inet_lookup_listener(struct
> > net *net,
> >  #define INET_MATCH(__sk, __net, __cookie, __saddr, __daddr, __ports, __dif,
> > __sdif) \
> >         (((__sk)->sk_portpair == (__ports))                     &&      \
> >          ((__sk)->sk_addrpair == (__cookie))                    &&      \
> > -        (((__sk)->sk_bound_dev_if == (__dif))                  ||      \
> > -         ((__sk)->sk_bound_dev_if == (__sdif)))                &&      \
> > +        (!(__sk)->sk_bound_dev_if      ||                              \
> > +          ((__sk)->sk_bound_dev_if == (__dif))                 ||      \
> > +          ((__sk)->sk_bound_dev_if == (__sdif)))               &&      \
> >          net_eq(sock_net(__sk), (__net)))
> >  #else /* 32-bit arch */
> >  #define INET_ADDR_COOKIE(__name, __saddr, __daddr) \
> > @@ -321,8 +322,9 @@ static inline struct sock *inet_lookup_listener(struct
> > net *net,
> >         (((__sk)->sk_portpair == (__ports))             &&              \
> >          ((__sk)->sk_daddr      == (__saddr))           &&              \
> >          ((__sk)->sk_rcv_saddr  == (__daddr))           &&              \
> > -        (((__sk)->sk_bound_dev_if == (__dif))          ||              \
> > -         ((__sk)->sk_bound_dev_if == (__sdif)))        &&              \
> > +        (!(__sk)->sk_bound_dev_if      ||                              \
> > +          ((__sk)->sk_bound_dev_if == (__dif))         ||              \
> > +          ((__sk)->sk_bound_dev_if == (__sdif)))       &&              \
> >          net_eq(sock_net(__sk), (__net)))
> >  #endif /* 64-bit arch */
> > 
> > restores the original behavior when applied on v5.18. This doesn't apply
> > directly on master, as the macro was replaced by an inline function in
> > "inet:
> > add READ_ONCE(sk->sk_bound_dev_if) in INET_MATCH()" (4915d50e300e).
> > 
> > I have to admit I don't quite understand 3c82a21f4320, so I'm not sure how
> > to proceed. What would be broken by the partial revert above? Are there
> > better ways to configure routing into the VRF than simply "ip route add
> > 172.16.0.0/24 dev red" that still work?
> > 
> > Thanks,
> > Jan
> > 
> > #regzbot introduced: 3c82a21f4320
> > 
> > 
> > 
> 
> Andy Roulin suggested the same fix to the same problem a few weeks back.
> Let's do it along with a test case in fcnl-test.sh which covers all of
> these vrf permutations.

Thanks! I'd be happy to test any patch in our real setup.

Regards,
Jan



  reply	other threads:[~2022-06-15 17:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-11 11:14 [REGRESSION] connection timeout with routes to VRF Jan Luebbe
2022-06-11 16:44 ` David Ahern
2022-06-15 17:47   ` Jan Luebbe [this message]
2022-06-16 13:27     ` David Ahern
2022-06-26 20:06   ` Mike Manning
2022-07-06 18:49     ` Jan Luebbe
2022-07-17 10:31       ` Mike Manning
2022-07-17 19:27         ` Jan Lübbe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3d0991cf30d6429e8dd059f7e0d1c54a2200c5a0.camel@lasnet.de \
    --to=jluebbe@lasnet.de \
    --cc=aroulin@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mvrmanning@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=regressions@lists.linux.dev \
    --cc=robertshearman@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).