13 Apr, 2012
2 commits
-
commit d72308bff5c2fa207949a5925b020bce74495e33 upstream.
Is possible that we will arm the tid_rx->reorder_timer after
del_timer_sync() in ___ieee80211_stop_rx_ba_session(). We need to stop
timer after RCU grace period finish, so move it to
ieee80211_free_tid_rx(). Timer will not be armed again, as
rcu_dereference(sta->ampdu_mlme.tid_rx[tid]) will return NULL.Debug object detected problem with the following warning:
ODEBUG: free active (active state 0) object type: timer_list hint: sta_rx_agg_reorder_timer_expired+0x0/0xf0 [mac80211]Bug report (with all warning messages):
https://bugzilla.redhat.com/show_bug.cgi?id=804007Reported-by: "jan p. springer"
Signed-off-by: Stanislaw Gruszka
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 81213b5e8ae68e204aa7a3f83c4f9100405dbff9 ]
If both addresses equal, nothing needs to be done. If the device is down,
then we simply copy the new address to dev->dev_addr. If the device is up,
then we add another loopback device with the new address, and if that does
not fail, we remove the loopback device with the old address. And only
then, we update the dev->dev_addr.Signed-off-by: Daniel Borkmann
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
03 Apr, 2012
9 commits
-
commit 6d8d17499810479eabd10731179c04b2ca22152f upstream.
There is no point in passing a zero length string here and quite a
few of that cache_parse() implementations will Oops if count is
zero.Signed-off-by: Dan Carpenter
Signed-off-by: J. Bruce Fields
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 1265fd616782ef03b98fd19f65c2b47fcd4ea11f ]
We call the wrong replay notify function when we use ESN replay
handling. This leads to the fact that we don't send notifications
if we use ESN. Fix this by calling the registered callbacks instead
of xfrm_replay_notify().Signed-off-by: Steffen Klassert
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit a6506e1486181975d318344143aca722b2b91621 ]
no socket layer outputs a message for this error and neither should rds.
Signed-off-by: Dave Jones
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 2a2a459eeeff48640dc557548ce576d666ab06ed ]
napi->skb is allocated in napi_get_frags() using
netdev_alloc_skb_ip_align(), with a reserve of NET_SKB_PAD +
NET_IP_ALIGN bytes.However, when such skb is recycled in napi_reuse_skb(), it ends with a
reserve of NET_IP_ALIGN which is suboptimal.Signed-off-by: Eric Dumazet
Cc: Herbert Xu
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 94f826b8076e2cb92242061e92f21b5baa3eccc2 ]
Commit f2c31e32b378 (net: fix NULL dereferences in check_peer_redir() )
added a regression in rt6_fill_node(), leading to rcu_read_lock()
imbalance.Thats because NLA_PUT() can make a jump to nla_put_failure label.
Fix this by using nla_put()
Many thanks to Ben Greear for his help
Reported-by: Ben Greear
Reported-by: Dave Jones
Signed-off-by: Eric Dumazet
Tested-by: Ben Greear
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 1f85851e17b64cabd089a8a8839dddebc627948c ]
Since commit 299b0767(ipv6: Fix IPsec slowpath fragmentation problem)
In func ip6_append_data,after call skb_put(skb, fraglen + dst_exthdrlen)
the skb->len contains dst_exthdrlen,and we don't reduce dst_exthdrlen at last
This will make fraggap>0 in next "while cycle",and cause the size of skb incorrentFix this by reserve headroom for dst_exthdrlen.
Signed-off-by: Gao feng
Acked-by: Steffen Klassert
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit bbdb32cb5b73597386913d052165423b9d736145 ]
While testing L2TP functionality, I came across a bug in getsockname(). The
IP address returned within the pppol2tp_addr's addr memember was not being
set to the IP address in use. This bug is caused by using inet_sk() on the
wrong socket (the L2TP socket rather than the underlying UDP socket), and was
likely introduced during the addition of L2TPv3 support.Signed-off-by: Benjamin LaHaise
Signed-off-by: James Chapman
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 540a0f7584169651f485e8ab67461fcb06934e38 upstream.
The problem is that for the case of priority queues, we
have to assume that __rpc_remove_wait_queue_priority will move new
elements from the tk_wait.links lists into the queue->tasks[] list.
We therefore cannot use list_for_each_entry_safe() on queue->tasks[],
since that will skip these new tasks that __rpc_remove_wait_queue_priority
is adding.Without this fix, rpc_wake_up and rpc_wake_up_status will both fail
to wake up all functions on priority wait queues, which can result
in some nasty hangs.Reported-by: Andy Adamson
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 48752f6513012a1b078da08b145d5c40a644f058 upstream.
Add VF spoof check to IFLA policy. The original patch I submitted to
add the spoof checking feature to rtnl failed to add the proper policy
rule that identifies the data type and len. This patch corrects that
oversight. No bugs have been reported against this but it may cause
some problem for the netlink message parsing that uses the policy
table.Signed-off-by: Greg Rose
Tested-by: Sibai Li
Signed-off-by: Jeff Kirsher
Signed-off-by: Greg Kroah-Hartman
24 Mar, 2012
2 commits
-
[ Upstream commit c577923756b7fe9071f28a76b66b83b306d1d001 ]
ip6_mc_find_dev_rcu() is called with rcu_read_lock(), so don't
need to dev_hold().
With dev_hold(), not corresponding dev_put(), will lead to leak.[ bug introduced in 96b52e61be1 (ipv6: mcast: RCU conversions) ]
Signed-off-by: RongQing.Li
Acked-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit dfd25ffffc132c00070eed64200e8950da5d7e9d ]
commit ea4fc0d619 (ipv4: Don't use rt->rt_{src,dst} in ip_queue_xmit())
added a serious regression on synflood handling.Simon Kirby discovered a successful connection was delayed by 20 seconds
before being responsive.In my tests, I discovered that xmit frames were lost, and needed ~4
retransmits and a socket dst rebuild before being really sent.In case of syncookie initiated connection, we use a different path to
initialize the socket dst, and inet->cork.fl.u.ip4 is left cleared.As ip_queue_xmit() now depends on inet flow being setup, fix this by
copying the temp flowi4 we use in cookie_v4_check().Reported-by: Simon Kirby
Bisected-by: Simon Kirby
Signed-off-by: Eric Dumazet
Tested-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
20 Mar, 2012
7 commits
-
[ Upstream commit d6ddef9e641d1229d4ec841dc75ae703171c3e92 ]
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: Li Wei
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 4648dc97af9d496218a05353b0e442b3dfa6aaab ]
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 (832d11c5cd076abc0aa1eaf7be96c81d1a59ce41)
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 cc9a672ee522d4805495b98680f4a3db5d0a0af9
and daef52bab1fd26e24e8e9578f8fb33ba1d0cb412, 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: Neal Cardwell
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit d1d81d4c3dd886d5fa25a2c4fa1e39cb89613712 ]
otherwise source IPv6 address of ICMPV6_MGM_QUERY packet
might be random junk if IPv6 is disabled on interface or
link-local address is not yet ready (DAD).Signed-off-by: Ulrich Weber
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit c0638c247f559e1a16ee79e54df14bca2cb679ea ]
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: Neal Cardwell
Acked-by: Ilpo Järvinen
Acked-by: Yuchung Cheng
Acked-by: Nandita Dukkipati
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 4c90d3b30334833450ccbb02f452d4972a3c3c3f ]
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: Neal Cardwell
Acked-by: Yuchung Cheng
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 03606895cd98c0a628b17324fd7b5ff15db7e3cd ]
Niccolo Belli reported ipsec crashes in case we handle a frame without
mac header (atm in his case)Before copying mac header, better make sure it is present.
Bugzilla reference: https://bugzilla.kernel.org/show_bug.cgi?id=42809
Reported-by: Niccolò Belli
Tested-by: Niccolò Belli
Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 84338a6c9dbb6ff3de4749864020f8f25d86fc81 ]
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: Michel Machado
CC: "David S. Miller"
CC: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
13 Mar, 2012
1 commit
-
commit 8617b093d0031837a7be9b32bc674580cfb5f6b5 upstream.
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=768639Cc: Pavel Roskin
Signed-off-by: Mohammed Shafi Shajakhan
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman
01 Mar, 2012
12 commits
-
commit e0aac52e17a3db68fe2ceae281780a70fc69957f upstream.
Commit f11017ec2d1859c661f4e2b12c4a8d250e1f47cf (2.6.37)
moved the fwmark variable in subcontext that is invalidated before
reaching the ip_vs_ct_in_get call. As vaddr is provided as pointer
in the param structure make sure the fwmark variable is in
same context. As the fwmark templates can not be matched,
more and more template connections are created and the
controlled connections can not go to single real server.Signed-off-by: Julian Anastasov
Signed-off-by: Simon Horman
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 0af2a0d0576205dda778d25c6c344fc6508fc81d ]
This commit ensures that lost_cnt_hint is correctly updated in
tcp_shifted_skb() for FACK TCP senders. The lost_cnt_hint adjustment
in tcp_sacktag_one() only applies to non-FACK senders, so FACK senders
need their own adjustment.This applies the spirit of 1e5289e121372a3494402b1b131b41bfe1cf9b7f -
except now that the sequence range passed into tcp_sacktag_one() is
correct we need only have a special case adjustment for FACK.Signed-off-by: Neal Cardwell
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit daef52bab1fd26e24e8e9578f8fb33ba1d0cb412 ]
Fix the newly-SACKed range to be the range of newly-shifted bytes.
Previously - since 832d11c5cd076abc0aa1eaf7be96c81d1a59ce41 -
tcp_shifted_skb() incorrectly called tcp_sacktag_one() with the start
and end sequence numbers of the skb it passes in set to the range just
beyond the range that is newly-SACKed.This commit also removes a special-case adjustment to lost_cnt_hint in
tcp_shifted_skb() since the pre-existing adjustment of lost_cnt_hint
in tcp_sacktag_one() now properly handles this things now that the
correct start sequence number is passed in.Signed-off-by: Neal Cardwell
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit cc9a672ee522d4805495b98680f4a3db5d0a0af9 ]
This commit allows callers of tcp_sacktag_one() to pass in sequence
ranges that do not align with skb boundaries, as tcp_shifted_skb()
needs to do in an upcoming fix in this patch series.In fact, now tcp_sacktag_one() does not need to depend on an input skb
at all, which makes its semantics and dependencies more clear.Signed-off-by: Neal Cardwell
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 5ca3b72c5da47d95b83857b768def6172fbc080a ]
Shlomo Pongratz reported GRO L2 header check was suited for Ethernet
only, and failed on IB/ipoib traffic.He provided a patch faking a zeroed header to let GRO aggregates frames.
Roland Dreier, Herbert Xu, and others suggested we change GRO L2 header
check to be more generic, ie not assuming L2 header is 14 bytes, but
taking into account hard_header_len.__napi_gro_receive() has special handling for the common case (Ethernet)
to avoid a memcmp() call and use an inline optimized function instead.Signed-off-by: Eric Dumazet
Reported-by: Shlomo Pongratz
Cc: Roland Dreier
Cc: Or Gerlitz
Cc: Herbert Xu
Tested-by: Sean Hefty
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 16bda13d90c8d5da243e2cfa1677e62ecce26860 ]
Just like skb->cb[], so that qdisc_skb_cb can be encapsulated inside
of other data structures.This is intended to be used by IPoIB so that it can remember
addressing information stored at hard_header_ops->create() time that
it can fetch when the packet gets to the transmit routine.Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 5dc7883f2a7c25f8df40d7479687153558cd531b ]
This patch fix a bug which introduced by commit ac8a4810 (ipv4: Save
nexthop address of LSRR/SSRR option to IPCB.).In that patch, we saved
the nexthop of SRR in ip_option->nexthop and update iph->daddr until
we get to ip_forward_options(), but we need to update it before
ip_rt_get_source(), otherwise we may get a wrong src.Signed-off-by: Li Wei
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit e2446eaab5585555a38ea0df4e01ff313dbb4ac9 ]
Binding RST packet outgoing interface to incoming interface
for tcp v4 when there is no socket associate with it.
when sk is not NULL, using sk->sk_bound_dev_if instead.
(suggested by Eric Dumazet).This has few benefits:
1. tcp_v6_send_reset already did that.
2. This helps tcp connect with SO_BINDTODEVICE set. When
connection is lost, we still able to sending out RST using
same interface.
3. we are sending reply, it is most likely to be succeed
if iif is usedSigned-off-by: Shawn Lu
Acked-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit eb10192447370f19a215a8c2749332afa1199d46 ]
Not now, but it looks you are correct. q->qdisc is NULL until another
additional qdisc is attached (beside tfifo). See 50612537e9ab2969312.
The following patch should work.From: Hagen Paul Pfeifer
netem: catch NULL pointer by updating the real qdisc statistic
Reported-by: Vijay Subramanian
Signed-off-by: Hagen Paul Pfeifer
Acked-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 58e05f357a039a94aa36475f8c110256f693a239 ]
commit 5a698af53f (bond: service netpoll arp queue on master device)
tested IFF_SLAVE flag against dev->priv_flags instead of dev->flagsSigned-off-by: Eric Dumazet
Cc: WANG Cong
Acked-by: Neil Horman
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 70620c46ac2b45c24b0f22002fdf5ddd1f7daf81 ]
Commit 653241 (net: RFC3069, private VLAN proxy arp support) changed
the behavior of arp proxy to send arp replies back out on the interface
the request came in even if the private VLAN feature is disabled.Previously we checked rt->dst.dev != skb->dev for in scenarios, when
proxy arp is enabled on for the netdevice and also when individual proxy
neighbour entries have been added.This patch adds the check back for the pneigh_lookup() scenario.
Signed-off-by: Thomas Graf
Acked-by: Jesper Dangaard Brouer
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit b57e6b560fc2a2742910ac5ca0eb2c46e45aeac2 upstream.
read_lock(&tpt_trig->trig.leddev_list_lock) is accessed via the path
ieee80211_open (->) ieee80211_do_open (->) ieee80211_mod_tpt_led_trig
(->) ieee80211_start_tpt_led_trig (->) tpt_trig_timer before initializing
it.
the intilization of this read/write lock happens via the path
ieee80211_led_init (->) led_trigger_register, but we are doing
'ieee80211_led_init' after 'ieeee80211_if_add' where we
register netdev_ops.
so we access leddev_list_lock before initializing it and causes the
following bug in chrome laptops with AR928X cards with the following
scriptwhile true
do
sudo modprobe -v ath9k
sleep 3
sudo modprobe -r ath9k
sleep 3
doneBUG: rwlock bad magic on CPU#1, wpa_supplicant/358, f5b9eccc
Pid: 358, comm: wpa_supplicant Not tainted 3.0.13 #1
Call Trace:[] rwlock_bug+0x3d/0x47
[] do_raw_read_lock+0x19/0x29
[] _raw_read_lock+0xd/0xf
[] tpt_trig_timer+0xc3/0x145 [mac80211]
[] ieee80211_mod_tpt_led_trig+0x152/0x174 [mac80211]
[] ieee80211_do_open+0x11e/0x42e [mac80211]
[] ? ieee80211_check_concurrent_iface+0x26/0x13c [mac80211]
[] ieee80211_open+0x48/0x4c [mac80211]
[] __dev_open+0x82/0xab
[] __dev_change_flags+0x9c/0x113
[] dev_change_flags+0x18/0x44
[] devinet_ioctl+0x243/0x51a
[] inet_ioctl+0x93/0xac
[] sock_ioctl+0x1c6/0x1ea
[] ? might_fault+0x20/0x20
[] do_vfs_ioctl+0x46e/0x4a2
[] ? fget_light+0x2f/0x70
[] ? sys_recvmsg+0x3e/0x48
[] sys_ioctl+0x46/0x69
[] sysenter_do_call+0x12/0x2Cc: Gary Morain
Cc: Paul Stewart
Cc: Abhijit Pradhan
Cc: Vasanthakumar Thiagarajan
Cc: Rajkumar Manoharan
Acked-by: Johannes Berg
Tested-by: Mohammed Shafi Shajakhan
Signed-off-by: Mohammed Shafi Shajakhan
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman
21 Feb, 2012
1 commit
-
commit 07ae2dfcf4f7143ce191c6436da1c33f179af0d6 upstream.
The current code checks for stored_mpdu_num > 1, causing
the reorder_timer to be triggered indefinitely, but the
frame is never timed-out (until the next packet is received)Signed-off-by: Eliad Peller
Acked-by: Johannes Berg
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman
04 Feb, 2012
6 commits
-
[ Upstream commit 8a622e71f58ec9f092fc99eacae0e6cf14f6e742 ]
md5 key is added in socket through remote address.
remote address should be used in finding md5 key when
sending out reset packet.Signed-off-by: shawnlu
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 5b35e1e6e9ca651e6b291c96d1106043c9af314a ]
This commit fixes tcp_trim_head() to recalculate the number of
segments in the skb with the skb's existing MSS, so trimming the head
causes the skb segment count to be monotonically non-increasing - it
should stay the same or go down, but not increase.Previously tcp_trim_head() used the current MSS of the connection. But
if there was a decrease in MSS between original transmission and ACK
(e.g. due to PMTUD), this could cause tcp_trim_head() to
counter-intuitively increase the segment count when trimming bytes off
the head of an skb. This violated assumptions in tcp_tso_acked() that
tcp_trim_head() only decreases the packet count, so that packets_acked
in tcp_tso_acked() could underflow, leading tcp_clean_rtx_queue() to
pass u32 pkts_acked values as large as 0xffffffff to
ca_ops->pkts_acked().As an aside, if tcp_trim_head() had really wanted the skb to reflect
the current MSS, it should have called tcp_set_skb_tso_segs()
unconditionally, since a decrease in MSS would mean that a
single-packet skb should now be sliced into multiple segments.Signed-off-by: Neal Cardwell
Acked-by: Nandita Dukkipati
Acked-by: Ilpo Järvinen
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit efc3dbc37412c027e363736b4f4c74ee5e8ecffc ]
rds_sock_info() triggers locking warnings because we try to perform a
local_bh_enable() (via sock_i_ino()) while hardware interrupts are
disabled (via taking rds_sock_lock).There is no reason for rds_sock_lock to be a hardware IRQ disabling
lock, none of these access paths run in hardware interrupt context.Therefore making it a BH disabling lock is safe and sufficient to
fix this bug.Reported-by: Kumar Sanghvi
Reported-by: Josh Boyer
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit cf778b00e96df6d64f8e21b8395d1f8a859ecdc7 ]
commit a9b3cd7f32 (rcu: convert uses of rcu_assign_pointer(x, NULL) to
RCU_INIT_POINTER) did a lot of incorrect changes, since it did a
complete conversion of rcu_assign_pointer(x, y) to RCU_INIT_POINTER(x,
y).We miss needed barriers, even on x86, when y is not NULL.
Signed-off-by: Eric Dumazet
CC: Stephen Hemminger
CC: Paul E. McKenney
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 68315801dbf3ab2001679fd2074c9dc5dcf87dfa ]
When a packet is received on an L2TP IP socket (L2TPv3 IP link
encapsulation), the l2tpip socket's backlog_rcv function calls
xfrm4_policy_check(). This is not necessary, since it was called
before the skb was added to the backlog. With CONFIG_NET_NS enabled,
xfrm4_policy_check() will oops if skb->dev is null, so this trivial
patch removes the call.This bug has always been present, but only when CONFIG_NET_NS is
enabled does it cause problems. Most users are probably using UDP
encapsulation for L2TP, hence the problem has only recently
surfaced.EIP: 0060:[] EFLAGS: 00210246 CPU: 0
EIP is at l2tp_ip_recvmsg+0xd4/0x2a7
EAX: 00000001 EBX: d77b5180 ECX: 00000000 EDX: 00200246
ESI: 00000000 EDI: d63cbd30 EBP: d63cbd18 ESP: d63cbcf4
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Call Trace:
[] sock_common_recvmsg+0x31/0x46
[] __sock_recvmsg_nosec+0x45/0x4d
[] __sock_recvmsg+0x31/0x3b
[] sock_recvmsg+0x96/0xab
[] ? might_fault+0x47/0x81
[] ? might_fault+0x47/0x81
[] ? _copy_from_user+0x31/0x115
[] ? copy_from_user+0x8/0xa
[] ? verify_iovec+0x3e/0x78
[] __sys_recvmsg+0x10a/0x1aa
[] ? sock_recvmsg+0x0/0xab
[] ? __lock_acquire+0xbdf/0xbee
[] ? do_page_fault+0x193/0x375
[] ? fcheck_files+0x9b/0xca
[] ? fget_light+0x2a/0x9c
[] sys_recvmsg+0x2b/0x43
[] sys_socketcall+0x16d/0x1a5
[] ? trace_hardirqs_on_thunk+0xc/0x10
[] sysenter_do_call+0x12/0x38
Code: c6 05 8c ea a8 c1 01 e8 0c d4 d9 ff 85 f6 74 07 3e ff 86 80 00 00 00 b9 17 b6 2b c1 ba 01 00 00 00 b8 78 ed 48 c1 e8 23 f6 d9 ff 76 0c 68 28 e3 30 c1 68 2d 44 41 c1 e8 89 57 01 00 83 c4 0cSigned-off-by: James Chapman
Acked-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 6f01fd6e6f6809061b56e78f1e8d143099716d70 ]
Commit 0884d7aa24 (AF_UNIX: Fix poll blocking problem when reading from
a stream socket) added a regression for epoll() in Edge Triggered mode
(EPOLLET)Appropriate fix is to use skb_peek()/skb_unlink() instead of
skb_dequeue(), and only call skb_unlink() when skb is fully consumed.This remove the need to requeue a partial skb into sk_receive_queue head
and the extra sk->sk_data_ready() calls that added the regression.This is safe because once skb is given to sk_receive_queue, it is not
modified by a writer, and readers are serialized by u->readlock mutex.This also reduce number of spinlock acquisition for small reads or
MSG_PEEK users so should improve overall performance.Reported-by: Nick Mathewson
Signed-off-by: Eric Dumazet
Cc: Alexey Moiseytsev
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
