1. 22 3月, 2012 15 次提交
  2. 17 3月, 2012 2 次提交
  3. 16 3月, 2012 2 次提交
  4. 12 3月, 2012 1 次提交
  5. 08 3月, 2012 5 次提交
  6. 07 3月, 2012 8 次提交
    • B
      openvswitch: Honor dp_ifindex, when specified, for vport lookup by name. · 651a68ea
      Ben Pfaff 提交于
      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: NBen Pfaff <blp@nicira.com>
      Signed-off-by: NJesse Gross <jesse@nicira.com>
      651a68ea
    • L
      IPv6: Fix not join all-router mcast group when forwarding set. · d6ddef9e
      Li Wei 提交于
      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: NLi Wei <lw@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d6ddef9e
    • P
      netfilter: nf_conntrack: fix early_drop with reliable event delivery · 74138511
      Pablo Neira Ayuso 提交于
      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: NKerin Millar <kerframil@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      74138511
    • F
      bridge: netfilter: don't call iptables on vlan packets if sysctl is off · 739e4505
      Florian Westphal 提交于
      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: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      739e4505
    • P
      netfilter: bridge: fix wrong pointer dereference · a157b9d5
      Pablo Neira Ayuso 提交于
      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: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a157b9d5
    • P
      netfilter: ctnetlink: remove incorrect spin_[un]lock_bh on NAT module autoload · 8be619d1
      Pablo Neira Ayuso 提交于
      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: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8be619d1
    • S
      netfilter: ebtables: fix wrong name length while copying to user-space · 848edc69
      Santosh Nayak 提交于
      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: NSantosh Nayak <santoshprasadnayak@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      848edc69
    • N
      tcp: fix tcp_shift_skb_data() to not shift SACKed data below snd_una · 4648dc97
      Neal Cardwell 提交于
      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: NNeal Cardwell <ncardwell@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4648dc97
  7. 06 3月, 2012 1 次提交
  8. 05 3月, 2012 3 次提交
  9. 04 3月, 2012 1 次提交
    • N
      tcp: don't fragment SACKed skbs in tcp_mark_head_lost() · c0638c24
      Neal Cardwell 提交于
      In tcp_mark_head_lost() we should not attempt to fragment a SACKed skb
      to mark the first portion as lost. This is for two primary reasons:
      
      (1) tcp_shifted_skb() coalesces adjacent regions of SACKed skbs. When
      doing this, it preserves the sum of their packet counts in order to
      reflect the real-world dynamics on the wire. But given that skbs can
      have remainders that do not align to MSS boundaries, this packet count
      preservation means that for SACKed skbs there is not necessarily a
      direct linear relationship between tcp_skb_pcount(skb) and
      skb->len. Thus tcp_mark_head_lost()'s previous attempts to fragment
      off and mark as lost a prefix of length (packets - oldcnt)*mss from
      SACKed skbs were leading to occasional failures of the WARN_ON(len >
      skb->len) in tcp_fragment() (which used to be a BUG_ON(); see the
      recent "crash in tcp_fragment" thread on netdev).
      
      (2) there is no real point in fragmenting off part of a SACKed skb and
      calling tcp_skb_mark_lost() on it, since tcp_skb_mark_lost() is a NOP
      for SACKed skbs.
      Signed-off-by: NNeal Cardwell <ncardwell@google.com>
      Acked-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Acked-by: NYuchung Cheng <ycheng@google.com>
      Acked-by: NNandita Dukkipati <nanditad@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c0638c24
  10. 29 2月, 2012 1 次提交
    • N
      tcp: fix false reordering signal in tcp_shifted_skb · 4c90d3b3
      Neal Cardwell 提交于
      When tcp_shifted_skb() shifts bytes from the skb that is currently
      pointed to by 'highest_sack' then the increment of
      TCP_SKB_CB(skb)->seq implicitly advances tcp_highest_sack_seq(). This
      implicit advancement, combined with the recent fix to pass the correct
      SACKed range into tcp_sacktag_one(), caused tcp_sacktag_one() to think
      that the newly SACKed range was before the tcp_highest_sack_seq(),
      leading to a call to tcp_update_reordering() with a degree of
      reordering matching the size of the newly SACKed range (typically just
      1 packet, which is a NOP, but potentially larger).
      
      This commit fixes this by simply calling tcp_sacktag_one() before the
      TCP_SKB_CB(skb)->seq advancement that can advance our notion of the
      highest SACKed sequence.
      
      Correspondingly, we can simplify the code a little now that
      tcp_shifted_skb() should update the lost_cnt_hint in all cases where
      skb == tp->lost_skb_hint.
      Signed-off-by: NNeal Cardwell <ncardwell@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4c90d3b3
  11. 25 2月, 2012 1 次提交