1. 12 3月, 2012 1 次提交
  2. 08 3月, 2012 5 次提交
  3. 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
  4. 06 3月, 2012 1 次提交
  5. 05 3月, 2012 3 次提交
  6. 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
  7. 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
  8. 25 2月, 2012 2 次提交
  9. 24 2月, 2012 3 次提交
  10. 23 2月, 2012 2 次提交
  11. 22 2月, 2012 6 次提交
    • E
      atm: clip: remove clip_tbl · 597cdbc2
      Eric Dumazet 提交于
      Commit 32092ecf (atm: clip: Use device neigh support on top of
      "arp_tbl".) introduced a bug since clip_tbl is zeroed : Crash occurs in
      __neigh_for_each_release()
      
      idle_timer_check() must use instead arp_tbl and neigh_check_cb() should
      ignore non clip neighbours.
      
      Idea from David Miller.
      Reported-by: NMeelis Roos <mroos@linux.ee>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Tested-by: NMeelis Roos <mroos@linux.ee>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      597cdbc2
    • D
      ipv4: ping: Fix recvmsg MSG_OOB error handling. · a5e7424d
      David S. Miller 提交于
      Don't return an uninitialized variable as the error, return
      -EOPNOTSUPP instead.
      Reported-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a5e7424d
    • G
      rtnetlink: Fix problem with buffer allocation · 115c9b81
      Greg Rose 提交于
      Implement a new netlink attribute type IFLA_EXT_MASK.  The mask
      is a 32 bit value that can be used to indicate to the kernel that
      certain extended ifinfo values are requested by the user application.
      At this time the only mask value defined is RTEXT_FILTER_VF to
      indicate that the user wants the ifinfo dump to send information
      about the VFs belonging to the interface.
      
      This patch fixes a bug in which certain applications do not have
      large enough buffers to accommodate the extra information returned
      by the kernel with large numbers of SR-IOV virtual functions.
      Those applications will not send the new netlink attribute with
      the interface info dump request netlink messages so they will
      not get unexpectedly large request buffers returned by the kernel.
      
      Modifies the rtnl_calcit function to traverse the list of net
      devices and compute the minimum buffer size that can hold the
      info dumps of all matching devices based upon the filter passed
      in via the new netlink attribute filter mask.  If no filter
      mask is sent then the buffer allocation defaults to NLMSG_GOODSIZE.
      
      With this change it is possible to add yet to be defined netlink
      attributes to the dump request which should make it fairly extensible
      in the future.
      Signed-off-by: NGreg Rose <gregory.v.rose@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      115c9b81
    • M
      neighbour: Fixed race condition at tbl->nht · 84338a6c
      Michel Machado 提交于
      When the fixed race condition happens:
      
      1. While function neigh_periodic_work scans the neighbor hash table
      pointed by field tbl->nht, it unlocks and locks tbl->lock between
      buckets in order to call cond_resched.
      
      2. Assume that function neigh_periodic_work calls cond_resched, that is,
      the lock tbl->lock is available, and function neigh_hash_grow runs.
      
      3. Once function neigh_hash_grow finishes, and RCU calls
      neigh_hash_free_rcu, the original struct neigh_hash_table that function
      neigh_periodic_work was using doesn't exist anymore.
      
      4. Once back at neigh_periodic_work, whenever the old struct
      neigh_hash_table is accessed, things can go badly.
      Signed-off-by: NMichel Machado <michel@digirati.com.br>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      84338a6c
    • M
      mac80211: Fix a warning on changing to monitor mode from STA · 0dee0068
      Mohammed Shafi Shajakhan 提交于
      nothing needs to be done for monitor/AP_VLAN mode on calling
      ieee80211_bss_info_change_notify -> drv_bss_info_changed with the change
      flag 'BSS_CHANGED_IDLE'. 'wl1271' seems to use BSS_CHANGED_IDLE only for
      STA and IBSS mode. further the non-idle state of the monitor mode is
      taken care by the 'count' variable which counts non-idle interfaces.
      ieee80211_idle_off(local, "in use") will be called.
      this fixes the following WARNING when we have initially STA mode
      (network manager running) and not associated, and change it to monitor
      mode with network manager disabled and bringing up the monitor mode.
      this changes the idle state from 'true' (STA unassociated) to 'false'
      (MONITOR mode)
      exposed by the commit 405385f8
      "mac80211: set bss_conf.idle when vif is connected"
      
      	WARNING: net/mac80211/main.c:212
      	ieee80211_bss_info_change_notify+0x1cf/0x330 [mac80211]()
      	Hardware name: 64756D6
      	Pid: 3835, comm: ifconfig Tainted: G           O
      	3.3.0-rc3-wl #9
      	Call Trace:
      	  [<c0133b02>] warn_slowpath_common+0x72/0xa0
      	  [<fc8e8c3f>] ?
      	  ieee80211_bss_info_change_notify+0x1cf/0x330 [mac80211]
      	  [<fc8e8c3f>] ?
      	  ieee80211_bss_info_change_notify+0x1cf/0x330 [mac80211]
      	  [<c0133b52>] warn_slowpath_null+0x22/0x30
      	  [<fc8e8c3f>]
      	  ieee80211_bss_info_change_notify+0x1cf/0x330 [mac80211]
      	  [<fc8f9de3>] __ieee80211_recalc_idle+0x113/0x430
      	  [mac80211]
      	  [<fc8fabc6>] ieee80211_do_open+0x156/0x7e0 [mac80211]
      	  [<fc8f8a25>] ?
      	  ieee80211_check_concurrent_iface+0x25/0x180 [mac80211]
      	  [<c015dd9f>] ? raw_notifier_call_chain+0x1f/0x30
      	  [<fc8fb290>] ieee80211_open+0x40/0x80 [mac80211]
      	  [<c05894f6>] __dev_open+0x96/0xe0
      	  [<c068fba5>] ? _raw_spin_unlock_bh+0x35/0x40
      	  [<c05881d9>] __dev_change_flags+0x109/0x170
      	  [<c0589423>] dev_change_flags+0x23/0x60
      	  [<c05f3770>] devinet_ioctl+0x6a0/0x770
      
       ieee80211 phy0: device no longer idle - in use
      
      Cc: Eliad Peller <eliad@wizery.com>
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0dee0068
    • M
      mac80211: zero initialize count field in ieee80211_tx_rate · 8617b093
      Mohammed Shafi Shajakhan 提交于
      rate control algorithms concludes the rate as invalid
      with rate[i].idx < -1 , while they do also check for rate[i].count is
      non-zero. it would be safer to zero initialize the 'count' field.
      recently we had a ath9k rate control crash where the ath9k rate control
      in ath_tx_status assumed to check only for rate[i].count being non-zero
      in one instance and ended up in using invalid rate index for
      'connection monitoring NULL func frames' which eventually lead to the crash.
      thanks to Pavel Roskin for fixing it and finding the root cause.
      https://bugzilla.redhat.com/show_bug.cgi?id=768639
      
      Cc: stable@vger.kernel.org
      Cc: Pavel Roskin <proski@gnu.org>
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8617b093
  12. 21 2月, 2012 1 次提交
  13. 20 2月, 2012 1 次提交
  14. 16 2月, 2012 2 次提交
  15. 15 2月, 2012 3 次提交