1. 01 Jul, 2013 19 commits
  2. 30 Jun, 2013 1 commit
    • Florian Westphal's avatar
      netfilter: nf_queue: add NFQA_SKB_CSUM_NOTVERIFIED info flag · 496e4ae7
      Florian Westphal authored
      The common case is that TCP/IP checksums have already been
      verified, e.g. by hardware (rx checksum offload), or conntrack.
      
      Userspace can use this flag to determine when the checksum
      has not been validated yet.
      
      If the flag is set, this doesn't necessarily mean that the packet has
      an invalid checksum, e.g. if NIC doesn't support rx checksum.
      
      Userspace that sucessfully enabled NFQA_CFG_F_GSO queue feature flag can
      infer that IP/TCP checksum has already been validated if either the
      SKB_INFO attribute is not present or the NFQA_SKB_CSUM_NOTVERIFIED
      flag is unset.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      496e4ae7
  3. 29 Jun, 2013 14 commits
  4. 28 Jun, 2013 6 commits
    • John W. Linville's avatar
      Merge branch 'master' of... · 57ed5cd6
      John W. Linville authored
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem
      
      Conflicts:
      	net/wireless/nl80211.c
      57ed5cd6
    • nikolay@redhat.com's avatar
      bonding: when cloning a MAC use NET_ADDR_STOLEN · ae0d6750
      nikolay@redhat.com authored
      A simple semantic change, when a slave's MAC is cloned by the bond
      master then set addr_assign_type to NET_ADDR_STOLEN instead of
      NET_ADDR_SET. Also use bond_set_dev_addr() in BOND_FOM_ACTIVE mode
      to change the bond's MAC address because the assign_type has to be
      set properly.
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ae0d6750
    • nikolay@redhat.com's avatar
      bonding: remove unnecessary dev_addr_from_first member · 97a1e639
      nikolay@redhat.com authored
      In struct bonding there's a member called dev_addr_from_first which is
      used to denote when the bond dev should clone the first slave's MAC
      address but since we have netdev's addr_assign_type variable that is not
      necessary. We clone the first slave's MAC each time we have a random MAC
      set to the bond device. This has the nice side-effect of also fixing an
      inconsistency - when the MAC address of the bond dev is set after its
      creation, but prior to having slaves, it's not kept and the first slave's
      MAC is cloned. The only way to keep the MAC was to create the bond device
      with the MAC address set (e.g. through ip link). In all cases if the
      bond device is left without any slaves - its MAC gets reset to a random
      one as before.
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      97a1e639
    • nikolay@redhat.com's avatar
      bonding: remove unnecessary setup_by_slave member · 8d2ada77
      nikolay@redhat.com authored
      We have a member called setup_by_slave in struct bonding to denote if the
      bond dev has different type than ARPHRD_ETHER, but that is already denoted
      in bond's netdev type variable if it was setup by the slave, so use that
      instead of the member.
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8d2ada77
    • Pablo Neira's avatar
      netlink: fix splat in skb_clone with large messages · 3a36515f
      Pablo Neira authored
      Since (c05cdb1b netlink: allow large data transfers from user-space),
      netlink splats if it invokes skb_clone on large netlink skbs since:
      
      * skb_shared_info was not correctly initialized.
      * skb->destructor is not set in the cloned skb.
      
      This was spotted by trinity:
      
      [  894.990671] BUG: unable to handle kernel paging request at ffffc9000047b001
      [  894.991034] IP: [<ffffffff81a212c4>] skb_clone+0x24/0xc0
      [...]
      [  894.991034] Call Trace:
      [  894.991034]  [<ffffffff81ad299a>] nl_fib_input+0x6a/0x240
      [  894.991034]  [<ffffffff81c3b7e6>] ? _raw_read_unlock+0x26/0x40
      [  894.991034]  [<ffffffff81a5f189>] netlink_unicast+0x169/0x1e0
      [  894.991034]  [<ffffffff81a601e1>] netlink_sendmsg+0x251/0x3d0
      
      Fix it by:
      
      1) introducing a new netlink_skb_clone function that is used in nl_fib_input,
         that sets our special skb->destructor in the cloned skb. Moreover, handle
         the release of the large cloned skb head area in the destructor path.
      
      2) not allowing large skbuffs in the netlink broadcast path. I cannot find
         any reasonable use of the large data transfer using netlink in that path,
         moreover this helps to skip extra skb_clone handling.
      
      I found two more netlink clients that are cloning the skbs, but they are
      not in the sendmsg path. Therefore, the sole client cloning that I found
      seems to be the fib frontend.
      
      Thanks to Eric Dumazet for helping to address this issue.
      Reported-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3a36515f
    • Nicolas Dichtel's avatar
      sit: add support of x-netns · 5e6700b3
      Nicolas Dichtel authored
      This patch allows to switch the netns when packet is encapsulated or
      decapsulated. In other word, the encapsulated packet is received in a netns,
      where the lookup is done to find the tunnel. Once the tunnel is found, the
      packet is decapsulated and injecting into the corresponding interface which
      stands to another netns.
      
      When one of the two netns is removed, the tunnel is destroyed.
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5e6700b3