10 Dec, 2015
2 commits
-
[ Upstream commit 45c8b7b175ceb2d542e0fe15247377bf3bce29ec ]
The current code for message reassembly is erroneously assuming that
the the first arriving fragment buffer always is linear, and then goes
ahead resetting the fragment list of that buffer in anticipation of
more arriving fragments.However, if the buffer already happens to be non-linear, we will
inadvertently drop the already attached fragment list, and later
on trig a BUG() in __pskb_pull_tail().We see this happen when running fragmented TIPC multicast across UDP,
something made possible since
commit d0f91938bede ("tipc: add ip/udp media type")We fix this by not resetting the fragment list when the buffer is non-
linear, and by initiatlizing our private fragment list tail pointer to
the tail of the existing fragment list.Fixes: commit d0f91938bede ("tipc: add ip/udp media type")
Signed-off-by: Jon Maloy
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 50010c20597d14667eff0fdb628309986f195230 ]
This is decrementing the pointer, instead of the value stored in the
pointer. KASan detects it as an out of bounds reference.Reported-by: "Berry Cheng 程君(成淼)"
Signed-off-by: Dan Carpenter
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
10 Nov, 2015
38 commits
-
commit 89c1a8cf63f8c69dfddb6e377c04df8b25ab1c88 upstream.
cd-gpios polarity should be changed to GPIO_ACTIVE_LOW and wp-gpios
should be changed to GPIO_ACTIVE_HIGH.
Otherwise, the SD may not work properly due to wrong polarity inversion
specified in DT after switch to common parsing function mmc_of_parse().Signed-off-by: Dong Aisheng
Acked-by: Shawn Guo
Signed-off-by: Ulf Hansson
Signed-off-by: Fabio Estevam
Signed-off-by: Greg Kroah-Hartman -
Fixes the backport of 0b34a166f291d255755be46e43ed5497cdd194f2 upstream
Commit 0b34a166f291d255755be46e43ed5497cdd194f2 "x86/xen: Support
kexec/kdump in HVM guests by doing a soft reset" has been added to the
4.2-stable tree" needed to correct the CONFIG variable, as
CONFIG_KEXEC_CORE only showed up in 4.3.Reported-by: David Vrabel
Reported-by: Luis Henriques
Signed-off-by: Greg Kroah-Hartman -
commit be32c0cf0462c36f482b5ddcff1d8371be1e183c upstream.
The Exar XR17V358 can also be combined with a XR17V354 chip to act as a
single 12 port chip. This works the same way as the combining two XR17V358
chips. But the reported device id then is 0x4358.Signed-off-by: Soeren Grunewald
Signed-off-by: Greg Kroah-Hartman -
commit 78e1c896932df5b8bcdff7bf5417d8e72a4d0d6b upstream.
The Intel Baytrail pinctrl driver implements irqchip callbacks which are
called with desc->lock raw_spinlock held. In mainline this is fine because
spinlock resolves to raw_spinlock. However, running the same code in -rt we
get:BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917
in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/0
Preemption disabled at:[] cpu_startup_entry+0x17f/0x480CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.5-rt5 #13
...
Call Trace:
[] dump_stack+0x4a/0x61
[] ___might_sleep+0xe7/0x170
[] rt_spin_lock+0x1f/0x50
[] byt_gpio_clear_triggering+0x38/0x60
[] byt_irq_mask+0x11/0x20
[] handle_level_irq+0x83/0x150
[] generic_handle_irq+0x27/0x40
[] byt_gpio_irq_handler+0x7f/0xc0
[] handle_irq+0xaa/0x190
...This is because in -rt spinlocks are preemptible so taking the driver
private spinlock in irqchip callbacks causes might_sleep() to trigger.In order to keep -rt happy but at the same time make sure that register
accesses get serialized, convert the driver to use raw_spinlock instead.Also shorten the critical section a bit in few places.
Suggested-by: Linus Walleij
Signed-off-by: Mika Westerberg
Signed-off-by: Linus Walleij
Cc: Lucas De Marchi
Signed-off-by: Greg Kroah-Hartman -
commit 39ce8150a079e3ae6ed9abf26d7918a558ef7c19 upstream.
There is a hardware issue in Intel Baytrail where concurrent GPIO register
access might result reads of 0xffffffff and writes might get dropped
completely.Prevent this from happening by taking the serializing lock in all places
where it is possible that more than one thread might be accessing the
hardware concurrently.Signed-off-by: Mika Westerberg
Signed-off-by: Linus Walleij
Cc: Lucas De Marchi
Signed-off-by: Greg Kroah-Hartman -
commit 47aee4d8e314384807e98b67ade07f6da476aa75 upstream.
Use is_zero_pfn() on pteval only after pte_present() check on pteval
(It might be better idea to introduce is_zero_pte() which checks
pte_present() first).Otherwise when working on a swap or migration entry and if pte_pfn's
result is equal to zero_pfn by chance, we lose user's data in
__collapse_huge_page_copy(). So if you're unlucky, the application
segfaults and finally you could see below message on exit:BUG: Bad rss-counter state mm:ffff88007f099300 idx:2 val:3
Fixes: ca0984caa823 ("mm: incorporate zero pages into transparent huge pages")
Signed-off-by: Minchan Kim
Reviewed-by: Andrea Arcangeli
Acked-by: Kirill A. Shutemov
Cc: Mel Gorman
Acked-by: Vlastimil Babka
Cc: Hugh Dickins
Cc: Rik van Riel
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 54c12bc374408faddbff75dbf1a6167c19af39c4 upstream.
If user space calls unreference on a user_dmabuf it will typically
kill the struct ttm_base_object member which is responsible for the
user-space visibility. However the dmabuf part may still be alive and
refcounted. In some situations, like for shared guest-backed surface
referencing/opening, the driver may try to reference the
struct ttm_base_object member again, causing an immediate kernel warning
and a later kernel NULL pointer dereference.Fix this by always maintaining a reference on the struct
ttm_base_object member, in situations where it might subsequently be
referenced.Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
Reviewed-by: Sinclair Yeh
Signed-off-by: Greg Kroah-Hartman -
commit 0dfc70c33409afc232ef0b9ec210535dfbf9bc61 upstream.
Resources are reallocated for requeued commands, so unmap and release
the iod for the failed command.It's a pretty bad memory leak and causes a kernel hang if you remove a
drive because of a busy dma pool. You'll get messages spewing like this:nvme 0000:xx:xx.x: dma_pool_destroy prp list 256, ffff880420dec000 busy
and lock up pci and the driver since removal never completes while
holding a lock.Signed-off-by: Keith Busch
Reviewed-by: Christoph Hellwig
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit 589cb22bbedacf325951014c07a35a2b01ca57f6 upstream.
If the STXR instruction fails in the SWP emulation code, we leave *data
overwritten with the loaded value, therefore corrupting the data written
by a subsequent, successful attempt.This patch re-jigs the code so that we only write back to *data once we
know that the update has happened.Fixes: bd35a4adc413 ("arm64: Port SWP/SWPB emulation support from arm")
Reported-by: Shengjiu Wang
Reported-by: Vladimir Murzin
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman -
commit e13d918a19a7b6cba62b32884f5e336e764c2cc6 upstream.
Commit dd006da21646 ("arm64: mm: increase VA range of identity map")
introduced a mechanism to extend the virtual memory map range
to support arm64 systems with system RAM located at very high offset,
where the identity mapping used to enable/disable the MMU requires
additional translation levels to map the physical memory at an equal
virtual offset.The kernel detects at boot time the tcr_el1.t0sz value required by the
identity mapping and sets-up the tcr_el1.t0sz register field accordingly,
any time the identity map is required in the kernel (ie when enabling the
MMU).After enabling the MMU, in the cold boot path the kernel resets the
tcr_el1.t0sz to its default value (ie the actual configuration value for
the system virtual address space) so that after enabling the MMU the
memory space translated by ttbr0_el1 is restored as expected.Commit dd006da21646 ("arm64: mm: increase VA range of identity map")
also added code to set-up the tcr_el1.t0sz value when the kernel resumes
from low-power states with the MMU off through cpu_resume() in order to
effectively use the identity mapping to enable the MMU but failed to add
the code required to restore the tcr_el1.t0sz to its default value, when
the core returns to the kernel with the MMU enabled, so that the kernel
might end up running with tcr_el1.t0sz value set-up for the identity
mapping which can be lower than the value required by the actual virtual
address space, resulting in an erroneous set-up.This patchs adds code in the resume path that restores the tcr_el1.t0sz
default value upon core resume, mirroring this way the cold boot path
behaviour therefore fixing the issue.Cc: Catalin Marinas
Fixes: dd006da21646 ("arm64: mm: increase VA range of identity map")
Acked-by: Ard Biesheuvel
Signed-off-by: Lorenzo Pieralisi
Signed-off-by: James Morse
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman -
commit af391b15f7b56ce19f52862d36595637dd42b575 upstream.
This patch renames __cpu_suspend to cpu_suspend so that it's aligned
with ARM32. It also removes the redundant wrapper created.This is in preparation to implement generic PSCI system suspend using
the cpu_{suspend,resume} which now has the same interface on both ARM
and ARM64.Cc: Mark Rutland
Reviewed-by: Lorenzo Pieralisi
Reviewed-by: Ashwin Chaugule
Signed-off-by: Sudeep Holla
Signed-off-by: Catalin Marinas
Signed-off-by: Greg Kroah-Hartman -
commit 8e601a9f97a00bab031980de34f9a81891c1f82f upstream.
This is a workaround for KNL platform, where in some cases MPERF counter
will not have updated value before next read of MSR_IA32_MPERF. In this
case divide by zero will occur. This change ignores current sample for
busy calculation in this case.Fixes: b34ef932d79a (intel_pstate: Knights Landing support)
Signed-off-by: Srinivas Pandruvada
Acked-by: Kristen Carlson Accardi
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 0ca81a2840f77855bbad1b9f172c545c4dc9e6a4 upstream.
ib_send_cm_sidr_rep could sometimes erase the node from the sidr
(depending on errors in the process). Since ib_send_cm_sidr_rep is
called both from cm_sidr_req_handler and cm_destroy_id, cm_id_priv
could be either erased from the rb_tree twice or not erased at all.
Fixing that by making sure it's erased only once before freeing
cm_id_priv.Fixes: a977049dacde ('[PATCH] IB: Add the kernel CM implementation')
Signed-off-by: Doron Tsur
Signed-off-by: Matan Barak
Signed-off-by: Doug Ledford
Signed-off-by: Greg Kroah-Hartman -
commit 0f89abf56abbd0e1c6e3cef9813e6d9f05383c1e upstream.
Commit 8eb934591f8b ("btrfs: check unsupported filters in balance
arguments") adds a jump to exit label out_bargs in case the argument
check fails. At this point in addition to the bargs memory, the
memory for struct btrfs_balance_control has already been allocated.
Ownership of bctl is passed to btrfs_balance() in the good case,
thus the memory is not freed due to the introduced jump. Make sure
that the memory gets freed in any case as necessary. Detected by
Coverity CID 1328378.Signed-off-by: Christian Engelmayer
Reviewed-by: David Sterba
Signed-off-by: Chris Mason
Signed-off-by: Greg Kroah-Hartman -
commit 22869a9eca4ea5b534538d160b68c7aef44e378a upstream.
This defines a new compatible option for MFD devices "simple-mfd" that will
make the OF core spawn child devices for all subnodes of that MFD device.
It is optional but handy for things like syscon and possibly other
simpler MFD devices.Since there was no file to put the documentation in, I took this opportunity
to make a small writeup on MFD devices and add the compatible definition
there.Suggested-by: Lee Jones
Acked-by: Lee Jones
Acked-by: Antoine Tenart
Acked-by: Alexandre Belloni
Cc: Arnd Bergmann
Cc: Devicetree
Cc: Rob Herring
Cc: Benjamin Herrenschmidt
Cc: Grant Likely
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Signed-off-by: Linus Walleij
Cc: Henrik Juul Pedersen
Signed-off-by: Greg Kroah-Hartman -
commit 2280521719e81919283b82902ac24058f87dfc1b upstream.
When pci_pool_alloc fails in mvs_task_prep then task->lldd_task stays
NULL but it's later used in mvs_abort_task as slot which is passed
to mvs_slot_task_free causing NULL pointer dereference.Just return from mvs_slot_task_free when passed with NULL slot.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101891
Signed-off-by: Dāvis Mosāns
Reviewed-by: Tomas Henzl
Reviewed-by: Johannes Thumshirn
Signed-off-by: James Bottomley
Signed-off-by: Greg Kroah-Hartman -
commit 209da39154837ec1b69fb34f438041939911e4b4 upstream.
The LIC doesn't deal with the different types of interrupts itself
but needs to forward calls to set the appropriate type to its parent
IRQ controller.Without this fix all IRQs routed through the LIC will stay at the
initial EDGE type, while most of them should actually be level triggered.Fixes: 1eec582158e2 "irqchip: tegra: Add Tegra210 support"
Signed-off-by: Lucas Stach
Cc: Stephen Warren
Cc: Thierry Reding
Cc: Alexandre Courbot
Cc: Jason Cooper
Cc: Marc Zyngier
Link: http://lkml.kernel.org/r/1445787552-13062-1-git-send-email-dev@lynxeye.de
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 2900ea609616c2651dec65312beeb2a6e536bc50 upstream.
In commit
7d375bffa524 ("sb_edac: Fix support for systems with two home agents per socket")
NUM_CHANNELS was changed to 8 and the channel space was renumerated to
handle EN, EP, and EX configurations.The *_mci_bind_devs() functions - except for sbridge_mci_bind_devs() -
got a new device presence check in the form of saw_chan_mask. However,
sbridge_mci_bind_devs() still uses the NUM_CHANNELS for loop.With the increase in NUM_CHANNELS, this loop fails at index 4 since
SB only has 4 TADs. This results in the following error on SB machines:EDAC sbridge: Some needed devices are missing
EDAC sbridge: Couldn't find mci handler
EDAC sbridge: Couldn't find mci handleThis patch adapts the saw_chan_mask logic for sbridge_mci_bind_devs() as
well.After this patch:
EDAC MC0: Giving out device to module sbridge_edac.c controller Sandy Bridge Socket#0: DEV 0000:3f:0e.0 (POLLED)
EDAC MC1: Giving out device to module sbridge_edac.c controller Sandy Bridge Socket#1: DEV 0000:7f:0e.0 (POLLED)Signed-off-by: Seth Jennings
Acked-by: Aristeu Rozanski
Acked-by: Tony Luck
Tested-by: Borislav Petkov
Cc: Mauro Carvalho Chehab
Cc: linux-edac
Link: http://lkml.kernel.org/r/1438798561-10180-1-git-send-email-sjenning@redhat.com
Signed-off-by: Borislav Petkov
Signed-off-by: Greg Kroah-Hartman -
commit d01552a76d71f9879af448e9142389ee9be6e95b upstream.
This reverts commit 7eb418851f3278de67126ea0c427641ab4792c57.
This commit is poorly justified, I can find not discusison in email,
and it clearly causes a problem.If a device which is being recovered fails and is subsequently
re-added to an array, there could easily have been changes to the
array *before* the point where the recovery was up to. So the
recovery must start again from the beginning.If a spare is being recovered and fails, then when it is re-added we
really should do a bitmap-based recovery up to the recovery-offset,
and then a full recovery from there. Before this reversion, we only
did the "full recovery from there" which is not corect. After this
reversion with will do a full recovery from the start, which is safer
but not ideal.It will be left to a future patch to arrange the two different styles
of recovery.Reported-and-tested-by: Nate Dailey
Signed-off-by: NeilBrown
Fixes: 7eb418851f32 ("md: allow a partially recovered device to be hot-added to an array.")
Signed-off-by: Greg Kroah-Hartman -
commit b8a9d66d043ffac116100775a469f05f5158c16f upstream.
After commit 566c09c53455 ("raid5: relieve lock contention in get_active_stripe()")
__find_stripe() is called under conf->hash_locks + hash.
But handle_stripe_clean_event() calls remove_hash() under
conf->device_lock.Under some cirscumstances the hash chain can be circuited,
and we get an infinite loop with disabled interrupts and locked hash
lock in __find_stripe(). This leads to hard lockup on multiple CPUs
and following system crash.I was able to reproduce this behavior on raid6 over 6 ssd disks.
The devices_handle_discard_safely option should be set to enable trim
support. The following script was used:for i in `seq 1 32`; do
dd if=/dev/zero of=large$i bs=10M count=100 &
doneneilb: original was against a 3.x kernel. I forward-ported
to 4.3-rc. This verison is suitable for any kernel since
Commit: 59fc630b8b5f ("RAID5: batch adjacent full stripe write")
(v4.1+). I'll post a version for earlier kernels to stable.Signed-off-by: Roman Gushchin
Fixes: 566c09c53455 ("raid5: relieve lock contention in get_active_stripe()")
Signed-off-by: NeilBrown
Cc: Shaohua Li
Signed-off-by: Greg Kroah-Hartman -
commit 681ab4696062f5aa939c9e04d058732306a97176 upstream.
This was introduced with 9e882242c6193ae6f416f2d8d8db0d9126bd996b
which changed the return value of submit_bio_wait() to return != 0 on
error, but didn't update the caller accordingly.Fixes: 9e882242c6 ("block: Add submit_bio_wait(), remove from md")
Reported-by: Bill Kuzeja
Signed-off-by: Jes Sorensen
Signed-off-by: NeilBrown
Signed-off-by: Greg Kroah-Hartman -
commit 203d27b0226a05202438ddb39ef0ef1acb14a759 upstream.
This was introduced with 9e882242c6193ae6f416f2d8d8db0d9126bd996b
which changed the return value of submit_bio_wait() to return != 0 on
error, but didn't update the caller accordingly.Fixes: 9e882242c6 ("block: Add submit_bio_wait(), remove from md")
Reported-by: Bill Kuzeja
Signed-off-by: Jes Sorensen
Signed-off-by: NeilBrown
Signed-off-by: Greg Kroah-Hartman -
commit 3fc89adb9fa4beff31374a4bf50b3d099d88ae83 upstream.
Currently a number of Crypto API operations may fail when a signal
occurs. This causes nasty problems as the caller of those operations
are often not in a good position to restart the operation.In fact there is currently no need for those operations to be
interrupted by user signals at all. All we need is for them to
be killable.This patch replaces the relevant calls of signal_pending with
fatal_signal_pending, and wait_for_completion_interruptible with
wait_for_completion_killable, respectively.Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit 195562194aad3a0a3915941077f283bcc6347b9b upstream.
commit 92bac83dd79e ("Input: alps - non interleaved V2 dualpoint has
separate stick button bits") assumes that all alps v2 non-interleaved
dual point setups have the separate stick button bits.Later we limited this to Dell laptops only because of reports that this
broke things on non Dell laptops. Now it turns out that this breaks things
on the Dell Latitude D600 too. So it seems that only the Dell Latitude
D420/430/620/630, which all share the same touchpad / stick combo,
have these separate bits.This patch limits the checking of the separate bits to only these models
fixing regressions with other models.Reported-and-tested-by: Larry Finger
Tested-by: Hans de Goede
Signed-off-by: Hans de Goede
Acked-By: Pali Rohár
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman -
commit ab79efab0a0ba01a74df782eb7fa44b044dae8b5 upstream.
In ovl_copy_up_locked(), newdentry is leaked if the function exits through
out_cleanup as this just to out after calling ovl_cleanup() - which doesn't
actually release the ref on newdentry.The out_cleanup segment should instead exit through out2 as certainly
newdentry leaks - and possibly upper does also, though this isn't caught
given the catch of newdentry.Without this fix, something like the following is seen:
BUG: Dentry ffff880023e9eb20{i=f861,n=#ffff880023e82d90} still in use (1) [unmount of tmpfs tmpfs]
BUG: Dentry ffff880023ece640{i=0,n=bigfile} still in use (1) [unmount of tmpfs tmpfs]when unmounting the upper layer after an error occurred in copyup.
An error can be induced by creating a big file in a lower layer with
something like:dd if=/dev/zero of=/lower/a/bigfile bs=65536 count=1 seek=$((0xf000))
to create a large file (4.1G). Overlay an upper layer that is too small
(on tmpfs might do) and then induce a copy up by opening it writably.Reported-by: Ulrich Obergfell
Signed-off-by: David Howells
Signed-off-by: Miklos Szeredi
Signed-off-by: Greg Kroah-Hartman -
commit 0480334fa60488d12ae101a02d7d9e1a3d03d7dd upstream.
Open the lower file with O_LARGEFILE in ovl_copy_up().
Pass O_LARGEFILE unconditionally in ovl_copy_up_data() as it's purely for
catching 32-bit userspace dealing with a file large enough that it'll be
mishandled if the application isn't aware that there might be an integer
overflow. Inside the kernel, there shouldn't be any problems.Reported-by: Ulrich Obergfell
Signed-off-by: David Howells
Signed-off-by: Miklos Szeredi
Signed-off-by: Greg Kroah-Hartman -
commit 5ffdbe8bf1e485026e1c7e4714d2841553cf0b40 upstream.
This fixes memory leak after umount.
Kmemleak report:
unreferenced object 0xffff8800ba791010 (size 8):
comm "mount", pid 2394, jiffies 4294996294 (age 53.920s)
hex dump (first 8 bytes):
20 1c 13 02 00 88 ff ff .......
backtrace:
[] create_object+0x124/0x2c0
[] kmemleak_alloc+0x7b/0xc0
[] __kmalloc+0x106/0x340
[] ovl_fill_super+0x55c/0x9b0 [overlay]
[] mount_nodev+0x54/0xa0
[] ovl_mount+0x18/0x20 [overlay]
[] mount_fs+0x43/0x170
[] vfs_kern_mount+0x74/0x170
[] do_mount+0x22d/0xdf0
[] SyS_mount+0x7b/0xc0
[] entry_SYSCALL_64_fastpath+0x12/0x76
[] 0xffffffffffffffffSigned-off-by: Konstantin Khlebnikov
Signed-off-by: Miklos Szeredi
Fixes: dd662667e6d3 ("ovl: add mutli-layer infrastructure")
Signed-off-by: Greg Kroah-Hartman -
commit 0f95502ad84874b3c05fc7cdd9d4d9d5cddf7859 upstream.
This fixes small memory leak after mount.
Kmemleak report:
unreferenced object 0xffff88003683fe00 (size 16):
comm "mount", pid 2029, jiffies 4294909563 (age 33.380s)
hex dump (first 16 bytes):
20 27 1f bb 00 88 ff ff 40 4b 0f 36 02 88 ff ff '......@K.6....
backtrace:
[] create_object+0x124/0x2c0
[] kmemleak_alloc+0x7b/0xc0
[] __kmalloc+0x106/0x340
[] ovl_fill_super+0x389/0x9a0 [overlay]
[] mount_nodev+0x54/0xa0
[] ovl_mount+0x18/0x20 [overlay]
[] mount_fs+0x43/0x170
[] vfs_kern_mount+0x74/0x170
[] do_mount+0x22d/0xdf0
[] SyS_mount+0x7b/0xc0
[] entry_SYSCALL_64_fastpath+0x12/0x76
[] 0xffffffffffffffffSigned-off-by: Konstantin Khlebnikov
Signed-off-by: Miklos Szeredi
Fixes: a78d9f0d5d5c ("ovl: support multiple lower layers")
Signed-off-by: Greg Kroah-Hartman -
commit 1266963170f576d4d08e6310b6963e26d3ff9d1e upstream.
63692df103e9 ("PCI: Allow numa_node override via sysfs") didn't check that
the numa node provided by userspace is valid. Passing a node number too
high would attempt to access invalid memory and trigger a kernel panic.Fixes: 63692df103e9 ("PCI: Allow numa_node override via sysfs")
Signed-off-by: Sasha Levin
Signed-off-by: Bjorn Helgaas
Signed-off-by: Greg Kroah-Hartman -
commit 275d7d44d802ef271a42dc87ac091a495ba72fc5 upstream.
Poma (on the way to another bug) reported an assertion triggering:
[] module_assert_mutex_or_preempt+0x49/0x90
[] __module_address+0x32/0x150
[] __module_text_address+0x16/0x70
[] symbol_put_addr+0x29/0x40
[] dvb_frontend_detach+0x7d/0x90 [dvb_core]Laura Abbott produced a patch which lead us to
inspect symbol_put_addr(). This function has a comment claiming it
doesn't need to disable preemption around the module lookup
because it holds a reference to the module it wants to find, which
therefore cannot go away.This is wrong (and a false optimization too, preempt_disable() is really
rather cheap, and I doubt any of this is on uber critical paths,
otherwise it would've retained a pointer to the actual module anyway and
avoided the second lookup).While its true that the module cannot go away while we hold a reference
on it, the data structure we do the lookup in very much _CAN_ change
while we do the lookup. Therefore fix the comment and add the
required preempt_disable().Reported-by: poma
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Rusty Russell
Fixes: a6e6abd575fc ("module: remove module_text_address()")
Signed-off-by: Greg Kroah-Hartman -
commit a54c8f0f2d7df525ff997e2afe71866a1a013064 upstream.
xen-blkfront will crash if the check to talk_to_blkback()
in blkback_changed()(XenbusStateInitWait) returns an error.
The driver data is freed and info is set to NULL. Later during
the close process via talk_to_blkback's call to xenbus_dev_fatal()
the null pointer is passed to and dereference in blkfront_closing.Signed-off-by: Cathy Avery
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Greg Kroah-Hartman -
commit fd7cd061adcf5f7503515ba52b6a724642a839c8 upstream.
We received several reports of systems rebooting and powering on
after an attempted shutdown. Testing showed that setting
XHCI_SPURIOUS_WAKEUP quirk in addition to the XHCI_SPURIOUS_REBOOT
quirk allowed the system to shutdown as expected for LynxPoint-LP
xHCI controllers. Set the quirk back.Note that the quirk was originally introduced for LynxPoint and
LynxPoint-LP just for this same reason. See:commit 638298dc66ea ("xhci: Fix spurious wakeups after S5 on Haswell")
It was later limited to only concern HP machines as it caused
regression on some machines, see both bug and commit:Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171
commit 6962d914f317 ("xhci: Limit the spurious wakeup fix only to HP machines")Later it was discovered that the powering on after shutdown
was limited to LynxPoint-LP (Haswell-ULT) and that some non-LP HP
machine suffered from spontaneous resume from S3 (which should
not be related to the SPURIOUS_WAKEUP quirk at all). An attempt
to fix this then removed the SPURIOUS_WAKEUP flag usage completely.commit b45abacde3d5 ("xhci: no switching back on non-ULT Haswell")
Current understanding is that LynxPoint-LP (Haswell ULT) machines
need the SPURIOUS_WAKEUP quirk, otherwise they will restart, and
plain Lynxpoint (Haswell) machines may _not_ have the quirk
set otherwise they again will restart.Signed-off-by: Laura Abbott
Cc: Takashi Iwai
Cc: Oliver Neukum
[Added more history to commit message -Mathias]
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
commit 3b4739b8951d650becbcd855d7d6f18ac98a9a85 upstream.
If a host fails to wake up a isochronous SuperSpeed device from U1/U2
in time for a isoch transfer it will generate a "No ping response error"
Host will then move to the next transfer descriptor.Handle this case in the same way as missed service errors, tag the
current TD as skipped and handle it on the next transfer event.Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
commit 0729a04977d497cf66234fd7f900ddcec3ef1c52 upstream.
Commit 00d8689b85a7 ("i2c: mv64xxx: rework offload support to fix
several problems") completely reworked the offload support, but left a
debugging-related "return false" at the beginning of the
mv64xxx_i2c_can_offload() function. This has the unfortunate consequence
that offloading is in fact never used, which wasn't really the
intention.This commit fixes that problem by removing the bogus "return false".
Fixes: 00d8689b85a7 ("i2c: mv64xxx: rework offload support to fix several problems")
Signed-off-by: Hezi Shahmoon
[Thomas: reworked commit log and title.]
Signed-off-by: Thomas Petazzoni
Signed-off-by: Wolfram Sang
Signed-off-by: Greg Kroah-Hartman -
commit f504ab1888026d15b5be8f9c262bf4ae9cacd177 upstream.
New device IDs shamelessly lifted from the vendor driver.
Signed-off-by: Bjørn Mork
Acked-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
commit f967fc8f165fadb72166f2bd4785094b3ca21307 upstream.
This reverts commit 9119fba0cfeda6d415c9f068df66838a104b87cb.
This commit prevents from sending "big" file using Bluetooth.
When sending a lot of data quickly through the Bluetooth interface, and
after a variable amount of data sent, transfer fails with error:
kernel: [ 415.247453] Bluetooth: hci0 hardware error 0x00Found on T100TA.
After reverting this commit, send works fine for any file size.
Signed-off-by: Frederic Danis
Fixes: 9119fba0cfed (serial: 8250_dma: don't bother DMA with small transfers)
Reviewed-by: Heikki Krogerus
Acked-by: Andy Shevchenko
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Greg Kroah-Hartman -
commit 4dcb8b57df3593dcb20481d9d6cf79d1dc1534be upstream.
btree_split_beneath()'s error path had an outstanding FIXME that speaks
directly to the potential for _not_ cleaning up a previously allocated
bufio-backed block.Fix this by releasing the previously allocated bufio block using
unlock_block().Reported-by: Mikulas Patocka
Signed-off-by: Mike Snitzer
Acked-by: Joe Thornber
Signed-off-by: Greg Kroah-Hartman
