1. 22 Mar, 2012 18 commits
  2. 17 Mar, 2012 2 commits
  3. 16 Mar, 2012 2 commits
  4. 11 Mar, 2012 1 commit
  5. 08 Mar, 2012 4 commits
  6. 07 Mar, 2012 1 commit
  7. 06 Mar, 2012 8 commits
    • Ben Pfaff's avatar
      openvswitch: Honor dp_ifindex, when specified, for vport lookup by name. · 651a68ea
      Ben Pfaff authored
      
      When OVS_VPORT_ATTR_NAME is specified and dp_ifindex is nonzero, the
      logical behavior would be for the vport name lookup scope to be limited
      to the specified datapath, but in fact the dp_ifindex value was ignored.
      This commit causes the search scope to be honored.
      Signed-off-by: default avatarBen Pfaff <blp@nicira.com>
      Signed-off-by: default avatarJesse Gross <jesse@nicira.com>
      651a68ea
    • Li Wei's avatar
      IPv6: Fix not join all-router mcast group when forwarding set. · d6ddef9e
      Li Wei authored
      
      When forwarding was set and a new net device is register,
      we need add this device to the all-router mcast group.
      Signed-off-by: default avatarLi Wei <lw@cn.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d6ddef9e
    • Pablo Neira Ayuso's avatar
      netfilter: nf_conntrack: fix early_drop with reliable event delivery · 74138511
      Pablo Neira Ayuso authored
      
      If reliable event delivery is enabled and ctnetlink fails to deliver
      the destroy event in early_drop, the conntrack subsystem cannot
      drop any the candidate flow that was planned to be evicted.
      Reported-by: default avatarKerin Millar <kerframil@gmail.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      74138511
    • Florian Westphal's avatar
      bridge: netfilter: don't call iptables on vlan packets if sysctl is off · 739e4505
      Florian Westphal authored
      
      When net.bridge.bridge-nf-filter-vlan-tagged is 0 (default), vlan packets
      arriving should not be sent to ip(6)tables by bridge netfilter.
      
      However, it turns out that we currently always send VLAN packets to
      netfilter, if ..
      a), CONFIG_VLAN_8021Q is enabled ; or
      b), CONFIG_VLAN_8021Q is not set but rx vlan offload is enabled
         on the bridge port.
      
      This is because bridge netfilter treats skb with
      skb->protocol == ETH_P_IP{V6} as "non-vlan packet".
      
      With rx vlan offload on or CONFIG_VLAN_8021Q=y, the vlan header has
      already been removed here, and we cannot rely on skb->protocol alone.
      
      Fix this by only using skb->protocol if the skb has no vlan tag,
      or if a vlan tag is present and filter-vlan-tagged bridge netfilter
      sysctl is enabled.
      
      We cannot remove the skb->protocol == htons(ETH_P_8021Q) test
      because the vlan tag is still around in the CONFIG_VLAN_8021Q=n &&
      "ethtool -K $itf rxvlan off" case.
      
      reproducer:
      iptables -t raw -I PREROUTING -i br0
      iptables -t raw -I PREROUTING -i br0.1
      
      Then send packets to an ip address configured on br0.1 interface.
      Even with net.bridge.bridge-nf-filter-vlan-tagged=0, the 1st rule
      will match instead of the 2nd one.
      
      With this patch applied, the 2nd rule will match instead.
      In the non-local address case, netfilter won't be consulted after
      this patch unless the sysctl is switched on.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      739e4505
    • Pablo Neira Ayuso's avatar
      netfilter: bridge: fix wrong pointer dereference · a157b9d5
      Pablo Neira Ayuso authored
      
      In adf7ff8, a invalid dereference was added in ebt_make_names.
      
      CC [M]  net/bridge/netfilter/ebtables.o
      net/bridge/netfilter/ebtables.c: In function `ebt_make_names':
      net/bridge/netfilter/ebtables.c:1371:20: warning: `t' may be used uninitialized in this function [-Wuninitialized]
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a157b9d5
    • Pablo Neira Ayuso's avatar
      netfilter: ctnetlink: remove incorrect spin_[un]lock_bh on NAT module autoload · 8be619d1
      Pablo Neira Ayuso authored
      Since 7d367e06
      
      , ctnetlink_new_conntrack is called without holding
      the nf_conntrack_lock spinlock. Thus, ctnetlink_parse_nat_setup
      does not require to release that spinlock anymore in the NAT module
      autoload case.
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8be619d1
    • Santosh Nayak's avatar
      netfilter: ebtables: fix wrong name length while copying to user-space · 848edc69
      Santosh Nayak authored
      
      user-space ebtables expects 32 bytes-long names, but xt_match names
      use 29 bytes. We have to copy less 29 bytes and then, make sure we
      fill the remaining bytes with zeroes.
      Signed-off-by: default avatarSantosh Nayak <santoshprasadnayak@gmail.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      848edc69
    • Neal Cardwell's avatar
      tcp: fix tcp_shift_skb_data() to not shift SACKed data below snd_una · 4648dc97
      Neal Cardwell authored
      This commit fixes tcp_shift_skb_data() so that it does not shift
      SACKed data below snd_una.
      
      This fixes an issue whose symptoms exactly match reports showing
      tp->sacked_out going negative since 3.3.0-rc4 (see "WARNING: at
      net/ipv4/tcp_input.c:3418" thread on netdev).
      
      Since 2008 (832d11c5)
      tcp_shift_skb_data() had been shifting SACKed ranges that were below
      snd_una. It checked that the *end* of the skb it was about to shift
      from was above snd_una, but did not check that the end of the actual
      shifted range was above snd_una; this commit adds that check.
      
      Shifting SACKed ranges below snd_una is problematic because for such
      ranges tcp_sacktag_one() short-circuits: it does not declare anything
      as SACKed and does not increase sacked_out.
      
      Before the fixes in commits cc9a672e
      and daef52ba
      
      , shifting SACKed ranges
      below snd_una happened to work because tcp_shifted_skb() was always
      (incorrectly) passing in to tcp_sacktag_one() an skb whose end_seq
      tcp_shift_skb_data() had already guaranteed was beyond snd_una. Hence
      tcp_sacktag_one() never short-circuited and always increased
      tp->sacked_out in this case.
      
      After those two fixes, my testing has verified that shifting SACKed
      ranges below snd_una could cause tp->sacked_out to go negative with
      the following sequence of events:
      
      (1) tcp_shift_skb_data() sees an skb whose end_seq is beyond snd_una,
          then shifts a prefix of that skb that is below snd_una
      
      (2) tcp_shifted_skb() increments the packet count of the
          already-SACKed prev sk_buff
      
      (3) tcp_sacktag_one() sees the end of the new SACKed range is below
          snd_una, so it short-circuits and doesn't increase tp->sacked_out
      
      (5) tcp_clean_rtx_queue() sees the SACKed skb has been ACKed,
          decrements tp->sacked_out by this "inflated" pcount that was
          missing a matching increase in tp->sacked_out, and hence
          tp->sacked_out underflows to a u32 like 0xFFFFFFFF, which casted
          to s32 is negative.
      
      (6) this leads to the warnings seen in the recent "WARNING: at
          net/ipv4/tcp_input.c:3418" thread on the netdev list; e.g.:
          tcp_input.c:3418  WARN_ON((int)tp->sacked_out < 0);
      
      More generally, I think this bug can be tickled in some cases where
      two or more ACKs from the receiver are lost and then a DSACK arrives
      that is immediately above an existing SACKed skb in the write queue.
      
      This fix changes tcp_shift_skb_data() to abort this sequence at step
      (1) in the scenario above by noticing that the bytes are below snd_una
      and not shifting them.
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4648dc97
  8. 05 Mar, 2012 4 commits