1. 02 4月, 2012 31 次提交
  2. 30 3月, 2012 2 次提交
    • Z
      x86 bpf_jit: fix a bug in emitting the 16-bit immediate operand of AND · 1d24fb36
      zhuangfeiran@ict.ac.cn 提交于
      When K >= 0xFFFF0000, AND needs the two least significant bytes of K as
      its operand, but EMIT2() gives it the least significant byte of K and
      0x2. EMIT() should be used here to replace EMIT2().
      Signed-off-by: NFeiran Zhuang  <zhuangfeiran@ict.ac.cn>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1d24fb36
    • W
      bonding: emit event when bonding changes MAC · 7d26bb10
      Weiping Pan 提交于
      When a bonding device is configured with fail_over_mac=active,
      we expect to see the MAC address of the new active slave as the source MAC
      address after failover. But we see that the source MAC address is the MAC
      address of previous active slave.
      
      Emit NETDEV_CHANGEADDR event when bonding changes its MAC address, in order
      to let arp_netdev_event flush neighbour cache and route cache.
      
      How to reproduce this bug ?
      
                             -----------hostB----------------
      hostA ----- switch ---|-- eth0--bond0(192.168.100.2/24)|
      (192.168.100.1/24  \--|-- eth1-/                       |
                             --------------------------------
      
      1 on hostB,
      modprobe bonding mode=1 miimon=500 fail_over_mac=active downdelay=1000
      num_grat_arp=1
      ifconfig bond0 192.168.100.2/24 up
      ifenslave bond0 eth0
      ifenslave bond0 eth1
      
      then eth0 is the active slave, and MAC of bond0 is MAC of eth0.
      
      2 on hostA, ping 192.168.100.2
      
      3 on hostB,
      tcpdump -i bond0 -p icmp -XXX
      you will see bond0 uses MAC of eth0 as source MAC in icmp reply.
      
      4 on hostB,
      ifconfig eth0 down
      tcpdump -i bond0 -p icmp -XXX (just keep it running in step 3)
      you will see first bond0 uses MAC of eth1 as source MAC in icmp
      reply, then it will use MAC of eth0 as source MAC.
      Signed-off-by: NWeiping Pan <wpan@redhat.com>
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7d26bb10
  3. 29 3月, 2012 5 次提交
  4. 28 3月, 2012 2 次提交
    • B
      net/core: dev_forward_skb() should clear skb_iif · 3b9785c6
      Benjamin LaHaise 提交于
      While investigating another bug, I found that the code on the incoming path
      in __netif_receive_skb will only set skb->skb_iif if it is already 0.  When
      dev_forward_skb() is used in the case of interfaces like veth, skb_iif may
      already have been set.  Making dev_forward_skb() cause the packet to look
      like a newly received packet would seem to the the correct behaviour here,
      as otherwise the wrong incoming interface can be reported for such a packet.
      Signed-off-by: NBenjamin LaHaise <bcrl@kvack.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3b9785c6
    • B
      net/ipv4: fix IPv4 multicast over network namespaces · 4e7b2f14
      Benjamin LaHaise 提交于
      When using multicast over a local bridge feeding a number of LXC guests
      using veth, the LXC guests are unable to get a response from other guests
      when pinging 224.0.0.1.  Multicast packets did not appear to be getting
      delivered to the network namespaces of the guest hosts, and further
      inspection showed that the incoming route was pointing to the loopback
      device of the host, not the guest.  This lead to the wrong network namespace
      being picked up by sockets (like ICMP).  Fix this by using the correct
      network namespace when creating the inbound route entry.
      Signed-off-by: NBenjamin LaHaise <bcrl@kvack.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4e7b2f14
新手
引导
客服 返回
顶部