All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@nvidia.com>
To: liamsmith827 <liamsmith827@grapheneos.org>
Cc: netdev@vger.kernel.org, David Ahern <dsahern@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Simon Horman <horms@kernel.org>, Shuah Khan <shuah@kernel.org>,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
	Liam Smith <liamsmith827@proton.me>
Subject: Re: [PATCH net-next v3 4/4] ipv4: replace obsolete routing comment
Date: Sun, 15 Nov 2026 10:31:18 +0200	[thread overview]
Message-ID: <20261115083118.GC3764829@shredder> (raw)
In-Reply-To: <20261112235932.23836-5-liamsmith827@grapheneos.org>

On Thu, Nov 12, 2026 at 11:59:32PM +0000, liamsmith827 wrote:
> From: Liam Smith <liamsmith827@proton.me>
> 
> Replace an existing comment which describes obsolete fib_lookup(),
> MSG_DONTROUTE and IPv6 behavior.
> 
> Signed-off-by: Liam Smith <liamsmith827@proton.me>
> ---
>  net/ipv4/route.c | 27 +++++++++++----------------
>  1 file changed, 11 insertions(+), 16 deletions(-)
> 
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 03db105303b4..d862b5ecad71 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -2856,24 +2856,19 @@ struct rtable *ip_route_output_key_hash_rcu(struct net *net, struct flowi4 *fl4,
>  		if (fl4->flowi4_oif &&
>  		    (ipv4_is_multicast(fl4->daddr) ||
>  		     (!fl4->flowi4_l3mdev && err == -ESRCH))) {
> -			/* Apparently, routing tables are wrong. Assume,
> -			 * that the destination is on link.
> +			/* When oif is specified, fib_lookup() is called
> +			 * primarily to determine if the destination is
> +			 * accessible directly or through a gateway. It also
> +			 * checks whether there are any traffic restrictions
> +			 * (blackhole, prohibit, unreachable), or if there's a
> +			 * routing lookup miss.
>  			 *
> -			 * WHY? DW.
> -			 * Because we are allowed to send to iface
> -			 * even if it has NO routes and NO assigned
> -			 * addresses. When oif is specified, routing

The new comment should include the motivation for the fallback.
Something like [1].

> -			 * tables are looked up with only one purpose:
> -			 * to catch if destination is gatewayed, rather than
> -			 * direct. Moreover, if MSG_DONTROUTE is set,
> -			 * we send packet, ignoring both routing tables
> -			 * and ifaddr state. --ANK
> -			 *
> -			 *
> -			 * We could make it even if oif is unknown,
> -			 * likely IPv6, but we do not.
> +			 * This fallback path is always taken for multicast,
> +			 * regardless of any restrictions or misses. Non-vrf
> +			 * unicast does honor restrictions, but falls back if
> +			 * there's a miss. The destination is assumed on-link
> +			 * for both.
>  			 */
> -
>  			if (fl4->saddr == 0)
>  				fl4->saddr = inet_select_addr(dev_out, 0,
>  							      RT_SCOPE_LINK);

[1]
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 18cb8bfc5bfc..0b5f6e9cc437 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2859,24 +2859,18 @@ struct rtable *ip_route_output_key_hash_rcu(struct net *net, struct flowi4 *fl4,
 		if (fl4->flowi4_oif &&
 		    (ipv4_is_multicast(fl4->daddr) ||
 		     (!fl4->flowi4_l3mdev && err == -ESRCH))) {
-			/* Apparently, routing tables are wrong. Assume,
-			 * that the destination is on link.
+			/* We are allowed to send packets via the specified
+			 * interface even if it does not have any routes.
+			 * Upon a lookup miss, assume that the destination is
+			 * on-link, unless the interface is a VRF device or
+			 * enslaved to one.
 			 *
-			 * WHY? DW.
-			 * Because we are allowed to send to iface
-			 * even if it has NO routes and NO assigned
-			 * addresses. When oif is specified, routing
-			 * tables are looked up with only one purpose:
-			 * to catch if destination is gatewayed, rather than
-			 * direct. Moreover, if MSG_DONTROUTE is set,
-			 * we send packet, ignoring both routing tables
-			 * and ifaddr state. --ANK
-			 *
-			 *
-			 * We could make it even if oif is unknown,
-			 * likely IPv6, but we do not.
+			 * Unreachable, blackhole and prohibit routes / rules
+			 * are honored, but not for multicast packets.
+			 * Multicast in a VRF relies on this fallback since
+			 * the lookup hits the unreachable default route in
+			 * the VRF table.
 			 */
-
 			if (fl4->saddr == 0)
 				fl4->saddr = inet_select_addr(dev_out, 0,
 							      RT_SCOPE_LINK);


  reply	other threads:[~2026-11-15  8:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-12 23:59 [PATCH net-next v3 0/4] ipv4: restrict on-link fallback to lookup misses liamsmith827
2026-11-12 23:59 ` [PATCH net-next v3 1/4] ipv4: add FIB_LOOKUP_REPORT_MISS liamsmith827
2026-11-12 23:59 ` [PATCH net-next v3 2/4] ipv4: restrict on-link fallback to lookup misses liamsmith827
2026-11-12 23:59 ` [PATCH net-next v3 3/4] selftests: net: test restricted on-link fallback liamsmith827
2026-11-15  8:30   ` Ido Schimmel
2026-11-12 23:59 ` [PATCH net-next v3 4/4] ipv4: replace obsolete routing comment liamsmith827
2026-11-15  8:31   ` Ido Schimmel [this message]
2026-11-15  8:30 ` [PATCH net-next v3 0/4] ipv4: restrict on-link fallback to lookup misses Ido Schimmel

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=20261115083118.GC3764829@shredder \
    --to=idosch@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@kernel.org \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=liamsmith827@grapheneos.org \
    --cc=liamsmith827@proton.me \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=shuah@kernel.org \
    /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.