All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guillaume Nault <gnault@redhat.com>
To: dccp@vger.kernel.org
Subject: [PATCH net-next 0/3] ipv4: First steps toward removing RTO_ONLINK
Date: Wed, 20 Apr 2022 23:21:19 +0000	[thread overview]
Message-ID: <cover.1650470610.git.gnault@redhat.com> (raw)

RTO_ONLINK is a flag that allows to reduce the scope of route lookups.
It's stored in a normally unused bit of the ->flowi4_tos field, in
struct flowi4. However it has several problems:

 * This bit is also used by ECN. Although ECN bits are supposed to be
   cleared before doing a route lookup, it happened that some code
   paths didn't properly sanitise their ->flowi4_tos. So this mechanism
   is fragile and we had bugs in the past where ECN bits slipped in and
   could end up being erroneously interpreted as RTO_ONLINK.

 * A dscp_t type was recently introduced to ensure ECN bits are cleared
   during route lookups. ->flowi4_tos is the most important structure
   field to convert, but RTO_ONLINK prevents such conversion, as dscp_t
   mandates that ECN bits (where RTO_ONLINK is stored) be zero.

Therefore we need to stop using RTO_ONLINK altogether. Fortunately
RTO_ONLINK isn't a necessity. Instead of passing a flag in ->flowi4_tos
to tell the route lookup function to restrict the scope, we can simply
initialise the scope correctly.

Patch 1 does some preparatory work: it stops resetting ->flowi4_scope
automatically before a route lookup, thus allowing callers to set their
desired scope without having to rely on the RTO_ONLINK flag.

Patch 2-3 convert a few code paths to avoid relying on RTO_ONLINK.

More conversions will have to take place before we can eventually
remove this flag.

Guillaume Nault (3):
  ipv4: Don't reset ->flowi4_scope in ip_rt_fix_tos().
  ipv4: Avoid using RTO_ONLINK with ip_route_connect().
  ipv4: Initialise ->flowi4_scope properly in ICMP handlers.

 include/net/route.h | 36 ++++++++++++++++++++++++------------
 net/dccp/ipv4.c     |  5 ++---
 net/ipv4/af_inet.c  |  6 +++---
 net/ipv4/datagram.c |  7 +++----
 net/ipv4/route.c    | 41 +++++++++++++++++++----------------------
 net/ipv4/tcp_ipv4.c |  5 ++---
 6 files changed, 53 insertions(+), 47 deletions(-)

-- 
2.21.3

WARNING: multiple messages have this Message-ID (diff)
From: Guillaume Nault <gnault@redhat.com>
To: David Miller <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
Cc: netdev@vger.kernel.org,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	David Ahern <dsahern@kernel.org>,
	dccp@vger.kernel.org
Subject: [PATCH net-next 0/3] ipv4: First steps toward removing RTO_ONLINK
Date: Thu, 21 Apr 2022 01:21:19 +0200	[thread overview]
Message-ID: <cover.1650470610.git.gnault@redhat.com> (raw)

RTO_ONLINK is a flag that allows to reduce the scope of route lookups.
It's stored in a normally unused bit of the ->flowi4_tos field, in
struct flowi4. However it has several problems:

 * This bit is also used by ECN. Although ECN bits are supposed to be
   cleared before doing a route lookup, it happened that some code
   paths didn't properly sanitise their ->flowi4_tos. So this mechanism
   is fragile and we had bugs in the past where ECN bits slipped in and
   could end up being erroneously interpreted as RTO_ONLINK.

 * A dscp_t type was recently introduced to ensure ECN bits are cleared
   during route lookups. ->flowi4_tos is the most important structure
   field to convert, but RTO_ONLINK prevents such conversion, as dscp_t
   mandates that ECN bits (where RTO_ONLINK is stored) be zero.

Therefore we need to stop using RTO_ONLINK altogether. Fortunately
RTO_ONLINK isn't a necessity. Instead of passing a flag in ->flowi4_tos
to tell the route lookup function to restrict the scope, we can simply
initialise the scope correctly.

Patch 1 does some preparatory work: it stops resetting ->flowi4_scope
automatically before a route lookup, thus allowing callers to set their
desired scope without having to rely on the RTO_ONLINK flag.

Patch 2-3 convert a few code paths to avoid relying on RTO_ONLINK.

More conversions will have to take place before we can eventually
remove this flag.

Guillaume Nault (3):
  ipv4: Don't reset ->flowi4_scope in ip_rt_fix_tos().
  ipv4: Avoid using RTO_ONLINK with ip_route_connect().
  ipv4: Initialise ->flowi4_scope properly in ICMP handlers.

 include/net/route.h | 36 ++++++++++++++++++++++++------------
 net/dccp/ipv4.c     |  5 ++---
 net/ipv4/af_inet.c  |  6 +++---
 net/ipv4/datagram.c |  7 +++----
 net/ipv4/route.c    | 41 +++++++++++++++++++----------------------
 net/ipv4/tcp_ipv4.c |  5 ++---
 6 files changed, 53 insertions(+), 47 deletions(-)

-- 
2.21.3


             reply	other threads:[~2022-04-20 23:21 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-20 23:21 Guillaume Nault [this message]
2022-04-20 23:21 ` [PATCH net-next 0/3] ipv4: First steps toward removing RTO_ONLINK Guillaume Nault
2022-04-20 23:21 ` [PATCH net-next 3/3] ipv4: Initialise ->flowi4_scope properly in ICMP handlers Guillaume Nault
2022-04-22  3:08   ` David Ahern
2022-04-22  3:10 ` [PATCH net-next 0/3] ipv4: First steps toward removing RTO_ONLINK David Ahern
2022-04-22  3:10   ` David Ahern
2022-04-22 11:02 ` Guillaume Nault
2022-04-22 11:02   ` Guillaume Nault
2022-04-22 12:50 ` patchwork-bot+netdevbpf
2022-04-22 12:50   ` patchwork-bot+netdevbpf
  -- strict thread matches above, loose matches on Subject: below --
2022-04-20 23:21 [PATCH net-next 1/3] ipv4: Don't reset ->flowi4_scope in ip_rt_fix_tos() Guillaume Nault
2022-04-20 23:21 ` Guillaume Nault
2022-04-22  2:30 ` David Ahern
2022-04-22  2:30   ` David Ahern
2022-04-22 10:53 ` Guillaume Nault
2022-04-22 10:53   ` Guillaume Nault
2022-04-22 14:40 ` David Ahern
2022-04-22 14:40   ` David Ahern
2022-04-25 10:04 ` Guillaume Nault
2022-04-25 10:04   ` Guillaume Nault
2022-04-20 23:21 [PATCH net-next 2/3] ipv4: Avoid using RTO_ONLINK with ip_route_connect() Guillaume Nault
2022-04-20 23:21 ` Guillaume Nault
2022-04-22  2:32 ` David Ahern
2022-04-22  2:32   ` David Ahern

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=cover.1650470610.git.gnault@redhat.com \
    --to=gnault@redhat.com \
    --cc=dccp@vger.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.