commit ac3d826bef907afe35f80ecccbcdd57223df4b88
Author: Sasha Levin <alexander.levin@verizon.com>
Date: Tue Nov 29 11:44:43 2016 -0500
Linux 3.18.45
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit e45cc4194b96ede706205a7df824d85eb10a51eb
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Fri Nov 4 19:39:38 2016 +0100
kbuild: add -fno-PIE
[ Upstream commit 8ae94224c9d72fc4d9aaac93b2d7833cf46d7141 ]
Debian started to build the gcc with -fPIE by default so the kernel
build ends before it starts properly with:
|kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
Also add to KBUILD_AFLAGS due to:
|gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d … -mfentry -DCC_USING_FENTRY … vdso/vdso32/note.S
|arch/x86/entry/vdso/vdso32/note.S:1:0: sorry, unimplemented: -mfentry isn’t supported for 32-bit in combination with -fpic
Tagging it stable so it is possible to compile recent stable kernels as
well.
Cc: stable@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Michal Marek <mmarek@suse.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 1eb043fffc0aeca62ca3b33ffb346eae40f45411
Author: Stefan Richter <stefanr@s5r6.in-berlin.de>
Date: Sun Oct 30 17:32:01 2016 +0100
firewire: net: fix fragmented datagram_size off-by-one
[ Upstream commit e9300a4b7bbae83af1f7703938c94cf6dc6d308f ]
RFC 2734 defines the datagram_size field in fragment encapsulation
headers thus:
datagram_size: The encoded size of the entire IP datagram. The
value of datagram_size [...] SHALL be one less than the value of
Total Length in the datagram's IP header (see STD 5, RFC 791).
Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got
this field with a -/+1 offset:
ether1394_tx() /* transmit */
ether1394_encapsulate_prep()
hdr->ff.dg_size = dg_size - 1;
ether1394_data_handler() /* receive */
if (hdr->common.lf == ETH1394_HDR_LF_FF)
dg_size = hdr->ff.dg_size + 1;
else
dg_size = hdr->sf.dg_size + 1;
Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500
byte sized datagrams in fragments with datagram_size=1499 if link
fragmentation is required.
Only firewire-net sets and gets datagram_size without this offset. The
result is lacking interoperability of firewire-net with OS X, Windows
XP, and presumably Linux' eth1394. (I did not test with the latter.)
For example, FTP data transfers to a Linux firewire-net box with max_rec
smaller than the 1500 bytes MTU
- from OS X fail entirely,
- from Win XP start out with a bunch of fragmented datagrams which
time out, then continue with unfragmented datagrams because Win XP
temporarily reduces the MTU to 576 bytes.
So let's fix firewire-net's datagram_size accessors.
Note that firewire-net thereby loses interoperability with unpatched
firewire-net, but only if link fragmentation is employed. (This happens
with large broadcast datagrams, and with large datagrams on several
FireWire CardBus cards with smaller max_rec than equivalent PCI cards,
and it can be worked around by setting a small enough MTU.)
Cc: stable@vger.kernel.org
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit dff462fc98d649a51557491d02f5c16f2127970b
Author: Stefan Richter <stefanr@s5r6.in-berlin.de>
Date: Sat Oct 29 21:28:18 2016 +0200
firewire: net: guard against rx buffer overflows
[ Upstream commit 667121ace9dbafb368618dbabcf07901c962ddac ]
The IP-over-1394 driver firewire-net lacked input validation when
handling incoming fragmented datagrams. A maliciously formed fragment
with a respectively large datagram_offset would cause a memcpy past the
datagram buffer.
So, drop any packets carrying a fragment with offset + length larger
than datagram_size.
In addition, ensure that
- GASP header, unfragmented encapsulation header, or fragment
encapsulation header actually exists before we access it,
- the encapsulated datagram or fragment is of nonzero size.
Reported-by: Eyal Itkin <eyal.itkin@gmail.com>
Reviewed-by: Eyal Itkin <eyal.itkin@gmail.com>
Fixes: CVE 2016-8633
Cc: stable@vger.kernel.org
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 056bcad97c8e1ac7f6287a45b090ea51f93565cf
Author: John David Anglin <dave.anglin@bell.net>
Date: Fri Oct 28 23:00:34 2016 -0400
parisc: Ensure consistent state when switching to kernel stack at syscall entry
[ Upstream commit 6ed518328d0189e0fdf1bb7c73290d546143ea66 ]
We have one critical section in the syscall entry path in which we switch from
the userspace stack to kernel stack. In the event of an external interrupt, the
interrupt code distinguishes between those two states by analyzing the value of
sr7. If sr7 is zero, it uses the kernel stack. Therefore it's important, that
the value of sr7 is in sync with the currently enabled stack.
This patch now disables interrupts while executing the critical section. This
prevents the interrupt handler to possibly see an inconsistent state which in
the worst case can lead to crashes.
Interestingly, in the syscall exit path interrupts were already disabled in the
critical section which switches back to the userspace stack.
Cc: <stable@vger.kernel.org>
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit dff2cd539e4b537bf2e929eea256b20cd5262b35
Author: Miklos Szeredi <mszeredi@redhat.com>
Date: Mon Oct 31 14:42:14 2016 +0100
ovl: fsync after copy-up
[ Upstream commit 641089c1549d8d3df0b047b5de7e9a111362cdce ]
Make sure the copied up file hits the disk before renaming to the final
destination. If this is not done then the copy-up may corrupt the data in
the file in case of a crash.
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit cc30a01ae404cbf0ef1f419cbfab2af77f3c411c
Author: Matt Redfearn <matt.redfearn@imgtec.com>
Date: Tue Oct 11 12:05:15 2016 +0100
virtio: console: Unlock vqs while freeing buffers
[ Upstream commit 34563769e438d2881f62cf4d9badc4e589ac0ec0 ]
Commit c6017e793b93 ("virtio: console: add locks around buffer removal
in port unplug path") added locking around the freeing of buffers in the
vq. However, when free_buf() is called with can_sleep = true and rproc
is enabled, it calls dma_free_coherent() directly, requiring interrupts
to be enabled. Currently a WARNING is triggered due to the spin locking
around free_buf, with a call stack like this:
WARNING: CPU: 3 PID: 121 at ./include/linux/dma-mapping.h:433
free_buf+0x1a8/0x288
Call Trace:
[<8040c538>] show_stack+0x74/0xc0
[<80757240>] dump_stack+0xd0/0x110
[<80430d98>] __warn+0xfc/0x130
[<80430ee0>] warn_slowpath_null+0x2c/0x3c
[<807e7c6c>] free_buf+0x1a8/0x288
[<807ea590>] remove_port_data+0x50/0xac
[<807ea6a0>] unplug_port+0xb4/0x1bc
[<807ea858>] virtcons_remove+0xb0/0xfc
[<807b6734>] virtio_dev_remove+0x58/0xc0
[<807f918c>] __device_release_driver+0xac/0x134
[<807f924c>] device_release_driver+0x38/0x50
[<807f7edc>] bus_remove_device+0xfc/0x130
[<807f4b74>] device_del+0x17c/0x21c
[<807f4c38>] device_unregister+0x24/0x38
[<807b6b50>] unregister_virtio_device+0x28/0x44
Fix this by restructuring the loops to allow the locks to only be taken
where it is necessary to protect the vqs, and release it while the
buffer is being freed.
Fixes: c6017e793b93 ("virtio: console: add locks around buffer removal in port unplug path")
Cc: stable@vger.kernel.org
Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 919224dcf46262156e9c90dd4858a2097730d074
Author: NeilBrown <neilb@suse.com>
Date: Fri Oct 28 15:59:41 2016 +1100
md: be careful not lot leak internal curr_resync value into metadata. -- (all)
[ Upstream commit 1217e1d1999ed6c9c1e1b1acae0a74ab70464ae2 ]
mddev->curr_resync usually records where the current resync is up to,
but during the starting phase it has some "magic" values.
1 - means that the array is trying to start a resync, but has yielded
to another array which shares physical devices, and also needs to
start a resync
2 - means the array is trying to start resync, but has found another
array which shares physical devices and has already started resync.
3 - means that resync has commensed, but it is possible that nothing
has actually been resynced yet.
It is important that this value not be visible to user-space and
particularly that it doesn't get written to the metadata, as the
resync or recovery checkpoint. In part, this is because it may be
slightly higher than the correct value, though this is very rare.
In part, because it is not a multiple of 4K, and some devices only
support 4K aligned accesses.
There are two places where this value is propagates into either
->curr_resync_completed or ->recovery_cp or ->recovery_offset.
These currently avoid the propagation of values 1 and 3, but will
allow 3 to leak through.
Change them to only propagate the value if it is > 3.
As this can cause an array to fail, the patch is suitable for -stable.
Cc: stable@vger.kernel.org (v3.7+)
Reported-by: Viswesh <viswesh.vichu@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit debebae7513631270b3051dac8e5e7a0e3bdfe89
Author: NeilBrown <neilb@suse.com>
Date: Fri Jul 24 13:27:08 2015 +1000
md: sync sync_completed has correct value as recovery finishes.
[ Upstream commit 5ed1df2eacc0ba92c8c7e2499c97594b5ef928a8 ]
There can be a small window between the moment that recovery
actually writes the last block and the time when various sysfs
and /proc/mdstat attributes report that it has finished.
During this time, 'sync_completed' can have the wrong value.
This can confuse monitoring software.
So:
- don't set curr_resync_completed beyond the end of the devices,
- set it correctly when resync/recovery has completed.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 98d446ef289ddce78684965745d34a28b05cfb34
Author: Ching Huang <ching2048@areca.com.tw>
Date: Wed Oct 19 17:50:26 2016 +0800
scsi: arcmsr: Send SYNCHRONIZE_CACHE command to firmware
[ Upstream commit 2bf7dc8443e113844d078fd6541b7f4aa544f92f ]
The arcmsr driver failed to pass SYNCHRONIZE CACHE to controller
firmware. Depending on how drive caches are handled internally by
controller firmware this could potentially lead to data integrity
problems.
Ensure that cache flushes are passed to the controller.
[mkp: applied by hand and removed unused vars]
Cc: <stable@vger.kernel.org>
Signed-off-by: Ching Huang <ching2048@areca.com.tw>
Reported-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 103432f0b54a920c211f9d6c013f9ef7e0366d20
Author: Ewan D. Milne <emilne@redhat.com>
Date: Wed Oct 26 11:22:53 2016 -0400
scsi: scsi_debug: Fix memory leak if LBP enabled and module is unloaded
[ Upstream commit 4d2b496f19f3c2cfaca1e8fa0710688b5ff3811d ]
map_storep was not being vfree()'d in the module_exit call.
Cc: <stable@vger.kernel.org>
Signed-off-by: Ewan D. Milne <emilne@redhat.com>
Reviewed-by: Laurence Oberman <loberman@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit c0e76eccb785d480713918366e4f63b0d480a5bd
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Fri Oct 14 16:38:02 2016 -0400
drm/radeon/si_dpm: workaround for SI kickers
[ Upstream commit 7dc86ef5ac91642dfc3eb93ee0f0458e702a343e ]
Consolidate existing quirks. Fixes stability issues
on some kickers.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit b4caa5be158ef6ba86b63d9b95546e88e4ee5438
Author: James Hogan <james.hogan@imgtec.com>
Date: Tue Oct 25 16:11:11 2016 +0100
KVM: MIPS: Make ERET handle ERL before EXL
[ Upstream commit ede5f3e7b54a4347be4d8525269eae50902bd7cd ]
The ERET instruction to return from exception is used for returning from
exception level (Status.EXL) and error level (Status.ERL). If both bits
are set however we should be returning from ERL first, as ERL can
interrupt EXL, for example when an NMI is taken. KVM however checks EXL
first.
Fix the order of the checks to match the pseudocode in the instruction
set manual.
Fixes: e685c689f3a8 ("KVM/MIPS32: Privileged instruction/target branch emulation.")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim KrÄmář <rkrcmar@redhat.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Cc: <stable@vger.kernel.org> # 3.10.x-
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 1d98a7de7025c96fcb196a43ff0021011c528d8a
Author: Lucas Stach <dev@lynxeye.de>
Date: Mon Oct 24 23:32:04 2016 +0200
drm/radeon: drop register readback in cayman_cp_int_cntl_setup
[ Upstream commit 537b4b462caa8bfb9726d9695b8e56e2d5e6b41e ]
The read is taking a considerable amount of time (about 50us on this
machine). The register does not ever hold anything other than the ring
ID that is updated in this exact function, so there is no need for
the read modify write cycle.
This chops off a big chunk of the time spent in hardirq disabled
context, as this function is called multiple times in the interrupt
handler. With this change applied radeon won't show up in the list
of the worst IRQ latency offenders anymore, where it was a regular
before.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 24542192519d21719377d89f14654b3afd993a61
Author: Kashyap Desai <kashyap.desai@broadcom.com>
Date: Fri Oct 21 06:33:32 2016 -0700
scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) devices
[ Upstream commit 1e793f6fc0db920400574211c48f9157a37e3945 ]
Commit 02b01e010afe ("megaraid_sas: return sync cache call with
success") modified the driver to successfully complete SYNCHRONIZE_CACHE
commands without passing them to the controller. Disk drive caches are
only explicitly managed by controller firmware when operating in RAID
mode. So this commit effectively disabled writeback cache flushing for
any drives used in JBOD mode, leading to data integrity failures.
[mkp: clarified patch description]
Fixes: 02b01e010afeeb49328d35650d70721d2ca3fd59
CC: stable@vger.kernel.org
Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com>
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Ewan D. Milne <emilne@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit c6f51aabaf400f357eebe8f8f17e8bb39fc033dc
Author: Sasha Levin <alexander.levin@verizon.com>
Date: Sun Nov 20 10:05:28 2016 -0500
powerpc: Convert cmp to cmpd in idle enter sequence
[ Upstream commit 80f23935cadb1c654e81951f5a8b7ceae0acc1b4 ]
PowerPC's "cmp" instruction has four operands. Normally people write
"cmpw" or "cmpd" for the second cmp operand 0 or 1. But, frequently
people forget, and write "cmp" with just three operands.
With older binutils this is silently accepted as if this was "cmpw",
while often "cmpd" is wanted. With newer binutils GAS will complain
about this for 64-bit code. For 32-bit code it still silently assumes
"cmpw" is what is meant.
In this instance the code comes directly from ISA v2.07, including the
cmp, but cmpd is correct. Backport to stable so that new toolchains can
build old kernels.
Fixes: 948cf67c4726 ("powerpc: Add NAP mode support on Power7 in HV mode")
Cc: stable@vger.kernel.org # v3.0
Reviewed-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 2b5408a089d9f8672f89e90f77bc3f958c7263b5
Author: Tom St Denis <tom.stdenis@amd.com>
Date: Thu Oct 13 12:38:07 2016 -0400
drm/radeon/si_dpm: Limit clocks on HD86xx part
[ Upstream commit fb9a5b0c1c9893db2e0d18544fd49e19d784a87d ]
Limit clocks on a specific HD86xx part to avoid
crashes (while awaiting an appropriate PP fix).
Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 2c21744a274cb04817ce35c1ae13aa49d3246ca5
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Mon Sep 26 15:32:50 2016 -0400
drm/radeon/si/dpm: add workaround for for Jet parts
[ Upstream commit 670bb4fd21c966d0d2a59ad4a99bb4889f9a2987 ]
Add clock quirks for Jet parts.
Reviewed-by: Sonny Jiang <sonny.jiang@amd.com>
Tested-by: Sonny Jiang <sonny.jiang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 1f601388d5c150f0cef255bdb1a9296bdab9e157
Author: Johan Hovold <johan@kernel.org>
Date: Wed Oct 19 15:45:07 2016 +0200
USB: serial: cp210x: fix tiocmget error handling
[ Upstream commit de24e0a108bc48062e1c7acaa97014bce32a919f ]
The current tiocmget implementation would fail to report errors up the
stack and instead leaked a few bits from the stack as a mask of
modem-status flags.
Fixes: 39a66b8d22a3 ("[PATCH] USB: CP2101 Add support for flow control")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit d95841d1158bf0234198a4491471f5f3ab3de7fa
Author: Patrick Scheuring <patrick.scheuring.dev@gmail.com>
Date: Wed Oct 19 12:04:02 2016 -0700
Input: i8042 - add XMG C504 to keyboard reset table
[ Upstream commit da25311c7ca8b0254a686fc0d597075b9aa3b683 ]
The Schenker XMG C504 is a rebranded Gigabyte P35 v2 laptop.
Therefore it also needs a keyboard reset to detect the Elantech touchpad.
Otherwise the touchpad appears to be dead.
With this patch the touchpad is detected:
$ dmesg | grep -E "(i8042|Elantech|elantech)"
[ 2.675399] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[ 2.680372] i8042: Attempting to reset device connected to KBD port
[ 2.789037] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 2.791586] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 2.813840] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input4
[ 3.811431] psmouse serio1: elantech: assuming hardware version 4 (with firmware version 0x361f0e)
[ 3.825424] psmouse serio1: elantech: Synaptics capabilities query result 0x00, 0x15, 0x0f.
[ 3.839424] psmouse serio1: elantech: Elan sample query result 03, 58, 74
[ 3.911349] input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input6
Signed-off-by: Patrick Scheuring <patrick.scheuring.dev@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit fa3fcdd3d3564cc0d5b65e55ebc3f874fed370c0
Author: Johannes Berg <johannes.berg@intel.com>
Date: Wed Oct 5 10:14:42 2016 +0200
mac80211: discard multicast and 4-addr A-MSDUs
[ Upstream commit ea720935cf6686f72def9d322298bf7e9bd53377 ]
In mac80211, multicast A-MSDUs are accepted in many cases that
they shouldn't be accepted in:
* drop A-MSDUs with a multicast A1 (RA), as required by the
spec in 9.11 (802.11-2012 version)
* drop A-MSDUs with a 4-addr header, since the fourth address
can't actually be useful for them; unless 4-address frame
format is actually requested, even though the fourth address
is still not useful in this case, but ignored
Accepting the first case, in particular, is very problematic
since it allows anyone else with possession of a GTK to send
unicast frames encapsulated in a multicast A-MSDU, even when
the AP has client isolation enabled.
Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 7d9ad295527ff08a9f44aa71e2d77a84f57efcd1
Author: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Date: Wed Oct 19 12:29:41 2016 +0200
GenWQE: Fix bad page access during abort of resource allocation
[ Upstream commit a7a7aeefbca2982586ba2c9fd7739b96416a6d1d ]
When interrupting an application which was allocating DMAable
memory, it was possible, that the DMA memory was deallocated
twice, leading to the error symptoms below.
Thanks to Gerald, who analyzed the problem and provided this
patch.
I agree with his analysis of the problem: ddcb_cmd_fixups() ->
genwqe_alloc_sync_sgl() (fails in f/lpage, but sgl->sgl != NULL
and f/lpage maybe also != NULL) -> ddcb_cmd_cleanup() ->
genwqe_free_sync_sgl() (double free, because sgl->sgl != NULL and
f/lpage maybe also != NULL)
In this scenario we would have exactly the kind of double free that
would explain the WARNING / Bad page state, and as expected it is
caused by broken error handling (cleanup).
Using the Ubuntu git source, tag Ubuntu-4.4.0-33.52, he was able to reproduce
the "Bad page state" issue, and with the patch on top he could not reproduce
it any more.
------------[ cut here ]------------
WARNING: at /build/linux-o03cxz/linux-4.4.0/arch/s390/include/asm/pci_dma.h:141
Modules linked in: qeth_l2 ghash_s390 prng aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 sha_common genwqe_card qeth crc_itu_t qdio ccwgroup vmur dm_multipath dasd_eckd_mod dasd_mod
CPU: 2 PID: 3293 Comm: genwqe_gunzip Not tainted 4.4.0-33-generic #52-Ubuntu
task: 0000000032c7e270 ti: 00000000324e4000 task.ti: 00000000324e4000
Krnl PSW : 0404c00180000000 0000000000156346 (dma_update_cpu_trans+0x9e/0xa8)
R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
Krnl GPRS: 00000000324e7bcd 0000000000c3c34a 0000000027628298 000000003215b400
0000000000000400 0000000000001fff 0000000000000400 0000000116853000
07000000324e7b1e 0000000000000001 0000000000000001 0000000000000001
0000000000001000 0000000116854000 0000000000156402 00000000324e7a38
Krnl Code: 000000000015633a: 95001000 cli 0(%r1),0
000000000015633e: a774ffc3 brc 7,1562c4
#0000000000156342: a7f40001 brc 15,156344
>0000000000156346: 92011000 mvi 0(%r1),1
000000000015634a: a7f4ffbd brc 15,1562c4
000000000015634e: 0707 bcr 0,%r7
0000000000156350: c00400000000 brcl 0,156350
0000000000156356: eb7ff0500024 stmg %r7,%r15,80(%r15)
Call Trace:
([<00000000001563e0>] dma_update_trans+0x90/0x228)
[<00000000001565dc>] s390_dma_unmap_pages+0x64/0x160
[<00000000001567c2>] s390_dma_free+0x62/0x98
[<000003ff801310ce>] __genwqe_free_consistent+0x56/0x70 [genwqe_card]
[<000003ff801316d0>] genwqe_free_sync_sgl+0xf8/0x160 [genwqe_card]
[<000003ff8012bd6e>] ddcb_cmd_cleanup+0x86/0xa8 [genwqe_card]
[<000003ff8012c1c0>] do_execute_ddcb+0x110/0x348 [genwqe_card]
[<000003ff8012c914>] genwqe_ioctl+0x51c/0xc20 [genwqe_card]
[<000000000032513a>] do_vfs_ioctl+0x3b2/0x518
[<0000000000325344>] SyS_ioctl+0xa4/0xb8
[<00000000007b86c6>] system_call+0xd6/0x264
[<000003ff9e8e520a>] 0x3ff9e8e520a
Last Breaking-Event-Address:
[<0000000000156342>] dma_update_cpu_trans+0x9a/0xa8
---[ end trace 35996336235145c8 ]---
BUG: Bad page state in process jbd2/dasdb1-8 pfn:3215b
page:000003d100c856c0 count:-1 mapcount:0 mapping: (null) index:0x0
flags: 0x3fffc0000000000()
page dumped because: nonzero _count
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Frank Haverkamp <haver@linux.vnet.ibm.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 00736653372fce05cfe30e6c200d9d13a8a92308
Author: Chris Mason <clm@fb.com>
Date: Thu Oct 27 10:42:20 2016 -0700
btrfs: fix races on root_log_ctx lists
[ Upstream commit 570dd45042a7c8a7aba1ee029c5dd0f5ccf41b9b ]
btrfs_remove_all_log_ctxs takes a shortcut where it avoids walking the
list because it knows all of the waiters are patiently waiting for the
commit to finish.
But, there's a small race where btrfs_sync_log can remove itself from
the list if it finds a log commit is already done. Also, it uses
list_del_init() to remove itself from the list, but there's no way to
know if btrfs_remove_all_log_ctxs has already run, so we don't know for
sure if it is safe to call list_del_init().
This gets rid of all the shortcuts for btrfs_remove_all_log_ctxs(), and
just calls it with the proper locking.
This is part two of the corruption fixed by cbd60aa7cd1. I should have
done this in the first place, but convinced myself the optimizations were
safe. A 12 hour run of dbench 2048 will eventually trigger a list debug
WARN_ON for the list_del_init() in btrfs_sync_log().
Fixes: d1433debe7f4346cf9fc0dafc71c3137d2a97bc4
Reported-by: Dave Jones <davej@codemonkey.org.uk>
cc: stable@vger.kernel.org # 3.15+
Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 0b2a0a58ad22f9d6dfc641bc5ec46057493f22a5
Author: Scot Doyle <lkml14@scotdoyle.com>
Date: Thu Oct 13 12:12:43 2016 -0500
vt: clear selection before resizing
[ Upstream commit 009e39ae44f4191188aeb6dfbf661b771dbbe515 ]
When resizing a vt its selection may exceed the new size, resulting in
an invalid memory access [1]. Clear the selection before resizing.
[1] http://lkml.kernel.org/r/CACT4Y+acDTwy4umEvf5ROBGiRJNrxHN4Cn5szCXE5Jw-d1B=Xw@mail.gmail.com
Reported-and-tested-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 78ad6d4ce21be9409c0c5d8ddb9e3833819ee421
Author: Dmitry Vyukov <dvyukov@google.com>
Date: Fri Oct 14 15:18:28 2016 +0200
tty: limit terminal size to 4M chars
[ Upstream commit 32b2921e6a7461fe63b71217067a6cf4bddb132f ]
Size of kmalloc() in vc_do_resize() is controlled by user.
Too large kmalloc() size triggers WARNING message on console.
Put a reasonable upper bound on terminal size to prevent WARNINGs.
Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
CC: David Rientjes <rientjes@google.com>
Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: linux-kernel@vger.kernel.org
Cc: syzkaller@googlegroups.com
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 5352af8b4f82be5fb8a162f4e4278d523079aea9
Author: Marcel Hasler <mahasler@gmail.com>
Date: Thu Oct 27 00:42:27 2016 +0200
ALSA: usb-audio: Add quirk for Syntek STK1160
[ Upstream commit bdc3478f90cd4d2928197f36629d5cf93b64dbe9 ]
The stk1160 chip needs QUIRK_AUDIO_ALIGN_TRANSFER. This patch resolves
the issue reported on the mailing list
(http://marc.info/?l=linux-sound&m=139223599126215&w=2) and also fixes
bug 180071 (https://bugzilla.kernel.org/show_bug.cgi?id=180071).
Signed-off-by: Marcel Hasler <mahasler@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit abe571f80e33d3df7741d15cd03a8b95a93f659f
Author: David Howells <dhowells@redhat.com>
Date: Wed Oct 26 15:01:54 2016 +0100
KEYS: Fix short sprintf buffer in /proc/keys show function
[ Upstream commit 03dab869b7b239c4e013ec82aea22e181e441cfc ]
This fixes CVE-2016-7042.
Fix a short sprintf buffer in proc_keys_show(). If the gcc stack protector
is turned on, this can cause a panic due to stack corruption.
The problem is that xbuf[] is not big enough to hold a 64-bit timeout
rendered as weeks:
(gdb) p 0xffffffffffffffffULL/(60*60*24*7)
$2 = 30500568904943
That's 14 chars plus NUL, not 11 chars plus NUL.
Expand the buffer to 16 chars.
I think the unpatched code apparently works if the stack-protector is not
enabled because on a 32-bit machine the buffer won't be overflowed and on a
64-bit machine there's a 64-bit aligned pointer at one side and an int that
isn't checked again on the other side.
The panic incurred looks something like:
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81352ebe
CPU: 0 PID: 1692 Comm: reproducer Not tainted 4.7.2-201.fc24.x86_64 #1
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
0000000000000086 00000000fbbd2679 ffff8800a044bc00 ffffffff813d941f
ffffffff81a28d58 ffff8800a044bc98 ffff8800a044bc88 ffffffff811b2cb6
ffff880000000010 ffff8800a044bc98 ffff8800a044bc30 00000000fbbd2679
Call Trace:
[<ffffffff813d941f>] dump_stack+0x63/0x84
[<ffffffff811b2cb6>] panic+0xde/0x22a
[<ffffffff81352ebe>] ? proc_keys_show+0x3ce/0x3d0
[<ffffffff8109f7f9>] __stack_chk_fail+0x19/0x30
[<ffffffff81352ebe>] proc_keys_show+0x3ce/0x3d0
[<ffffffff81350410>] ? key_validate+0x50/0x50
[<ffffffff8134db30>] ? key_default_cmp+0x20/0x20
[<ffffffff8126b31c>] seq_read+0x2cc/0x390
[<ffffffff812b6b12>] proc_reg_read+0x42/0x70
[<ffffffff81244fc7>] __vfs_read+0x37/0x150
[<ffffffff81357020>] ? security_file_permission+0xa0/0xc0
[<ffffffff81246156>] vfs_read+0x96/0x130
[<ffffffff81247635>] SyS_read+0x55/0xc0
[<ffffffff817eb872>] entry_SYSCALL_64_fastpath+0x1a/0xa4
Reported-by: Ondrej Kozina <okozina@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Ondrej Kozina <okozina@redhat.com>
cc: stable@vger.kernel.org
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit a9dd8df76372507ba081e9d170edd064938d7719
Author: Long Li <longli@microsoft.com>
Date: Wed Oct 5 16:57:46 2016 -0700
hv: do not lose pending heartbeat vmbus packets
[ Upstream commit 407a3aee6ee2d2cb46d9ba3fc380bc29f35d020c ]
The host keeps sending heartbeat packets independent of the
guest responding to them. Even though we respond to the heartbeat messages at
interrupt level, we can have situations where there maybe multiple heartbeat
messages pending that have not been responded to. For instance this occurs when the
VM is paused and the host continues to send the heartbeat messages.
Address this issue by draining and responding to all
the heartbeat messages that maybe pending.
Signed-off-by: Long Li <longli@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
CC: Stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit d70f2ee448d4255b63aa2739ce01cb391e602d6b
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date: Wed Oct 19 01:34:48 2016 +0300
mei: txe: don't clean an unprocessed interrupt cause.
[ Upstream commit 43605e293eb13c07acb546c14f407a271837af17 ]
SEC registers are not accessible when the TXE device is in low power
state, hence the SEC interrupt cannot be processed if device is not
awake.
In some rare cases entrance to low power state (aliveness off) and input
ready bits can be signaled at the same time, resulting in communication
stall as input ready won't be signaled again after waking up. To resolve
this IPC_HHIER_SEC bit in HHISR_REG should not be cleaned if the
interrupt is not processed.
Cc: stable@vger.kernel.org
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit f596302c66a6100f564ce2ca6d2dafcfe5c79983
Author: tang.junhui <tang.junhui@zte.com.cn>
Date: Fri Oct 21 09:35:32 2016 +0800
dm table: fix missing dm_put_target_type() in dm_table_add_target()
[ Upstream commit dafa724bf582181d9a7d54f5cb4ca0bf8ef29269 ]
dm_get_target_type() was previously called so any error returned from
dm_table_add_target() must first call dm_put_target_type(). Otherwise
the DM target module's reference count will leak and the associated
kernel module will be unable to be removed.
Also, leverage the fact that r is already -EINVAL and remove an extra
newline.
Fixes: 36a0456 ("dm table: add immutable feature")
Fixes: cc6cbe1 ("dm table: add always writeable feature")
Fixes: 3791e2f ("dm table: add singleton feature")
Cc: stable@vger.kernel.org # 3.2+
Signed-off-by: tang.junhui <tang.junhui@zte.com.cn>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 6e64ac0957e06a81b22f95f3509cc39b07735d3d
Author: Bryan Paluch <bryanpaluch@gmail.com>
Date: Mon Oct 17 08:54:46 2016 -0400
usb: increase ohci watchdog delay to 275 msec
[ Upstream commit ed6d6f8f42d7302f6f9b6245f34927ec20d26c12 ]
Increase ohci watchout delay to 275 ms. Previous delay was 250 ms
with 20 ms of slack, after removing slack time some ohci controllers don't
respond in time. Logs from systems with controllers that have the
issue would show "HcDoneHead not written back; disabled"
Signed-off-by: Bryan Paluch <bryanpaluch@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit b6304f09377d88819e8856d9fad574ebe4e2239f
Author: Johan Hovold <johan@kernel.org>
Date: Fri Oct 21 12:56:27 2016 +0200
USB: serial: fix potential NULL-dereference at probe
[ Upstream commit 126d26f66d9890a69158812a6caa248c05359daa ]
Make sure we have at least one port before attempting to register a
console.
Currently, at least one driver binds to a "dummy" interface and requests
zero ports for it. Should such an interface also lack endpoints, we get
a NULL-deref during probe.
Fixes: e5b1e2062e05 ("USB: serial: make minor allocation dynamic")
Cc: stable <stable@vger.kernel.org> # 3.11
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit e42afd00e43cb13dafcfc9256471d342fb185cf1
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date: Thu Oct 20 18:09:18 2016 +0300
xhci: add restart quirk for Intel Wildcatpoint PCH
[ Upstream commit 4c39135aa412d2f1381e43802523da110ca7855c ]
xHC in Wildcatpoint-LP PCH is similar to LynxPoint-LP and need the
same quirks to prevent machines from spurious restart while
shutting them down.
Reported-by: Hasan Mahmood <hasan.mahm@gmail.com>
CC: <stable@vger.kernel.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit da512d38ffce476a7bebb4474ed572887cbb5fb1
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date: Thu Oct 20 15:46:18 2016 +1100
libxfs: clean up _calc_dquots_per_chunk
[ Upstream commit 58d789678546d46d7bbd809dd7dab417c0f23655 ]
The function xfs_calc_dquots_per_chunk takes a parameter in units
of basic blocks. The kernel seems to get the units wrong, but
userspace got 'fixed' by commenting out the unnecessary conversion.
Fix both.
cc: <stable@vger.kernel.org>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 6848fad2cbb5a1b86f1e39088ab1358a1ea81cfa
Author: Dinesh Israni <ddi@datera.io>
Date: Mon Oct 10 20:22:03 2016 -0700
target: Don't override EXTENDED_COPY xcopy_pt_cmd SCSI status code
[ Upstream commit 926317de33998c112c5510301868ea9aa34097e2 ]
This patch addresses a bug where a local EXTENDED_COPY WRITE or READ
backend I/O request would always return SAM_STAT_CHECK_CONDITION,
even if underlying xcopy_pt_cmd->se_cmd generated a different
SCSI status code.
ESX host environments expect to hit SAM_STAT_RESERVATION_CONFLICT
for certain scenarios, and SAM_STAT_CHECK_CONDITION results in
non-retriable status for these cases.
Tested on v4.1.y with ESX v5.5u2+ with local IBLOCK backend copy.
Reported-by: Nixon Vincent <nixon.vincent@calsoftinc.com>
Tested-by: Nixon Vincent <nixon.vincent@calsoftinc.com>
Cc: Nixon Vincent <nixon.vincent@calsoftinc.com>
Tested-by: Dinesh Israni <ddi@datera.io>
Signed-off-by: Dinesh Israni <ddi@datera.io>
Cc: Dinesh Israni <ddi@datera.io>
Cc: stable@vger.kernel.org # 3.14+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit c30d39a0de7c198ad6fd55403130b2d063b65312
Author: Richard Weinberger <richard@nod.at>
Date: Tue Sep 20 10:08:30 2016 +0200
ubifs: Fix xattr_names length in exit paths
[ Upstream commit 843741c5778398ea67055067f4cc65ae6c80ca0e ]
When the operation fails we also have to undo the changes
we made to ->xattr_names. Otherwise listxattr() will report
wrong lengths.
Cc: stable@vger.kernel.org
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 1ef14328fbf61bf0ebdcc404395c771f401d3b2b
Author: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Date: Fri Jun 17 18:53:28 2016 +0200
powerpc/mm: Prevent unlikely crash in copro_calculate_slb()
[ Upstream commit d2cf909cda5f8c5609cb7ed6cda816c3e15528c7 ]
If a cxl adapter faults on an invalid address for a kernel context, we
may enter copro_calculate_slb() with a NULL mm pointer (kernel
context) and an effective address which looks like a user
address. Which will cause a crash when dereferencing mm. It is clearly
an AFU bug, but there's no reason to crash either. So return an error,
so that cxl can ack the interrupt with an address error.
Fixes: 73d16a6e0e51 ("powerpc/cell: Move data segment faulting code out of cell platform")
Cc: stable@vger.kernel.org # v3.18+
Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Acked-by: Ian Munsie <imunsie@au1.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 249ed62d33fe9e0193cdc29a0a371076f9a71857
Author: Jan Kara <jack@suse.cz>
Date: Tue Oct 4 13:44:06 2016 +0200
isofs: Do not return EACCES for unknown filesystems
[ Upstream commit a2ed0b391dd9c3ef1d64c7c3e370f4a5ffcd324a ]
When isofs_mount() is called to mount a device read-write, it returns
EACCES even before it checks that the device actually contains an isofs
filesystem. This may confuse mount(8) which then tries to mount all
subsequent filesystem types in read-only mode.
Fix the problem by returning EACCES only once we verify that the device
indeed contains an iso9660 filesystem.
CC: stable@vger.kernel.org
Fixes: 17b7f7cf58926844e1dd40f5eb5348d481deca6a
Reported-by: Kent Overstreet <kent.overstreet@gmail.com>
Reported-by: Karel Zak <kzak@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 836308dcbdc9c4e42a124c7c648b4db8425fc042
Author: Stefan Tauner <stefan.tauner@technikum-wien.at>
Date: Thu Oct 6 18:40:11 2016 +0200
USB: serial: ftdi_sio: add support for Infineon TriBoard TC2X7
[ Upstream commit ca006f785fbfd7a5c901900bd3fe2b26e946a1ee ]
This adds support to ftdi_sio for the Infineon TriBoard TC2X7
engineering board for first-generation Aurix SoCs with Tricore CPUs.
Mere addition of the device IDs does the job.
Signed-off-by: Stefan Tauner <stefan.tauner@technikum-wien.at>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 85f89aaf55489e01c9735577990a6d8477cee658
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date: Wed Sep 28 11:33:28 2016 -0700
memstick: rtsx_usb_ms: Manage runtime PM when accessing the device
[ Upstream commit 9158cb29e7c2f10dd325eb1589f0fe745a271257 ]
Accesses to the rtsx usb device, which is the parent of the rtsx memstick
device, must not be done unless it's runtime resumed. This is currently not
the case and it could trigger various errors.
Fix this by properly deal with runtime PM in this regards. This means
making sure the device is runtime resumed, when serving requests via the
->request() callback or changing settings via the ->set_param() callbacks.
Cc: <stable@vger.kernel.org>
Cc: Ritesh Raj Sarraf <rrs@researchut.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit a5eade900fc89adf2b7cd18c6d61e6b85abff7e5
Author: Alan Stern <stern@rowland.harvard.edu>
Date: Mon Sep 26 15:45:41 2016 -0700
memstick: rtsx_usb_ms: Runtime resume the device when polling for cards
[ Upstream commit 796aa46adf1d90eab36ae06a42e6d3f10b28a75c ]
Accesses to the rtsx usb device, which is the parent of the rtsx memstick
device, must not be done unless it's runtime resumed.
Therefore when the rtsx_usb_ms driver polls for inserted memstick cards,
let's add pm_runtime_get|put*() to make sure accesses is done when the
rtsx usb device is runtime resumed.
Reported-by: Ritesh Raj Sarraf <rrs@researchut.com>
Tested-by: Ritesh Raj Sarraf <rrs@researchut.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit b2580c4ba788bd913759b14dc9f5a9ef2ada997d
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date: Thu Sep 15 14:46:21 2016 +0200
mmc: rtsx_usb_sdmmc: Handle runtime PM while changing the led
[ Upstream commit 4f48aa7a11bfed9502a7c85a5b68cd40ea827f73 ]
Accesses of the rtsx sdmmc's parent device, which is the rtsx usb device,
must be done when it's runtime resumed. Currently this isn't case when
changing the led, so let's fix this by adding a pm_runtime_get_sync() and
a pm_runtime_put() around those operations.
Reported-by: Ritesh Raj Sarraf <rrs@researchut.com>
Tested-by: Ritesh Raj Sarraf <rrs@researchut.com>
Cc: <stable@vger.kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 29cce652d7f43481a8cab30d94b73304849ce1cb
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date: Tue Sep 27 08:44:33 2016 -0700
mmc: rtsx_usb_sdmmc: Avoid keeping the device runtime resumed when unused
[ Upstream commit 31cf742f515c275d22843c4c756e048d2b6d716c ]
The rtsx_usb_sdmmc driver may bail out in its ->set_ios() callback when no
SD card is inserted. This is wrong, as it could cause the device to remain
runtime resumed when it's unused. Fix this behaviour.
Tested-by: Ritesh Raj Sarraf <rrs@researchut.com>
Cc: <stable@vger.kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 3ee23181095ce57c85f070c5cac509b1da304e1d
Author: Haibo Chen <haibo.chen@nxp.com>
Date: Mon Oct 17 10:18:37 2016 +0200
mmc: sdhci: cast unsigned int to unsigned long long to avoid unexpeted error
[ Upstream commit 02265cd60335a2c1417abae4192611e1fc05a6e5 ]
Potentially overflowing expression 1000000 * data->timeout_clks with
type unsigned int is evaluated using 32-bit arithmetic, and then used
in a context that expects an expression of type unsigned long long.
To avoid overflow, cast 1000000U to type unsigned long long.
Special thanks to Coverity.
Fixes: 7f05538af71c ("mmc: sdhci: fix data timeout (part 2)")
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Cc: stable@vger.kernel.org # v3.15+
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 27c8728510db7bee957ced720990227fa773a14d
Author: Felipe Balbi <felipe.balbi@linux.intel.com>
Date: Tue Oct 4 15:14:43 2016 +0300
usb: gadget: function: u_ether: don't starve tx request queue
[ Upstream commit 6c83f77278f17a7679001027e9231291c20f0d8a ]
If we don't guarantee that we will always get an
interrupt at least when we're queueing our very last
request, we could fall into situation where we queue
every request with 'no_interrupt' set. This will
cause the link to get stuck.
The behavior above has been triggered with g_ether
and dwc3.
Cc: <stable@vger.kernel.org>
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 60299e356a54b938af0b0f5c53f58c1ceb8b2ef1
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Fri Oct 14 10:26:21 2016 +0300
irqchip/gicv3: Handle loop timeout proper
[ Upstream commit d102eb5c1ac5e6743b1c6d145c06a25d98ad1375 ]
The timeout loop terminates when the loop count is zero, but the decrement
of the count variable is post check. So count is -1 when we check for the
timeout and therefor the error message is supressed.
Change it to predecrement, so the error message is emitted.
[ tglx: Massaged changelog ]
Fixes: a2c225101234 ("irqchip: gic-v3: Refactor gic_enable_redist to support both enabling and disabling")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: kernel-janitors@vger.kernel.org
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20161014072534.GA15168@mwanda
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 5617a13564bf1438a0dbfdde79c3bbf769190fbd
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Wed Oct 12 15:28:55 2016 -0400
drm/radeon: change vblank_time's calculation method to reduce computational error.
[ Upstream commit 02cfb5fccb0f9f968f0e208d89d9769aa16267bc ]
Ported from Rex's amdgpu change.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 74407793c5d017cfa295a226f06160331c2bc29e
Author: Taesoo Kim <tsgatesv@gmail.com>
Date: Wed Oct 12 23:19:18 2016 -0400
jbd2: fix incorrect unlock on j_list_lock
[ Upstream commit 559cce698eaf4ccecb2213b2519ea3a0413e5155 ]
When 'jh->b_transaction == transaction' (asserted by below)
J_ASSERT_JH(jh, (jh->b_transaction == transaction || ...
'journal->j_list_lock' will be incorrectly unlocked, since
the the lock is aquired only at the end of if / else-if
statements (missing the else case).
Signed-off-by: Taesoo Kim <tsgatesv@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Fixes: 6e4862a5bb9d12be87e4ea5d9a60836ebed71d28
Cc: stable@vger.kernel.org # 3.14+
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 37f487e02e46b1e12bd06adfb6edb3a9a1605a64
Author: Ming Lei <tom.leiming@gmail.com>
Date: Sun Oct 9 13:23:27 2016 +0800
scsi: Fix use-after-free
[ Upstream commit bcd8f2e94808fcddf6ef3af5f060a36820dcc432 ]
This patch fixes one use-after-free report[1] by KASAN.
In __scsi_scan_target(), when a type 31 device is probed,
SCSI_SCAN_TARGET_PRESENT is returned and the target will be scanned
again.
Inside the following scsi_report_lun_scan(), one new scsi_device
instance is allocated, and scsi_probe_and_add_lun() is called again to
probe the target and still see type 31 device, finally
__scsi_remove_device() is called to remove & free the device at the end
of scsi_probe_and_add_lun(), so cause use-after-free in
scsi_report_lun_scan().
And the following SCSI log can be observed:
scsi 0:0:2:0: scsi scan: INQUIRY pass 1 length 36
scsi 0:0:2:0: scsi scan: INQUIRY successful with code 0x0
scsi 0:0:2:0: scsi scan: peripheral device type of 31, no device added
scsi 0:0:2:0: scsi scan: Sending REPORT LUNS to (try 0)
scsi 0:0:2:0: scsi scan: REPORT LUNS successful (try 0) result 0x0
scsi 0:0:2:0: scsi scan: REPORT LUN scan
scsi 0:0:2:0: scsi scan: INQUIRY pass 1 length 36
scsi 0:0:2:0: scsi scan: INQUIRY successful with code 0x0
scsi 0:0:2:0: scsi scan: peripheral device type of 31, no device added
BUG: KASAN: use-after-free in __scsi_scan_target+0xbf8/0xe40 at addr ffff88007b44a104
This patch fixes the issue by moving the putting reference at
the end of scsi_report_lun_scan().
[1] KASAN report
==================================================================
[ 3.274597] PM: Adding info for serio:serio1
[ 3.275127] BUG: KASAN: use-after-free in __scsi_scan_target+0xd87/0xdf0 at addr ffff880254d8c304
[ 3.275653] Read of size 4 by task kworker/u10:0/27
[ 3.275903] CPU: 3 PID: 27 Comm: kworker/u10:0 Not tainted 4.8.0 #2121
[ 3.276258] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[ 3.276797] Workqueue: events_unbound async_run_entry_fn
[ 3.277083] ffff880254d8c380 ffff880259a37870 ffffffff94bbc6c1 ffff880078402d80
[ 3.277532] ffff880254d8bb80 ffff880259a37898 ffffffff9459fec1 ffff880259a37930
[ 3.277989] ffff880254d8bb80 ffff880078402d80 ffff880259a37920 ffffffff945a0165
[ 3.278436] Call Trace:
[ 3.278528] [<ffffffff94bbc6c1>] dump_stack+0x65/0x84
[ 3.278797] [<ffffffff9459fec1>] kasan_object_err+0x21/0x70
[ 3.279063] device: 'psaux': device_add
[ 3.279616] [<ffffffff945a0165>] kasan_report_error+0x205/0x500
[ 3.279651] PM: Adding info for No Bus:psaux
[ 3.280202] [<ffffffff944ecd22>] ? kfree_const+0x22/0x30
[ 3.280486] [<ffffffff94bc2dc9>] ? kobject_release+0x119/0x370
[ 3.280805] [<ffffffff945a0543>] __asan_report_load4_noabort+0x43/0x50
[ 3.281170] [<ffffffff9507e1f7>] ? __scsi_scan_target+0xd87/0xdf0
[ 3.281506] [<ffffffff9507e1f7>] __scsi_scan_target+0xd87/0xdf0
[ 3.281848] [<ffffffff9507d470>] ? scsi_add_device+0x30/0x30
[ 3.282156] [<ffffffff94f7f660>] ? pm_runtime_autosuspend_expiration+0x60/0x60
[ 3.282570] [<ffffffff956ddb07>] ? _raw_spin_lock+0x17/0x40
[ 3.282880] [<ffffffff9507e505>] scsi_scan_channel+0x105/0x160
[ 3.283200] [<ffffffff9507e8a2>] scsi_scan_host_selected+0x212/0x2f0
[ 3.283563] [<ffffffff9507eb3c>] do_scsi_scan_host+0x1bc/0x250
[ 3.283882] [<ffffffff9507efc1>] do_scan_async+0x41/0x450
[ 3.284173] [<ffffffff941c1fee>] async_run_entry_fn+0xfe/0x610
[ 3.284492] [<ffffffff941a8954>] ? pwq_dec_nr_in_flight+0x124/0x2a0
[ 3.284876] [<ffffffff941d1770>] ? preempt_count_add+0x130/0x160
[ 3.285207] [<ffffffff941a9a84>] process_one_work+0x544/0x12d0
[ 3.285526] [<ffffffff941aa8e9>] worker_thread+0xd9/0x12f0
[ 3.285844] [<ffffffff941aa810>] ? process_one_work+0x12d0/0x12d0
[ 3.286182] [<ffffffff941bb365>] kthread+0x1c5/0x260
[ 3.286443] [<ffffffff940855cd>] ? __switch_to+0x88d/0x1430
[ 3.286745] [<ffffffff941bb1a0>] ? kthread_worker_fn+0x5a0/0x5a0
[ 3.287085] [<ffffffff956dde9f>] ret_from_fork+0x1f/0x40
[ 3.287368] [<ffffffff941bb1a0>] ? kthread_worker_fn+0x5a0/0x5a0
[ 3.287697] Object at ffff880254d8bb80, in cache kmalloc-2048 size: 2048
[ 3.288064] Allocated:
[ 3.288147] PID = 27
[ 3.288218] [<ffffffff940b27ab>] save_stack_trace+0x2b/0x50
[ 3.288531] [<ffffffff9459f246>] save_stack+0x46/0xd0
[ 3.288806] [<ffffffff9459f4bd>] kasan_kmalloc+0xad/0xe0
[ 3.289098] [<ffffffff9459c07e>] __kmalloc+0x13e/0x250
[ 3.289378] [<ffffffff95078e5a>] scsi_alloc_sdev+0xea/0xcf0
[ 3.289701] [<ffffffff9507de76>] __scsi_scan_target+0xa06/0xdf0
[ 3.290034] [<ffffffff9507e505>] scsi_scan_channel+0x105/0x160
[ 3.290362] [<ffffffff9507e8a2>] scsi_scan_host_selected+0x212/0x2f0
[ 3.290724] [<ffffffff9507eb3c>] do_scsi_scan_host+0x1bc/0x250
[ 3.291055] [<ffffffff9507efc1>] do_scan_async+0x41/0x450
[ 3.291354] [<ffffffff941c1fee>] async_run_entry_fn+0xfe/0x610
[ 3.291695] [<ffffffff941a9a84>] process_one_work+0x544/0x12d0
[ 3.292022] [<ffffffff941aa8e9>] worker_thread+0xd9/0x12f0
[ 3.292325] [<ffffffff941bb365>] kthread+0x1c5/0x260
[ 3.292594] [<ffffffff956dde9f>] ret_from_fork+0x1f/0x40
[ 3.292886] Freed:
[ 3.292945] PID = 27
[ 3.293016] [<ffffffff940b27ab>] save_stack_trace+0x2b/0x50
[ 3.293327] [<ffffffff9459f246>] save_stack+0x46/0xd0
[ 3.293600] [<ffffffff9459fa61>] kasan_slab_free+0x71/0xb0
[ 3.293916] [<ffffffff9459bac2>] kfree+0xa2/0x1f0
[ 3.294168] [<ffffffff9508158a>] scsi_device_dev_release_usercontext+0x50a/0x730
[ 3.294598] [<ffffffff941ace9a>] execute_in_process_context+0xda/0x130
[ 3.294974] [<ffffffff9508107c>] scsi_device_dev_release+0x1c/0x20
[ 3.295322] [<ffffffff94f566f6>] device_release+0x76/0x1e0
[ 3.295626] [<ffffffff94bc2db7>] kobject_release+0x107/0x370
[ 3.295942] [<ffffffff94bc29ce>] kobject_put+0x4e/0xa0
[ 3.296222] [<ffffffff94f56e17>] put_device+0x17/0x20
[ 3.296497] [<ffffffff9505201c>] scsi_device_put+0x7c/0xa0
[ 3.296801] [<ffffffff9507e1bc>] __scsi_scan_target+0xd4c/0xdf0
[ 3.297132] [<ffffffff9507e505>] scsi_scan_channel+0x105/0x160
[ 3.297458] [<ffffffff9507e8a2>] scsi_scan_host_selected+0x212/0x2f0
[ 3.297829] [<ffffffff9507eb3c>] do_scsi_scan_host+0x1bc/0x250
[ 3.298156] [<ffffffff9507efc1>] do_scan_async+0x41/0x450
[ 3.298453] [<ffffffff941c1fee>] async_run_entry_fn+0xfe/0x610
[ 3.298777] [<ffffffff941a9a84>] process_one_work+0x544/0x12d0
[ 3.299105] [<ffffffff941aa8e9>] worker_thread+0xd9/0x12f0
[ 3.299408] [<ffffffff941bb365>] kthread+0x1c5/0x260
[ 3.299676] [<ffffffff956dde9f>] ret_from_fork+0x1f/0x40
[ 3.299967] Memory state around the buggy address:
[ 3.300209] ffff880254d8c200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 3.300608] ffff880254d8c280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 3.300986] >ffff880254d8c300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 3.301408] ^
[ 3.301550] ffff880254d8c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 3.301987] ffff880254d8c400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 3.302396]
==================================================================
Cc: Christoph Hellwig <hch@lst.de>
Cc: stable@vger.kernel.org
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 4a2ede59ea828df9616e3c7619252875912ea872
Author: Jiri Slaby <jslaby@suse.cz>
Date: Mon Oct 3 10:58:28 2016 +0200
mmc: core: Annotate cmd_hdr as __le32
[ Upstream commit 3f2d26643595973e835e8356ea90c7c15cb1b0f1 ]
Commit f68381a70bb2 (mmc: block: fix packed command header endianness)
correctly fixed endianness handling of packed_cmd_hdr in
mmc_blk_packed_hdr_wrq_prep.
But now, sparse complains about incorrect types:
drivers/mmc/card/block.c:1613:27: sparse: incorrect type in assignment (different base types)
drivers/mmc/card/block.c:1613:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/mmc/card/block.c:1613:27: got restricted __le32 [usertype] <noident>
...
So annotate cmd_hdr properly using __le32 to make everyone happy.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Fixes: f68381a70bb2 (mmc: block: fix packed command header endianness)
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 69335972b1c1c9bd7597fc6080b6eb1bd3fbf774
Author: Eric Dumazet <edumazet@google.com>
Date: Wed Dec 30 08:51:12 2015 -0500
udp: properly support MSG_PEEK with truncated buffers
[ Upstream commit 197c949e7798fbf28cfadc69d9ca0c2abbf93191 ]
Backport of this upstream commit into stable kernels :
89c22d8c3b27 ("net: Fix skb csum races when peeking")
exposed a bug in udp stack vs MSG_PEEK support, when user provides
a buffer smaller than skb payload.
In this case,
skb_copy_and_csum_datagram_iovec(skb, sizeof(struct udphdr),
msg->msg_iov);
returns -EFAULT.
This bug does not happen in upstream kernels since Al Viro did a great
job to replace this into :
skb_copy_and_csum_datagram_msg(skb, sizeof(struct udphdr), msg);
This variant is safe vs short buffers.
For the time being, instead reverting Herbert Xu patch and add back
skb->ip_summed invalid changes, simply store the result of
udp_lib_checksum_complete() so that we avoid computing the checksum a
second time, and avoid the problematic
skb_copy_and_csum_datagram_iovec() call.
This patch can be applied on recent kernels as it avoids a double
checksumming, then backported to stable kernels as a bug fix.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>