Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 05 3月, 2012 3 次提交
  3. 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
  5. 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
  7. 25 2月, 2012 2 次提交
  9. 24 2月, 2012 3 次提交
  11. 23 2月, 2012 2 次提交
  13. 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
  15. 21 2月, 2012 1 次提交
  17. 20 2月, 2012 1 次提交
  19. 16 2月, 2012 2 次提交
  21. 15 2月, 2012 12 次提交
  23. 14 2月, 2012 1 次提交
  25. 13 2月, 2012 2 次提交
  27. 11 2月, 2012 3 次提交