Re: [PATCH net-next 06/15] ipv4: Merge ip_local_out and ip_local_out_sk

To: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
Subject: Re: [PATCH net-next 06/15] ipv4: Merge ip_local_out and ip_local_out_sk
Cc: David Miller <davem@xxxxxxxxxxxxx>, netfilter-devel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxxxxxx, lvs-devel@xxxxxxxxxxxxxxx, Eric Dumazet <eric.dumazet@xxxxxxxxx>
From: Nicolas Dichtel <nicolas.dichtel@xxxxxxxxx>
Date: Thu, 8 Oct 2015 11:38:56 +0200
Le 07/10/2015 22:39, Eric W. Biederman a écrit :
Nicolas Dichtel <nicolas.dichtel@xxxxxxxxx> writes:

Le 06/10/2015 20:53, Eric W. Biederman a écrit :
It is confusing and silly hiding a paramater so modify all of
the callers to pass in the appropriate socket or skb->sk if
no socket is known.

Signed-off-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
@@ -456,7 +456,7 @@ packet_routed:
        skb->priority = sk->sk_priority;
        skb->mark = sk->sk_mark;

-       res = ip_local_out(skb);
+       res = ip_local_out(sk, skb);
As stated in the comment at the top of this function (ip_queue_xmit()), skb->sk
can be different from sk. See also commit b0270e91014d ("ipv4: add a sock
pointer to ip_queue_xmit()").
Not sure if this change is right.

Good catch.  This change should not have been buried in this patch. It
needs to be it's own separate bug fix.

As I read the code we actually do want to pass sk not skb->sk into
ip_local_out.  For all of the reasons that sk is potentially different
from skb->sk already.

The way I understand this is we have pushed an sk parameter through the
output path so that sk_mc_loop(sk) can be called with the tunnel's
socket not whatever is on skb->sk.  This allows for looking to see if
local multicast loopback is configured on the tunnels socket not on the
originating socket of the packet.
Ok, thank you for the explanation.
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

<Prev in Thread] Current Thread [Next in Thread>