03 Apr, 2012
40 commits
-
commit c9651e70ad0aa499814817cbf3cc1d0b806ed3a1 upstream.
Since 3.2.12 and 3.3, some systems are failing to boot with a BUG_ON.
Some other systems using the pata_jmicron driver fail to boot because no
disks are detected. Passing pcie_aspm=force on the kernel command line
works around it.The cause: commit 4949be16822e ("PCI: ignore pre-1.1 ASPM quirking when
ASPM is disabled") changed the behaviour of pcie_aspm_sanity_check() to
always return 0 if aspm is disabled, in order to avoid cases where we
changed ASPM state on pre-PCIe 1.1 devices.This skipped the secondary function of pcie_aspm_sanity_check which was
to avoid us enabling ASPM on devices that had non-PCIe children, causing
trouble later on. Move the aspm_disabled check so we continue to honour
that scenario.Addresses https://bugzilla.kernel.org/show_bug.cgi?id=42979 and
http://bugs.debian.org/665420Reported-by: Romain Francoise # kernel panic
Reported-by: Chris Holland # disk detection trouble
Signed-off-by: Matthew Garrett
Tested-by: Hatem Masmoudi # Dell Latitude E5520
Tested-by: janek # pata_jmicron with JMB362/JMB363
[jn: with more symptoms in log message]
Signed-off-by: Jonathan Nieder
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 49d4bcaddca977fffdea8b0b71f6e5da96dac78e upstream.
When DMA is enabled, sh-sci transfer begins with
uart_start()
sci_start_tx()
if (cookie_tx < 0) schedule_work()
Then, starts DMA when wq scheduled, -- (A)
process_one_work()
work_fn_rx()
cookie_tx = desc->submit_tx()
And finishes when DMA transfer ends, -- (B)
sci_dma_tx_complete()
async_tx_ack()
cookie_tx = -EINVAL
(possible another schedule_work())This A to B sequence is not reentrant, since controlling variables
(for example, cookie_tx above) are not queues nor lists. So, they
must be invoked as A B A B..., otherwise results in kernel crash.To ensure the sequence, sci_start_tx() seems to test if cookie_tx < 0
(represents "not used") to call schedule_work().
But cookie_tx will not be set (to a cookie, also means "used") until
in the middle of work queue scheduled function work_fn_tx().This gap between the test and set allows the breakage of the sequence
under the very frequently call of uart_start().
Another gap between async_tx_ack() and another schedule_work() results
in the same issue, too.This patch introduces a new condition "cookie_tx == 0" just to mark
it is "busy" and assign it within spin-locked region to fill the gaps.Signed-off-by: Takashi Yoshii
Reviewed-by: Guennadi Liakhovetski
Signed-off-by: Paul Mundt
Signed-off-by: Greg Kroah-Hartman -
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 -
commit 1631fcea8399da5e80a80084b3b8c5bfd99d21e7 upstream.
was set up to use sys_sendfile() for the 32-bit
compat API instead of sys_sendfile64(), but in fact the right thing to
do is to use sys_sendfile64() in all cases. The 32-bit sendfile64() API
in glibc uses the sendfile64 syscall, so it has to be capable of doing
full 64-bit operations. But the sys_sendfile() kernel implementation
has a MAX_NON_LFS test in it which explicitly limits the offset to 2^32.
So, we need to use the sys_sendfile64() implementation in the kernel
for this case.Acked-by: Arnd Bergmann
Signed-off-by: Chris Metcalf
Signed-off-by: Greg Kroah-Hartman -
commit 8f0750f19789cf352d7e24a6cc50f2ab1b4f1372 upstream.
These are used as offsets into an array of GDT_ENTRY_TLS_ENTRIES members
so GDT_ENTRY_TLS_ENTRIES is one past the end of the array.Signed-off-by: Dan Carpenter
Link: http://lkml.kernel.org/r/20120324075250.GA28258@elgon.mountain
Signed-off-by: H. Peter Anvin
Signed-off-by: Greg Kroah-Hartman -
commit 57779dc2b3b75bee05ef5d1ada47f615f7a13932 upstream.
While running the latest Linux as guest under VMware in highly
over-committed situations, we have seen cases when the refined TSC
algorithm fails to get a valid tsc_start value in
tsc_refine_calibration_work from multiple attempts. As a result the
kernel keeps on scheduling the tsc_irqwork task for later. Subsequently
after several attempts when it gets a valid start value it goes through
the refined calibration and either bails out or uses the new results.
Given that the kernel originally read the TSC frequency from the
platform, which is the best it can get, I don't think there is much
value in refining it.So for systems which get the TSC frequency from the platform we
should skip the refined tsc algorithm.We can use the TSC_RELIABLE cpu cap flag to detect this, right now it is
set only on VMware and for Moorestown Penwell both of which have there
own TSC calibration methods.Signed-off-by: Alok N Kataria
Cc: John Stultz
Cc: Dirk Brandewie
Cc: Alan Cox
[jstultz: Reworked to simply not schedule the refining work,
rather then scheduling the work and bombing out later]
Signed-off-by: John Stultz
Signed-off-by: Greg Kroah-Hartman -
commit de5b8e8e047534aac6bc9803f96e7257436aef9c upstream.
If you try to set grace_period or timeout via a module parameter
to lockd, and do this on a big-endian machine wheresizeof(int) != sizeof(unsigned long)
it won't work. This number given will be effectively shifted right
by the difference in those two sizes.So cast kp->arg properly to get correct result.
Signed-off-by: NeilBrown
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 5676cc7bfe1e388e87843f71daa229610385b41e ]
Some BIOS's don't setup power management correctly (what else is
new) and don't allow use of PCI Express power control. Add a special
exception module parameter to allow working around this issue.
Based on slightly different patch by Knut Petersen.Reported-by: Arkadiusz Miskiewicz
Signed-off-by: Stephen Hemminger
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 dc72d99dabb870ca5bd6d9fff674be853bb4a88d ]
Matt Evans spotted that x86 bpf_jit was incorrectly handling negative
constant offsets in BPF_S_LDX_B_MSH instruction.We need to abort JIT compilation like we do in common_load so that
filter uses the interpreter code and can call __load_pointer()Reference: http://lists.openwall.net/netdev/2011/07/19/11
Thanks to Indan Zupancic to bring back this issue.
Reported-by: Matt Evans
Reported-by: Indan Zupancic
Signed-off-by: Eric Dumazet
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 3fa016a0b5c5237e9c387fc3249592b2cb5391c6 upstream.
Looking at hibernate overwriting I though it looked like a cursor,
so I tracked down this missing piece to stop the cursor blink
timer. I've no idea if this is sufficient to fix the hibernate
problems people are seeing, but please test it.Both radeon and nouveau have done this for a long time.
I've run this personally all night hib/resume cycles with no fails.
Reviewed-by: Keith Packard
Reported-by: Petr Tesarik
Reported-by: Stanislaw Gruszka
Reported-by: Lots of misc segfaults after hibernate across the world.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=37142
Tested-by: Dave Airlie
Tested-by: Bojan Smojver
Tested-by: Andreas Hartmann
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit fa0fb93f2ac308a76fa64eb57c18511dadf97089 upstream.
For high-speed/super-speed isochronous endpoints, the bInterval
value is used as exponent, 2^(bInterval-1). Luckily we have
usb_fill_int_urb() function that handles it correctly. So we just
call this function to fill in the RX URB.Cc: Marcel Holtmann
Signed-off-by: Bing Zhao
Acked-by: Marcel Holtmann
Signed-off-by: Gustavo F. Padovan
Signed-off-by: Greg Kroah-Hartman -
commit f946eeb9313ff1470758e171a60fe7438a2ded3f upstream.
Module size was limited to 64MB, this was legacy limitation due to vmalloc()
which was removed a while ago.Limiting module size to 64MB is both pointless and affects real world use
cases.Cc: Tim Abbott
Signed-off-by: Sasha Levin
Signed-off-by: Rusty Russell
Signed-off-by: Greg Kroah-Hartman -
commit 66c4c35c6bc5a1a452b024cf0364635b28fd94e4 upstream.
sysfs_slab_add() calls various sysfs functions that actually may
end up in userspace doing all sorts of things.Release the slub_lock after adding the kmem_cache structure to the list.
At that point the address of the kmem_cache is not known so we are
guaranteed exlusive access to the following modifications to the
kmem_cache structure.If the sysfs_slab_add fails then reacquire the slub_lock to
remove the kmem_cache structure from the list.Reported-by: Sasha Levin
Acked-by: Eric Dumazet
Signed-off-by: Christoph Lameter
Signed-off-by: Pekka Enberg
Signed-off-by: Greg Kroah-Hartman -
commit d97d32edcd732110758799ae60af725e5110b3dc upstream.
When an IO error happens during inode deletion run from
xlog_recover_process_iunlinks() filesystem gets shutdown. Thus any subsequent
attempt to read buffers fails. Code in xlog_recover_process_iunlinks() does not
count with the fact that read of a buffer which was read a while ago can
really fail which results in the oops on
agi = XFS_BUF_TO_AGI(agibp);Fix the problem by cleaning up the buffer handling in
xlog_recover_process_iunlinks() as suggested by Dave Chinner. We release buffer
lock but keep buffer reference to AG buffer. That is enough for buffer to stay
pinned in memory and we don't have to call xfs_read_agi() all the time.Signed-off-by: Jan Kara
Reviewed-by: Dave Chinner
Signed-off-by: Ben Myers
Signed-off-by: Greg Kroah-Hartman -
commit 8da00edc1069f01c34510fa405dc15d96c090a3f upstream.
Fix typo in drivers/video/backlight/tosa_lcd.c
"tosa_lcd_reume" should be "tosa_lcd_resume".Signed-off-by: Masanari Iida
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit aadbe266f2f89ccc68b52f4effc7b3a8b29521ef upstream.
Call the correct exit function on failure in dm_exception_store_init.
Signed-off-by: Andrei Warkentin
Acked-by: Mike Snitzer
Signed-off-by: Alasdair G Kergon
Signed-off-by: Greg Kroah-Hartman -
commit 72c6e7afc43e19f68a31dea204fc366624d6eee9 upstream.
Always set io->error to -EIO when an error is detected in dm-crypt.
There were cases where an error code would be set only if we finish
processing the last sector. If there were other encryption operations in
flight, the error would be ignored and bio would be returned with
success as if no error happened.This bug is present in kcryptd_crypt_write_convert, kcryptd_crypt_read_convert
and kcryptd_async_done.Signed-off-by: Mikulas Patocka
Reviewed-by: Milan Broz
Signed-off-by: Alasdair G Kergon
Signed-off-by: Greg Kroah-Hartman -
commit aeb2deae2660a1773c83d3c6e9e6575daa3855d6 upstream.
This patch fixes a possible deadlock in dm-crypt's mempool use.
Currently, dm-crypt reserves a mempool of MIN_BIO_PAGES reserved pages.
It allocates first MIN_BIO_PAGES with non-failing allocation (the allocation
cannot fail and waits until the mempool is refilled). Further pages are
allocated with different gfp flags that allow failing.Because allocations may be done in parallel, this code can deadlock. Example:
There are two processes, each tries to allocate MIN_BIO_PAGES and the processes
run simultaneously.
It may end up in a situation where each process allocates (MIN_BIO_PAGES / 2)
pages. The mempool is exhausted. Each process waits for more pages to be freed
to the mempool, which never happens.To avoid this deadlock scenario, this patch changes the code so that only
the first page is allocated with non-failing gfp mask. Allocation of further
pages may fail.Signed-off-by: Mikulas Patocka
Signed-off-by: Milan Broz
Signed-off-by: Alasdair G Kergon
Signed-off-by: Greg Kroah-Hartman -
commit a0391a3ae91d301c0e59368531a4de5f0b122bcf upstream.
udf_release_file() can be called from munmap() path with mmap_sem held. Thus
we cannot take i_mutex there because that ranks above mmap_sem. Luckily,
i_mutex is not needed in udf_release_file() anymore since protection by
i_data_sem is enough to protect from races with write and truncate.Reported-by: Al Viro
Reviewed-by: Namjae Jeon
Signed-off-by: Jan Kara
Signed-off-by: Greg Kroah-Hartman -
commit b18dafc86bb879d2f38a1743985d7ceb283c2f4d upstream.
In d_materialise_unique() there are 3 subcases to the 'aliased dentry'
case; in two subcases the inode i_lock is properly released but this
does not occur in the -ELOOP subcase.This seems to have been introduced by commit 1836750115f2 ("fix loop
checks in d_materialise_unique()").Signed-off-by: Michel Lespinasse
[ Added a comment, and moved the unlock to where we generate the -ELOOP,
which seems to be more natural.You probably can't actually trigger this without a buggy network file
server - d_materialize_unique() is for finding aliases on non-local
filesystems, and the d_ancestor() case is for a hardlinked directory
loop.But we should be robust in the case of such buggy servers anyway. ]
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 31d4f3a2f3c73f279ff96a7135d7202ef6833f12 upstream.
Explicitly test for an extent whose length is zero, and flag that as a
corrupted extent.This avoids a kernel BUG_ON assertion failure.
Tested: Without this patch, the file system image found in
tests/f_ext_zero_len/image.gz in the latest e2fsprogs sources causes a
kernel panic. With this patch, an ext4 file system error is noted
instead, and the file system is marked as being corrupted.https://bugzilla.kernel.org/show_bug.cgi?id=42859
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Greg Kroah-Hartman -
commit 3d2b158262826e8b75bbbfb7b97010838dd92ac7 upstream.
Ext4 does not support data journalling with delayed allocation enabled.
We even do not allow to mount the file system with delayed allocation
and data journalling enabled, however it can be set via FS_IOC_SETFLAGS
so we can hit the inode with EXT4_INODE_JOURNAL_DATA set even on file
system mounted with delayed allocation (default) and that's where
problem arises. The easies way to reproduce this problem is with the
following set of commands:mkfs.ext4 /dev/sdd
mount /dev/sdd /mnt/test1
dd if=/dev/zero of=/mnt/test1/file bs=1M count=4
chattr +j /mnt/test1/file
dd if=/dev/zero of=/mnt/test1/file bs=1M count=4 conv=notrunc
chattr -j /mnt/test1/fileAdditionally it can be reproduced quite reliably with xfstests 272 and
269. In fact the above reproducer is a part of test 272.To fix this we should ignore the EXT4_INODE_JOURNAL_DATA inode flag if
the file system is mounted with delayed allocation. This can be easily
done by fixing ext4_should_*_data() functions do ignore data journal
flag when delalloc is set (suggested by Ted). We also have to set the
appropriate address space operations for the inode (again, ignoring data
journal flag if delalloc enabled).Additionally this commit introduces ext4_inode_journal_mode() function
because ext4_should_*_data() has already had a lot of common code and
this change is putting it all into one function so it is easier to
read.Successfully tested with xfstests in following configurations:
delalloc + data=ordered
delalloc + data=writeback
data=journal
nodelalloc + data=ordered
nodelalloc + data=writeback
nodelalloc + data=journalSigned-off-by: Lukas Czerner
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Greg Kroah-Hartman -
commit 15291164b22a357cb211b618adfef4fa82fc0de3 upstream.
journal_unmap_buffer()'s zap_buffer: code clears a lot of buffer head
state ala discard_buffer(), but does not touch _Delay or _Unwritten as
discard_buffer() does.This can be problematic in some areas of the ext4 code which assume
that if they have found a buffer marked unwritten or delay, then it's
a live one. Perhaps those spots should check whether it is mapped
as well, but if jbd2 is going to tear down a buffer, let's really
tear it down completely.Without this I get some fsx failures on sub-page-block filesystems
up until v3.2, at which point 4e96b2dbbf1d7e81f22047a50f862555a6cb87cb
and 189e868fa8fdca702eb9db9d8afc46b5cb9144c9 make the failures go
away, because buried within that large change is some more flag
clearing. I still think it's worth doing in jbd2, since
->invalidatepage leads here directly, and it's the right place
to clear away these flags.Signed-off-by: Eric Sandeen
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Greg Kroah-Hartman -
commit dccaf33fa37a1bc5d651baeb3bfeb6becb86597b upstream.
(backported to 3.0 by mjt)
There is a race between ext4 buffer write and direct_IO read with
dioread_nolock mount option enabled. The problem is that we clear
PageWriteback flag during end_io time but will do
uninitialized-to-initialized extent conversion later with dioread_nolock.
If an O_direct read request comes in during this period, ext4 will return
zero instead of the recently written data.This patch checks whether there are any pending uninitialized-to-initialized
extent conversion requests before doing O_direct read to close the race.
Note that this is just a bandaid fix. The fundamental issue is that we
clear PageWriteback flag before we really complete an IO, which is
problem-prone. To fix the fundamental issue, we may need to implement an
extent tree cache that we can use to look up pending to-be-converted extents.Signed-off-by: Jiaying Zhang
Signed-off-by: "Theodore Ts'o"
Cc: Jan Kara
Signed-off-by: Michael Tokarev
Signed-off-by: Greg Kroah-Hartman -
commit 05b4877f6a4f1ba4952d1222213d262bf8c132b7 upstream.
If create_basic_memory_bitmaps() fails, usermodehelpers are not re-enabled
before returning. Fix this. And while at it, reword the goto labels so that
they look more meaningful.Signed-off-by: Srivatsa S. Bhat
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 09357b00255c233705b1cf6d76a8d147340545b8 upstream.
Based on the original patch submitted my Michael Wang
.
Descriptors may not be write-back while checking TX hang with flag
FLAG2_DMA_BURST on.
So when we detect hang, we just flush the descriptor and detect
again for once.-v2 change 1 to true and 0 to false and remove extra ()
CC: Michael Wang
CC: Flavio Leitner
Acked-by: Jesse Brandeburg
Tested-by: Aaron Brown
Signed-off-by: Jeff Kirsher
Signed-off-by: Greg Kroah-Hartman -
commit 9ab2393fc3e460cd2040de1483918eb17abb822f upstream.
The D1F5 revision of the WinTV HVR-1900 uses a tda18271c2 tuner
instead of a tda18271c1 tuner as used in revision D1E9. To
account for this, we must hardcode the frontend configuration
to use the same IF frequency configuration for both revisions
of the device.6MHz DVB-T is unaffected by this issue, as the recommended
IF Frequency configuration for 6MHz DVB-T is the same on both
c1 and c2 revisions of the tda18271 tuner.Signed-off-by: Michael Krufky
Cc: Mike Isely
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 34817174fca0c5512c2d5b6ea0fc37a0337ce1d8 upstream.
The error handling in lgdt3303_read_status() and lgdt330x_read_ucblocks()
doesn't work, because i2c_read_demod_bytes() returns a u8 and (err < 0)
is always false.err = i2c_read_demod_bytes(state, 0x58, buf, 1);
if (err < 0)
return err;Change the return type of i2c_read_demod_bytes() to int. Also change
the return value on error to -EIO to make (err < 0) work.Signed-off-by: Xi Wang
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit fc0900cbda9243957d812cd6b4cc87965f9fe75f upstream.
Wrong bit was used for sign extension which caused wrong end results.
Thanks to Andre for spotting this bug.Reported-by: Andre Przywara
Signed-off-by: Andreas Herrmann
Acked-by: Guenter Roeck
Signed-off-by: Jean Delvare
Signed-off-by: Greg Kroah-Hartman -
commit 1b26c9b334044cff6d1d2698f2be41bc7d9a0864 upstream.
The namespace cleanup path leaks a dentry which holds a reference count
on a network namespace. Keeping that network namespace from being freed
when the last user goes away. Leaving things like vlan devices in the
leaked network namespace.If you use ip netns add for much real work this problem becomes apparent
pretty quickly. It light testing the problem hides because frequently
you simply don't notice the leak.Use d_set_d_op() so that DCACHE_OP_* flags are set correctly.
This issue exists back to 3.0.
Acked-by: "Eric W. Biederman"
Reported-by: Justin Pettit
Signed-off-by: Pravin B Shelar
Signed-off-by: Jesse Gross
Cc: David Miller
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 29a2e2836ff9ea65a603c89df217f4198973a74f upstream.
The problem occurs on !CONFIG_VM86 kernels [1] when a kernel-mode task
returns from a system call with a pending signal.A real-life scenario is a child of 'khelper' returning from a failed
kernel_execve() in ____call_usermodehelper() [ kernel/kmod.c ].
kernel_execve() fails due to a pending SIGKILL, which is the result of
"kill -9 -1" (at least, busybox's init does it upon reboot).The loop is as follows:
* syscall_exit_work:
- work_pending: // start_of_the_loop
- work_notify_sig:
- do_notify_resume()
- do_signal()
- if (!user_mode(regs)) return;
- resume_userspace // TIF_SIGPENDING is still set
- work_pending // so we call work_pending => goto
// start_of_the_loopMore information can be found in another LKML thread:
http://www.serverphorums.com/read.php?12,457826[1] the problem was also seen on MIPS.
Signed-off-by: Dmitry Adamushko
Link: http://lkml.kernel.org/r/1332448765.2299.68.camel@dimm
Cc: Oleg Nesterov
Cc: Roland McGrath
Cc: Andrew Morton
Signed-off-by: H. Peter Anvin
Signed-off-by: Greg Kroah-Hartman -
commit 5d5440a835710d09f0ef18da5000541ec98b537a upstream.
URB unlinking is always racing with its completion and tx_complete
may be called before or during running usb_unlink_urb, so tx_complete
must not clear urb->dev since it will be used in unlink path,
otherwise invalid memory accesses or usb device leak may be caused
inside usb_unlink_urb.Cc: Alan Stern
Cc: Oliver Neukum
Signed-off-by: Ming Lei
Acked-by: Greg Kroah-Hartman
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 0956a8c20b23d429e79ff86d4325583fc06f9eb4 upstream.
Commit 4231d47e6fe69f061f96c98c30eaf9fb4c14b96d(net/usbnet: avoid
recursive locking in usbnet_stop()) fixes the recursive locking
problem by releasing the skb queue lock, but it makes usb_unlink_urb
racing with defer_bh, and the URB to being unlinked may be freed before
or during calling usb_unlink_urb, so use-after-free problem may be
triggerd inside usb_unlink_urb.The patch fixes the use-after-free problem by increasing URB
reference count with skb queue lock held before calling
usb_unlink_urb, so the URB won't be freed until return from
usb_unlink_urb.Cc: Sebastian Andrzej Siewior
Cc: Alan Stern
Cc: Oliver Neukum
Reported-by: Dave Jones
Signed-off-by: Ming Lei
Acked-by: Greg Kroah-Hartman
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
