On Tue, Jun 30, 2020 at 6:18 PM Martin KaFai Lau <ka...@fb.com> wrote:
>
> When testing a recent kernel (5.6 in our case), the skb->mark of the
> IPv4 TCP RST pkt does not carry the mark from sk->sk_mark. It is
> discovered by the bpf@tc that depends on skb->mark to work properly.
> The same bpf prog has been working in the earlier kernel version.
> After reverting commit c6af0c227a22 ("ip: support SO_MARK cmsg"),
> the skb->mark is set and seen by bpf@tc properly.
>
> We have noticed that in IPv4 TCP RST but it should also
> happen to the ACK based on tcp_v4_send_ack() is also depending
> on ip_send_unicast_reply().
>
> This patch tries to fix it by initializing the ipc.sockc.mark to
> fl4.flowi4_mark.
>
> Fixes: c6af0c227a22 ("ip: support SO_MARK cmsg")
> Cc: Willem de Bruijn <will...@google.com>
> Signed-off-by: Martin KaFai Lau <ka...@fb.com>
> ---
> net/ipv4/ip_output.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
> index 090d3097ee15..033512f719ec 100644
> --- a/net/ipv4/ip_output.c
> +++ b/net/ipv4/ip_output.c
> @@ -1703,6 +1703,7 @@ void ip_send_unicast_reply(struct sock *sk, struct
> sk_buff *skb,
> sk->sk_bound_dev_if = arg->bound_dev_if;
> sk->sk_sndbuf = sysctl_wmem_default;
> sk->sk_mark = fl4.flowi4_mark;
> + ipc.sockc.mark = fl4.flowi4_mark;
> err = ip_append_data(sk, &fl4, ip_reply_glue_bits, arg->iov->iov_base,
> len, 0, &ipc, &rt, MSG_DONTWAIT);
> if (unlikely(err)) {
Yes, this total sense. I missed these cases.
Slight modification, the line above then no longer needs to be set.
That line was added in commit bf99b4ded5f8 ("tcp: fix mark propagation
with fwmark_reflect enabled"). Basically, it pretends that the socket
has a mark associated, but sk here is always the (netns) global
control sock. So your BPF program was depending on fwmark_reflect?
ipv6 seems to work differently enough not to have this problem,
tcp_v6_send_response passing fl6.flowi6_mark directly to ip6_xmit.
This was added in commit commit 92e55f412cff ("tcp: don't annotate
mark on control socket from tcp_v6_send_response()").
But I do see the same pattern where a socket mark is set from a
reflected value in icmp_reply and __icmp_send. Those almost certainly
need updating too. I can do that separately if you prefer. I even
placed ipcm_init right below this sk_mark initialization without
considering ipcm_init_sk. D'oh.
sk->sk_mark = mark;
ipcm_init(&ipc);
