All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Ahern <dsahern@kernel.org>
To: Jan Luebbe <jluebbe@lasnet.de>,
	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: Sat, 11 Jun 2022 10:44:50 -0600	[thread overview]
Message-ID: <6410890e-333d-5f0e-52f2-1041667c80f8@kernel.org> (raw)
In-Reply-To: <a54c149aed38fded2d3b5fdb1a6c89e36a083b74.camel@lasnet.de>

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.

...

> 
> 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.

  reply	other threads:[~2022-06-11 16:44 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 [this message]
2022-06-15 17:47   ` Jan Luebbe
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=6410890e-333d-5f0e-52f2-1041667c80f8@kernel.org \
    --to=dsahern@kernel.org \
    --cc=aroulin@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=jluebbe@lasnet.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.