24 Mar, 2012
10 commits
-
commit 78c5c68a4cf4329d17abfa469345ddf323d4fd62 upstream.
The code for "powersurge" SMP would kick in and cause a crash
at boot due to the lack of a NULL test.Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Jeremy Kerr
Reported-by: Adam Conrad
Tested-by: Adam Conrad
Signed-off-by: Greg Kroah-Hartman -
commit 210787e82a0ac1ffb5d7be1c796f0c51050849ad upstream.
On il3945_down procedure we free tx queue data and nullify il->txq
pointer. After that we drop mutex and then cancel delayed works. There
is possibility, that after drooping mutex and before the cancel, some
delayed work will start and crash while trying to send commands to
the device. For example, here is reported crash in
il3945_bg_reg_txpower_periodic():
https://bugzilla.kernel.org/show_bug.cgi?id=42766#c10Patch fix problem by adding il->txq check on works that send commands,
hence utilize tx queue.Reported-by: Clemens Eisserer
Signed-off-by: Stanislaw Gruszka
Signed-off-by: John W. Linville -
[ 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 -
commit e7f01d1e3d8d501deb8abeaa269d5d48a703b8b0 upstream.
Several places were expecting that the value returned was the number of
characters printed, not what would be printed if there was space.Fix it by using the scnprintf and vscnprintf variants we inherited from
the kernel sources.Some corner cases where the number of printed characters were not
accounted were fixed too.Reported-by: Anton Blanchard
Cc: Anton Blanchard
Cc: Eric B Munson
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Mike Galbraith
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Yanmin Zhang
Link: http://lkml.kernel.org/n/tip-kwxo2eh29cxmd8ilixi2005x@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Greg Kroah-Hartman -
commit b832796caa1fda8516464a003c8c7cc547bc20c2 upstream.
I have a workload where perf top scribbles over the stack and we SEGV.
What makes it interesting is that an snprintf is causing this.The workload is a c++ gem that has method names over 3000 characters
long, but snprintf is designed to avoid overrunning buffers. So what
went wrong?The problem is we assume snprintf returns the number of characters
written:ret += repsep_snprintf(bf + ret, size - ret, "[%c] ", self->level);
...
ret += repsep_snprintf(bf + ret, size - ret, "%s", self->ms.sym->name);Unfortunately this is not how snprintf works. snprintf returns the
number of characters that would have been written if there was enough
space. In the above case, if the first snprintf returns a value larger
than size, we pass a negative size into the second snprintf and happily
scribble over the stack. If you have 3000 character c++ methods thats a
lot of stack to trample.This patch fixes repsep_snprintf by clamping the value at size - 1 which
is the maximum snprintf can write before adding the NULL terminator.I get the sinking feeling that there are a lot of other uses of snprintf
that have this same bug, we should audit them all.Cc: David Ahern
Cc: Eric B Munson
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Yanmin Zhang
Link: http://lkml.kernel.org/r/20120307114249.44275ca3@kryten
Signed-off-by: Anton Blanchard
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Greg Kroah-Hartman -
commit c0173863528a8c9212c53e080d63a1aaae5ef4f4 upstream.
When writing files to afs I sometimes hit a BUG:
kernel BUG at fs/afs/rxrpc.c:179!
With a backtrace of:
afs_free_call
afs_make_call
afs_fs_store_data
afs_vnode_store_data
afs_write_back_from_locked_page
afs_writepages_region
afs_writepagesThe cause is:
ASSERT(skb_queue_empty(&call->rx_queue));
Looking at a tcpdump of the session the abort happens because we
are exceeding our disk quota:rx abort fs reply store-data error diskquota exceeded (32)
So the abort error is valid. We hit the BUG because we haven't
freed all the resources for the call.By freeing any skbs in call->rx_queue before calling afs_free_call
we avoid hitting leaking memory and avoid hitting the BUG.Signed-off-by: Anton Blanchard
Signed-off-by: David Howells
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 2c724fb92732c0b2a5629eb8af74e82eb62ac947 upstream.
A read of a large file on an afs mount failed:
# cat junk.file > /dev/null
cat: junk.file: Bad messageLooking at the trace, call->offset wrapped since it is only an
unsigned short. In afs_extract_data:_enter("{%u},{%zu},%d,,%zu", call->offset, len, last, count);
...if (call->offset < count) {
if (last) {
_leave(" = -EBADMSG [%d < %zu]", call->offset, count);
return -EBADMSG;
}Which matches the trace:
[cat ] ==> afs_extract_data({65132},{524},1,,65536)
[cat ] < 65536]call->offset went from 65132 to 0. Fix this by making call->offset an
unsigned int.Signed-off-by: Anton Blanchard
Signed-off-by: David Howells
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit d7178c79d9b7c5518f9943188091a75fc6ce0675 upstream.
According to the report from Slicky Devil, nilfs caused kernel oops at
nilfs_load_super_block function during mount after he shrank the
partition without resizing the filesystem:BUG: unable to handle kernel NULL pointer dereference at 00000048
IP: [] nilfs_load_super_block+0x17e/0x280 [nilfs2]
*pde = 00000000
Oops: 0000 [#1] PREEMPT SMP
...
Call Trace:
[] init_nilfs+0x4b/0x2e0 [nilfs2]
[] nilfs_mount+0x447/0x5b0 [nilfs2]
[] mount_fs+0x36/0x180
[] vfs_kern_mount+0x51/0xa0
[] do_kern_mount+0x3e/0xe0
[] do_mount+0x169/0x700
[] sys_mount+0x6b/0xa0
[] sysenter_do_call+0x12/0x28
Code: 53 18 8b 43 20 89 4b 18 8b 4b 24 89 53 1c 89 43 24 89 4b 20 8b 43
20 c7 43 2c 00 00 00 00 23 75 e8 8b 50 68 89 53 28 8b 54 b3 20 72
48 8b 7a 4c 8b 55 08 89 b3 84 00 00 00 89 bb 88 00 00 00
EIP: [] nilfs_load_super_block+0x17e/0x280 [nilfs2] SS:ESP 0068:ca9bbdcc
CR2: 0000000000000048This turned out due to a defect in an error path which runs if the
calculated location of the secondary super block was invalid.This patch fixes it and eliminates the reported oops.
Reported-by: Slicky Devil
Signed-off-by: Ryusuke Konishi
Tested-by: Slicky Devil
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
20 Mar, 2012
30 commits
-
commit fecfb64422d91a9621a3f96ab75c3a5f13e80b58 upstream.
Intersil reports that all chips supported by the zl6100 driver require
an interval between chip accesses, even ZL2004 and ZL6105 which were thought
to be safe.Reported-by: Vivek Gani
Signed-off-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
commit 087a03b3ea1c8d6e2d5743a8d1c6d571058caa04 upstream.
This patch addresses a bug with target_check_scsi2_reservation_conflict()
return checking in target_scsi2_reservation_[reserve,release]() that was
preventing CRH=1 operation from silently succeeding in the two special
cases defined by SPC-3, and not failing with reservation conflict status
when dealing with legacy RESERVE/RELEASE + active SPC-3 PR logic.Also explictly set cmd->scsi_status = SAM_STAT_RESERVATION_CONFLICT during
the early non reservation holder failure from pr_ops->t10_seq_non_holder()
check in transport_generic_cmd_sequencer() for fabrics that already expect
it to be set.This bug was originally introduced in mainline commit:
commit eacac00ce5bfde8086cd0615fb53c986f7f970fe
Author: Christoph Hellwig
Date: Thu Nov 3 17:50:40 2011 -0400target: split core_scsi2_emulate_crh
Reported-by: Martin Svec
Cc: Martin Svec
Cc: Christoph Hellwig
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit 00fdc6bbef77844ce397a7de7acfaf25e8e2e4eb upstream.
This patch addresses a iscsi-target specific bug related to reservation conflict
handling in iscsit_handle_scsi_cmd() that has been causing reservation conflicts
to complete and not fail as expected due to incorrect errno checking. The problem
occured with the change to return -EBUSY from transport_generic_cmd_sequencer() ->
transport_generic_allocate_tasks() failures, that broke iscsit_handle_scsi_cmd()
checking for -EINVAL in order to invoke a non GOOD status response.This was manifesting itself as data corruption with legacy SPC-2 reservations,
but also effects iscsi-target LUNs with SPC-3 persistent reservations.This bug was originally introduced in lio-core commit:
commit 03e98c9eb916f3f0868c1dc344dde2a60287ff72
Author: Nicholas Bellinger
Date: Fri Nov 4 02:36:16 2011 -0700target: Address legacy PYX_TRANSPORT_* return code breakage
Reported-by: Martin Svec
Cc: Martin Svec
Cc: Christoph Hellwig
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit 8ee161ce5e0cfc689eb677f227a6248191165fac upstream.
When the system is under heavy load, there can be a significant delay
between the getscl() and time_after() calls inside sclhi(). That delay
may cause the time_after() check to trigger after SCL has gone high,
causing sclhi() to return -ETIMEDOUT.To fix the problem, double check that SCL is still low after the
timeout has been reached, before deciding to return -ETIMEDOUT.Signed-off-by: Ville Syrjala
Signed-off-by: Jean Delvare
Signed-off-by: Greg Kroah-Hartman -
commit 9bbad7da76b3dd578fb55c862624366a8c9ccd22 upstream.
Fix indexed register offset definitions that use decimal (wrong) instead
of hexadecimal (correct) notation for indexing multipliers.Incorrect definitions do not affect Tsi721 driver in its current default
configuration because it uses only IDB queue 0. Loss of inbound
doorbell functionality should be observed if queue other than 0 is used.Signed-off-by: Alexandre Bounine
Cc: Matt Porter
Cc: Chul Kim
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit aacb6b0052692c72fe0cb94c6b547202def6ef46 upstream.
Properly set the source of temp2 for the W83627UHG. Also fix a
comment right before that, and document the W83627UHG as reporting up
to 3 temperatures.Signed-off-by: Jean Delvare
Cc: Guenter Roeck
Signed-off-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
commit 32260d94408c553dca4ce54104edf79941a27536 upstream.
The driver probe function leaked memory if creating the cpu0_vid attribute file
failed. Fix by converting the driver to use devm_kzalloc.Signed-off-by: Guenter Roeck
Acked-by: Jean Delvare
Signed-off-by: Greg Kroah-Hartman -
commit 33fa9b620409edfc71aa6cf01a51f990fbe46ab8 upstream.
NCT6775F and NCT6776F have their own set of registers for FAN_STOP_TIME. The
correct registers were used to read FAN_STOP_TIME, but writes used the wrong
registers. Fix it.Signed-off-by: Guenter Roeck
Acked-by: Jean Delvare
Signed-off-by: Greg Kroah-Hartman -
commit e0adb9902fb338a9fe634c3c2a3e474075c733ba upstream.
Newer version of binutils are more strict about specifying the
correct options to enable certain classes of instructions.The sparc32 build is done for v7 in order to support sun4c systems
which lack hardware integer multiply and divide instructions.So we have to pass -Av8 when building the assembler routines that
use these instructions and get patched into the kernel when we find
out that we have a v8 capable cpu.Reported-by: Paul Gortmaker
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 62d3c5439c534b0e6c653fc63e6d8c67be3a57b1 upstream.
This patch (as1519) fixes a bug in the block layer's disk-events
polling. The polling is done by a work routine queued on the
system_nrt_wq workqueue. Since that workqueue isn't freezable, the
polling continues even in the middle of a system sleep transition.Obviously, polling a suspended drive for media changes and such isn't
a good thing to do; in the case of USB mass-storage devices it can
lead to real problems requiring device resets and even re-enumeration.The patch fixes things by creating a new system-wide, non-reentrant,
freezable workqueue and using it for disk-events polling.Signed-off-by: Alan Stern
Acked-by: Tejun Heo
Acked-by: Rafael J. Wysocki
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit 9f53d2fe815b4011ff930a7b6db98385d45faa68 upstream.
The following situation might occur:
__blkdev_get: add_disk:
register_disk()
get_gendisk()disk_block_events()
disk->ev == NULLdisk_add_events()
__disk_unblock_events()
disk->ev != NULL
--ev->blockThen we unblock events, when they are suppose to be blocked. This can
trigger events related block/genhd.c warnings, but also can crash in
sd_check_events() or other places.I'm able to reproduce crashes with the following scripts (with
connected usb dongle as sdb disk).DEV=/dev/sdb
ENABLE=/sys/bus/usb/devices/1-2/bConfigurationValuefunction stop_me()
{
for i in `jobs -p` ; do kill $i 2> /dev/null ; done
exit
}trap stop_me SIGHUP SIGINT SIGTERM
for ((i = 0; i < 10; i++)) ; do
while true; do fdisk -l $DEV 2>&1 > /dev/null ; done &
donewhile true ; do
echo 1 > $ENABLE
sleep 1
echo 0 > $ENABLE
doneI use the script to verify patch fixing oops in sd_revalidate_disk
http://marc.info/?l=linux-scsi&m=132935572512352&w=2
Without Jun'ichi Nomura patch titled "Fix NULL pointer dereference in
sd_revalidate_disk" or this one, script easily crash kernel within
a few seconds. With both patches applied I do not observe crash.
Unfortunately after some time (dozen of minutes), script will hung in:[ 1563.906432] [] schedule_timeout_uninterruptible+0x15/0x20
[ 1563.906437] [] msleep+0x15/0x20
[ 1563.906443] [] blk_drain_queue+0x32/0xd0
[ 1563.906447] [] blk_cleanup_queue+0xd0/0x170
[ 1563.906454] [] scsi_free_queue+0x3f/0x60
[ 1563.906459] [] __scsi_remove_device+0x6e/0xb0
[ 1563.906463] [] scsi_forget_host+0x4f/0x60
[ 1563.906468] [] scsi_remove_host+0x5a/0xf0
[ 1563.906482] [] quiesce_and_remove_host+0x5b/0xa0 [usb_storage]
[ 1563.906490] [] usb_stor_disconnect+0x13/0x20 [usb_storage]Anyway I think this patch is some step forward.
As drawback, I do not teardown on sysfs file create error, because I do
not know how to nullify disk->ev (since it can be used). However add_disk
error handling practically does not exist too, and things will work
without this sysfs file, except events will not be exported to user
space.Signed-off-by: Stanislaw Gruszka
Acked-by: Tejun Heo
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit ea5f4db8ece896c2ab9eafa0924148a2596c52e4 upstream.
"mem" is type u8. We need parenthesis here or it screws up the pointer
math probably leading to an oops.Signed-off-by: Dan Carpenter
Acked-by: Jeff Garzik
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit fe316bf2d5847bc5dd975668671a7b1067603bc7 upstream.
Since 2.6.39 (1196f8b), when a driver returns -ENOMEDIUM for open(),
__blkdev_get() calls rescan_partitions() to remove
in-kernel partition structures and raise KOBJ_CHANGE uevent.However it ends up calling driver's revalidate_disk without open
and could cause oops.In the case of SCSI:
process A process B
----------------------------------------------
sys_open
__blkdev_get
sd_open
returns -ENOMEDIUM
scsi_remove_device
rescan_partitions
sd_revalidate_disk
Oopses are reported here:
http://marc.info/?l=linux-scsi&m=132388619710052This patch separates the partition invalidation from rescan_partitions()
and use it for -ENOMEDIUM case.Reported-by: Huajun Li
Signed-off-by: Jun'ichi Nomura
Acked-by: Tejun Heo
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit f03570cf1709397ebe656608266b44ec772960c2 upstream.
Don't assign the voltage to selector.
Signed-off-by: Axel Lin
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 4e50391968849860dff1aacde358b4eb14aa5127 upstream.
This patch adds support for the Sitecom LN-031 USB adapter with a AX88178 chip.
Added USB id to find correct driver for AX88178 1000 Ethernet adapter.
Signed-off-by: Joerg Neikes
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ 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 9c5028e9da1255dd2b99762d8627b88b29f68cce ]
Noticed with the 8168d (-vb-gr, aka RTL_GIGA_MAC_VER_26).
ConfigX registers should only be written while the Config9346 lock
is held.Signed-off-by: Francois Romieu
Reported-by: Nick Bowler
Cc: Hayes Wang
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 3f2010b2ad3d66d5291497c9b274315e7b807ecd ]
As part of the big network driver reorg, each vendor directory defaults to
yes, so that older config's can migrate correctly. Looks like this one
got missed.Signed-off-by: Stephen Hemminger
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit efead8710aad9e384730ecf25eae0287878840d7 ]
Fix transport header size
Fix the transpoert header size for UDP packets.
Signed-off-by: Shreyas N Bhatewara
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 ff3bc1e7527504a93710535611b2f812f3bb89bf ]
When pre-allocating skbs for received packets, we set ip_summed =
CHECKSUM_UNNCESSARY. We used to change it back to CHECKSUM_NONE when
the received packet had an incorrect checksum or unhandled protocol.Commit bc8acf2c8c3e43fcc192762a9f964b3e9a17748b ('drivers/net: avoid
some skb->ip_summed initializations') mistakenly replaced the latter
assignment with a DEBUG-only assertion that ip_summed ==
CHECKSUM_NONE. This assertion is always false, but it seems no-one
has exercised this code path in a DEBUG build.Fix this by moving our assignment of CHECKSUM_UNNECESSARY into
efx_rx_packet_gro().Signed-off-by: Ben Hutchings
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 8a49ad6e89feb5015e77ce6efeb2678947117e20 ]
This patch fixes a (mostly cosmetic) bug introduced by the patch
'ppp: Use SKB queue abstraction interfaces in fragment processing'
found here: http://www.spinics.net/lists/netdev/msg153312.htmlThe above patch rewrote and moved the code responsible for cleaning
up discarded fragments but the new code does not catch every case
where this is necessary. This results in some discarded fragments
remaining in the queue, and triggering a 'bad seq' error on the
subsequent call to ppp_mp_reconstruct. Fragments are discarded
whenever other fragments of the same frame have been lost.
This can generate a lot of unwanted and misleading log messages.This patch also adds additional detail to the debug logging to
make it clearer which fragments were lost and which other fragments
were discarded as a result of losses. (Run pppd with 'kdebug 1'
option to enable debug logging.)Signed-off-by: Ben McKeegan
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 -
[ Upstream commit 11aad99af6ef629ff3b05d1c9f0936589b204316 ]
This driver attempts to use two TX rings but lacks proper support :
1) IRQ handler only takes care of TX completion on first TX ring
2) the stop/start logic uses the legacy functions (for non multiqueue
drivers)This means all packets witk skb mark set to 1 are sent through high
queue but are never cleaned and queue eventualy fills and block the
device, triggering the infamous "NETDEV WATCHDOG" message.Lets use a single TX ring to fix the problem, this driver is not a real
multiqueue one yet.Minimal fix for stable kernels.
Reported-by: Thomas Meyer
Tested-by: Thomas Meyer
Signed-off-by: Eric Dumazet
Cc: Jay Cliburn
Cc: Chris Snook
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 461e74377cfcfc2c0d6bbdfa8fc5fbc21b052c2a upstream.
We have several reports which says acer-wmi is loaded on ideapads
and register rfkill for wifi which can not be unblocked.Since ideapad-laptop also register rfkill for wifi and it works
reliably, it will be fine acer-wmi is not going to register rfkill
for wifi once VPC2004 is found.Also put IBM0068/LEN0068 in the list. Though thinkpad_acpi has no
wifi rfkill capability, there are reports which says acer-wmi also
block wireless on Thinkpad E520/E420.Signed-off-by: Ike Panhc
Signed-off-by: Matthew Garrett
Cc: Jonathan Nieder
Signed-off-by: Greg Kroah-Hartman
