How does arp_process() replies to the right device?

Question

Looking at Kernel source code I see that when processing ARP request the net_device is retrieved right from the skb, and then seems like the reply is sent to that device (arp.c#L679):

static int arp_process(struct net *net, struct sock *sk, struct sk_buff *skb)
{
     struct net_device *dev = skb->dev;
     ...
     arp_send_dst(ARPOP_REPLY, ETH_P_ARP,
           sip, dev, tip, sha,
           dev->dev_addr, sha,
           reply_dst);
}

But if the packet went through bridge, then skb got its device overwritten with bridge device:

static int br_pass_frame_up(struct sk_buff *skb)
{
    ...
    skb->dev = brdev;
    ...
}

Shouldn't it some how retrieve the original device and send the reply there?

Answer 1

If the frame arrived from a bridge port, that means now there's a fresh bridge fdb entry telling to use this same bridge port when sending a frame to this MAC address: a reply will be sent to the same bridge port the query arrived from.

So from the point of view of the ARP layer, the packet was received on the bridge interface and the answer also sent back on the bridge interface.

When the reply reaches the lower layer: bridge, that's the bridge code which does a lookup in its Forwarding Database (aka FIB) and chooses as outgoing bridge port the previous incoming bridge port instead of flooding the answer to all of its ports (since there is such a recent entry to be found):

br_device.c:

netdev_tx_t br_dev_xmit(struct sk_buff *skb, struct net_device *dev)
{
...
  } else if ((dst = br_fdb_find_rcu(br, dest, vid)) != NULL) {
      br_forward(dst->dst, skb, false, true);
  } else {
      br_flood(br, skb, BR_PKT_UNICAST, false, true);

Doing the opposite as before, the skb's device bridge interface is overwritten with the bridge port:

br_forward.c:

static void __br_forward(const struct net_bridge_port *to,
           struct sk_buff *skb, bool local_orig)
{
...
      skb->dev = to->dev;
...