From: Florian Westphal <fw@strlen.de>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>,
netfilter-devel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH nf 2/2] netfilter: use actual socket sk rather than skb sk when routing harder
Date: Thu, 29 Oct 2020 10:28:38 +0100 [thread overview]
Message-ID: <20201029092838.GC15770@breakpoint.cc> (raw)
In-Reply-To: <20201029025606.3523771-3-Jason@zx2c4.com>
Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> If netfilter changes the packet mark when mangling, the packet is
> rerouted using the route_me_harder set of functions. Prior to this
> commit, there's one big difference between route_me_harder and the
> ordinary initial routing functions, described in the comment above
> __ip_queue_xmit():
>
> /* Note: skb->sk can be different from sk, in case of tunnels */
> int __ip_queue_xmit(struct sock *sk, struct sk_buff *skb, struct flowi *fl,
>
> That function goes on to correctly make use of sk->sk_bound_dev_if,
> rather than skb->sk->sk_bound_dev_if. And indeed the comment is true: a
> tunnel will receive a packet in ndo_start_xmit with an initial skb->sk.
> It will make some transformations to that packet, and then it will send
> the encapsulated packet out of a *new* socket. That new socket will
> basically always have a different sk_bound_dev_if (otherwise there'd be
> a routing loop). So for the purposes of routing the encapsulated packet,
> the routing information as it pertains to the socket should come from
> that socket's sk, rather than the packet's original skb->sk. For that
> reason __ip_queue_xmit() and related functions all do the right thing.
>
> One might argue that all tunnels should just call skb_orphan(skb) before
> transmitting the encapsulated packet into the new socket. But tunnels do
> *not* do this -- and this is wisely avoided in skb_scrub_packet() too --
> because features like TSQ rely on skb->destructor() being called when
> that buffer space is truely available again. Calling skb_orphan(skb) too
> early would result in buffers filling up unnecessarily and accounting
> info being all wrong. Instead, additional routing must take into account
> the new sk, just as __ip_queue_xmit() notes.
>
> So, this commit addresses the problem by fishing the correct sk out of
> state->sk -- it's already set properly in the call to nf_hook() in
> __ip_local_out(), which receives the sk as part of its normal
> functionality. So we make sure to plumb state->sk through the various
> route_me_harder functions, and then make correct use of it following the
> example of __ip_queue_xmit().
Reviewed-by: Florian Westphal <fw@strlen.de>
next prev parent reply other threads:[~2020-10-29 9:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-29 2:56 [PATCH nf 0/2] route_me_harder routing loop with tunnels Jason A. Donenfeld
2020-10-29 2:56 ` [PATCH nf 1/2] wireguard: selftests: check that route_me_harder packets use the right sk Jason A. Donenfeld
2020-10-29 2:56 ` [PATCH nf 2/2] netfilter: use actual socket sk rather than skb sk when routing harder Jason A. Donenfeld
2020-10-29 9:28 ` Florian Westphal [this message]
2020-10-29 12:01 ` Jason A. Donenfeld
2020-10-29 12:02 ` Jason A. Donenfeld
2020-10-30 19:23 ` [PATCH nf 0/2] route_me_harder routing loop with tunnels Pablo Neira Ayuso
2020-10-31 0:05 ` Jason A. Donenfeld
2020-10-31 1:00 ` Pablo Neira Ayuso
2020-10-31 1:08 ` Pablo Neira Ayuso
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=20201029092838.GC15770@breakpoint.cc \
--to=fw@strlen.de \
--cc=Jason@zx2c4.com \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.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 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).