commit 8576fa45c10e665bb72931a31461c7310f3c5494 Author: Sasha Levin Date: Tue Nov 29 11:34:50 2016 -0500 Linux 4.1.36 Signed-off-by: Sasha Levin commit 39f99860357cd710c2c952e16efbd534313acde4 Author: Sebastian Andrzej Siewior 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 Signed-off-by: Michal Marek Signed-off-by: Sasha Levin commit bf5d3d296abf509169ca673423c76b000bcf1085 Author: Stefan Richter 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 Signed-off-by: Sasha Levin commit c604dec3d5a695efed5492fc463ef70ef8010bbe Author: Stefan Richter 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 Reviewed-by: Eyal Itkin Fixes: CVE 2016-8633 Cc: stable@vger.kernel.org Signed-off-by: Stefan Richter Signed-off-by: Sasha Levin commit 9fe6256c0020a220fdbd096886a40de1a5a73388 Author: John David Anglin 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: Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 83a474ed7003b7065d3816d84dd0168f02a0ee94 Author: Miklos Szeredi 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 Cc: Signed-off-by: Sasha Levin commit c0b309f18b0144aca3a0abc7fbaa5ab0dc82394c Author: Matt Redfearn 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 Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 4fe9ae4d3fcf35b089721ed9d4df163b2d1d1439 Author: NeilBrown 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 Signed-off-by: NeilBrown Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin commit e1e5cab9b43c37c8069519cb671baa9ff986466a Author: NeilBrown 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 Signed-off-by: Sasha Levin commit 97d53c4d89e0f2833b932b8e3f0c2d7312a55b52 Author: Ching Huang 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: Signed-off-by: Ching Huang Reported-by: Tomas Henzl Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit d207c6603fc6be402f6e75181c9dae0bfd585e56 Author: Ewan D. Milne 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: Signed-off-by: Ewan D. Milne Reviewed-by: Laurence Oberman Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 169eb57c9e8da65b3e963960feb1f16b13fecff9 Author: Alex Deucher 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 Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c1593e5dcc2a9faac1fa622dde905d6e81d5e0ef Author: Ville Syrjälä Date: Wed Oct 26 12:05:55 2016 +0300 drm/dp/mst: Check peer device type before attempting EDID read [ Upstream commit 4da5caa6a6f82cda3193bca855235b87debf78bd ] Only certain types of pdts have the DDC bus registered, so check for that before we attempt the EDID read. Othwewise we risk playing around with an i2c adapter that doesn't actually exist. Cc: stable@vger.kernel.org Cc: Carlos Santa Cc: Kirill A. Shutemov Tested-by: Carlos Santa Tested-by: Kirill A. Shutemov Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97666 Signed-off-by: Ville Syrjälä Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1477472755-15288-5-git-send-email-ville.syrjala@linux.intel.com Signed-off-by: Sasha Levin commit e5c6bbbcc7be9106e744c36b88d0464a8a3c2a16 Author: Dave Airlie Date: Thu Oct 1 16:28:25 2015 +1000 drm/dp/mst: add some defines for logical/physical ports [ Upstream commit ccf03d6995fa4b784f5b987726ba98f4859bf326 ] This just removes the magic number. Acked-by: Daniel Vetter Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit dadd5803301f1175861c3cf42aa8385fd71537a9 Author: Ville Syrjälä Date: Wed Oct 26 16:30:33 2016 +0300 drm/dp/mst: Clear port->pdt when tearing down the i2c adapter [ Upstream commit 36e3fa6a38e135e9478a2f75dec9bf6ff1e6480e ] The i2c adapter is only relevant for some peer device types, so let's clear the pdt if it's still the same as the old_pdt when we tear down the i2c adapter. I don't really like this design pattern of updating port->whatever before doing the accompanying changes and passing around old_whatever to figure stuff out. Would make much more sense to me to the pass the new value around and only update the port->whatever when things are consistent. But let's try to work with what we have right now. Quoting a follow-up from Ville: "And naturally I forgot to amend the commit message w.r.t. this guy [the change in drm_dp_destroy_port]. We don't really need to do this here, but I figured I'd try to be a bit more consistent by having it, just to avoid accidental mistakes if/when someone changes this stuff again later." v2: Clear port->pdt in the caller, if needed (Daniel) Cc: Daniel Vetter Cc: stable@vger.kernel.org Cc: Carlos Santa Cc: Kirill A. Shutemov Tested-by: Carlos Santa (v1) Tested-by: Kirill A. Shutemov (v1) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97666 Signed-off-by: Ville Syrjälä Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1477488633-16544-1-git-send-email-ville.syrjala@linux.intel.com Signed-off-by: Sasha Levin commit a2d4bd9c99cc8c1fae2a8200eaaff00c0ca9d6fc Author: James Hogan Date: Tue Oct 25 16:11:12 2016 +0100 KVM: MIPS: Precalculate MMIO load resume PC [ Upstream commit e1e575f6b026734be3b1f075e780e91ab08ca541 ] The advancing of the PC when completing an MMIO load is done before re-entering the guest, i.e. before restoring the guest ASID. However if the load is in a branch delay slot it may need to access guest code to read the prior branch instruction. This isn't safe in TLB mapped code at the moment, nor in the future when we'll access unmapped guest segments using direct user accessors too, as it could read the branch from host user memory instead. Therefore calculate the resume PC in advance while we're still in the right context and save it in the new vcpu->arch.io_pc (replacing the no longer needed vcpu->arch.pending_load_cause), and restore it on MMIO completion. Fixes: e685c689f3a8 ("KVM/MIPS32: Privileged instruction/target branch emulation.") Signed-off-by: James Hogan Cc: Paolo Bonzini Cc: "Radim Krčmář Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Cc: # 3.10.x- Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit b05ff0cb0dea33b12e803e5bf2bb66a382c8696b Author: James Hogan 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 Cc: Paolo Bonzini Cc: "Radim Krčmář Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Cc: # 3.10.x- Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 90a107c0b85b4b5b2ecfb9fa6b7a714d8bb349e8 Author: Lucas Stach 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 Signed-off-by: Lucas Stach Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 9a9a2373142ac2c6fd9df9d038eb929b919e30d7 Author: Kashyap Desai 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 Signed-off-by: Sumit Saxena Reviewed-by: Tomas Henzl Reviewed-by: Hannes Reinecke Reviewed-by: Ewan D. Milne Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1b15bd7396897e2f8018f863dd18006092a4deb0 Author: Michel Dänzer Date: Mon Oct 24 16:52:20 2016 +0900 Revert "drm/radeon: fix DP link training issue with second 4K monitor" [ Upstream commit 9dc79965b21967caebde575f5f5d8bf1aa2c23ab ] This reverts commit 1a738347df2ee4977459a8776fe2c62196bdcb1b. It caused at least some Kaveri laptops to incorrectly report DisplayPort connectors as connected. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97857 Cc: stable@vger.kernel.org Reviewed-by: Alex Deucher Signed-off-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5bc028b10d041cb5340e5c87d4bc22e6b9e452d4 Author: Sasha Levin 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 Signed-off-by: Segher Boessenkool Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 00a4335dfaa5bc7aa632f1122dc304b7c98b231f Author: Tom St Denis 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 Reviewed-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 469bc68e081c25d65f0ce39ecb00ab8cca03a56b Author: Alex Deucher 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 Tested-by: Sonny Jiang Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 85a2af9f690a27c064cc94e5526d18fc0887104f Author: Johan Hovold 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 Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 0854ce492ec3b7bc0e147fdc0b7ad98c94d903fb Author: Patrick Scheuring 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 Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 0e9bbbdfe9f88ad383e8903866e2340490572735 Author: Takashi Iwai Date: Thu Dec 17 08:12:37 2015 +0100 ALSA: hda - Merge RIRB_PRE_DELAY into CTX_WORKAROUND caps [ Upstream commit ef85f299c74e6c5dd98ec0230183be33f4c2813d ] AZX_DCAPS_RIRB_PRE_DELAY is always tied with AZX_DCAPS_CTX_WORKAROUND, which is Creative's XFi specific. So, we can replace it and reduce one more bit free for DCAPS. Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 02426cf24407fc2f772f283777185cb5b66404cc Author: Johannes Berg 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 Signed-off-by: Sasha Levin commit f065a553f36eeb319ee64e894c44be7c22e3fe65 Author: Richard Weinberger Date: Fri Oct 28 11:49:03 2016 +0200 ubifs: Fix regression in ubifs_readdir() [ Upstream commit a00052a296e54205cf238c75bd98d17d5d02a6db ] Commit c83ed4c9dbb35 ("ubifs: Abort readdir upon error") broke overlayfs support because the fix exposed an internal error code to VFS. Reported-by: Peter Rosin Tested-by: Peter Rosin Reported-by: Ralph Sennhauser Tested-by: Ralph Sennhauser Fixes: c83ed4c9dbb35 ("ubifs: Abort readdir upon error") Cc: stable@vger.kernel.org Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 5fdb4fad291f6b460dd92f0a863360ce9428c029 Author: Gerald Schaefer 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 Signed-off-by: Frank Haverkamp Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 55a2f87cd5642a68b19c4bea8fdce8bf2a84228e Author: Alexander Polakov Date: Thu Oct 27 17:46:27 2016 -0700 mm/list_lru.c: avoid error-path NULL pointer deref [ Upstream commit 1bc11d70b5db7c6bb1414b283d7f09b1fe1ac0d0 ] As described in https://bugzilla.kernel.org/show_bug.cgi?id=177821: After some analysis it seems to be that the problem is in alloc_super(). In case list_lru_init_memcg() fails it goes into destroy_super(), which calls list_lru_destroy(). And in list_lru_init() we see that in case memcg_init_list_lru() fails, lru->node is freed, but not set NULL, which then leads list_lru_destroy() to believe it is initialized and call memcg_destroy_list_lru(). memcg_destroy_list_lru() in turn can access lru->node[i].memcg_lrus, which is NULL. [akpm@linux-foundation.org: add comment] Signed-off-by: Alexander Polakov Acked-by: Vladimir Davydov Cc: Al Viro Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 52e7b6bd8378b1b194ad35a27a185dffa6fb4066 Author: Chris Mason 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 cc: stable@vger.kernel.org # 3.15+ Signed-off-by: Chris Mason Signed-off-by: Sasha Levin commit 9f2d48f0745f921040df91bfe8fa7f0339cd7497 Author: Scot Doyle 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 Signed-off-by: Scot Doyle Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 93ec720c6f10712fc1c6f87a7412194c85b366b9 Author: Dmitry Vyukov 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 CC: David Rientjes Cc: One Thousand Gnomes Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: Peter Hurley Cc: linux-kernel@vger.kernel.org Cc: syzkaller@googlegroups.com Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ca963122cab2f2d09d4d63dffd6c61f8fe9e3b67 Author: Marcel Hasler 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 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 3dc8f1f0decb5f022b3be2cc98c7163a376556c9 Author: David Howells 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: [] dump_stack+0x63/0x84 [] panic+0xde/0x22a [] ? proc_keys_show+0x3ce/0x3d0 [] __stack_chk_fail+0x19/0x30 [] proc_keys_show+0x3ce/0x3d0 [] ? key_validate+0x50/0x50 [] ? key_default_cmp+0x20/0x20 [] seq_read+0x2cc/0x390 [] proc_reg_read+0x42/0x70 [] __vfs_read+0x37/0x150 [] ? security_file_permission+0xa0/0xc0 [] vfs_read+0x96/0x130 [] SyS_read+0x55/0xc0 [] entry_SYSCALL_64_fastpath+0x1a/0xa4 Reported-by: Ondrej Kozina Signed-off-by: David Howells Tested-by: Ondrej Kozina cc: stable@vger.kernel.org Signed-off-by: James Morris Signed-off-by: Sasha Levin commit 1f7ff6f7910efeb370e8382bfd15e8acb1dcf003 Author: Long Li 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 Signed-off-by: K. Y. Srinivasan CC: Stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9662d19bab684d86a09db80dabd2c7f17c6afe61 Author: Alexander Usyskin 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 Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a64291d578dd900b3b0cf40ea7be70185ad06959 Author: Arve Hjønnevåg Date: Mon Oct 24 15:20:30 2016 +0200 ANDROID: binder: Clear binder and cookie when setting handle in flat binder struct [ Upstream commit 4afb604e2d14d429ac9e1fd84b952602853b2df5 ] Prevents leaking pointers between processes Signed-off-by: Arve Hjønnevåg Signed-off-by: Martijn Coenen Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 11924cba404d4bedcdfda6a2ddda3120890efa8b Author: Arve Hjønnevåg Date: Mon Oct 24 15:20:29 2016 +0200 ANDROID: binder: Add strong ref checks [ Upstream commit 0a3ffab93fe52530602fe47cd74802cffdb19c05 ] Prevent using a binder_ref with only weak references where a strong reference is required. Signed-off-by: Arve Hjønnevåg Signed-off-by: Martijn Coenen Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 39709c84807f6bc5c56089223c4dbfeaff33065c Author: tang.junhui 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 Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit c91812c8ef760de46c1c40c60b13ee560b83a1c0 Author: Bryan Paluch 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 Acked-by: Alan Stern Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 51b231bd1a953271cc454452828b46bf82630db7 Author: Will Deacon Date: Thu Sep 29 12:37:01 2016 +0100 arm64: KVM: Take S1 walks into account when determining S2 write faults [ Upstream commit 60e21a0ef54cd836b9eb22c7cb396989b5b11648 ] The WnR bit in the HSR/ESR_EL2 indicates whether a data abort was generated by a read or a write instruction. For stage 2 data aborts generated by a stage 1 translation table walk (i.e. the actual page table access faults at EL2), the WnR bit therefore reports whether the instruction generating the walk was a load or a store, *not* whether the page table walker was reading or writing the entry. For page tables marked as read-only at stage 2 (e.g. due to KSM merging them with the tables from another guest), this could result in livelock, where a page table walk generated by a load instruction attempts to set the access flag in the stage 1 descriptor, but fails to trigger CoW in the host since only a read fault is reported. This patch modifies the arm64 kvm_vcpu_dabt_iswrite function to take into account stage 2 faults in stage 1 walks. Since DBM cannot be disabled at EL2 for CPUs that implement it, we assume that these faults are always causes by writes, avoiding the livelock situation at the expense of occasional, spurious CoWs. We could, in theory, do a bit better by checking the guest TCR configuration and inspecting the page table to see why the PTE faulted. However, I doubt this is measurable in practice, and the threat of livelock is real. Cc: Cc: Julien Grall Reviewed-by: Marc Zyngier Reviewed-by: Christoffer Dall Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit bb21e029506485e4e62aa2a93c432b769c1397de Author: Marc Zyngier Date: Fri Jan 29 15:01:28 2016 +0000 arm/arm64: KVM: Handle out-of-RAM cache maintenance as a NOP [ Upstream commit 57c841f131ef295b583365d2fddd6b0d16e82c10 ] So far, our handling of cache maintenance by VA has been pretty simple: Either the access is in the guest RAM and generates a S2 fault, which results in the page being mapped RW, or we go down the io_mem_abort() path, and nuke the guest. The first one is fine, but the second one is extremely weird. Treating the CM as an I/O is wrong, and nothing in the ARM ARM indicates that we should generate a fault for something that cannot end-up in the cache anyway (even if the guest maps it, it will keep on faulting at stage-2 for emulation). So let's just skip this instruction, and let the guest get away with it. Reviewed-by: Christoffer Dall Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 7fbfac87fbf5b452c7c9ba3c4a566a41dca032e2 Author: Johan Hovold 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 # 3.11 Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 605a6960617f1b7be08dc721c559dc00a27015ad Author: Mathias Nyman Date: Thu Oct 20 18:09:19 2016 +0300 xhci: workaround for hosts missing CAS bit [ Upstream commit 346e99736c3ce328fd42d678343b70243aca5f36 ] If a device is unplugged and replugged during Sx system suspend some Intel xHC hosts will overwrite the CAS (Cold attach status) flag and no device connection is noticed in resume. A device in this state can be identified in resume if its link state is in polling or compliance mode, and the current connect status is 0. A device in this state needs to be warm reset. Intel 100/c230 series PCH specification update Doc #332692-006 Errata #8 Observed on Cherryview and Apollolake as they go into compliance mode if LFPS times out during polling, and re-plugged devices are not discovered at resume. Signed-off-by: Mathias Nyman CC: Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c23a6dce114713b5872326670d064ced8d4ab33c Author: Mathias Nyman 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 CC: Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4c17f91bb3705c7ceb6d0f8c9e85e64458459c6c Author: Jiri Slaby Date: Thu Oct 13 17:45:20 2016 +0200 kvm: x86: memset whole irq_eoi [ Upstream commit 8678654e3c7ad7b0f4beb03fa89691279cba71f9 ] gcc 7 warns: arch/x86/kvm/ioapic.c: In function 'kvm_ioapic_reset': arch/x86/kvm/ioapic.c:597:2: warning: 'memset' used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size] And it is right. Memset whole array using sizeof operator. Signed-off-by: Jiri Slaby Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Thomas Gleixner Cc: Ingo Molnar Cc: H. Peter Anvin Cc: x86@kernel.org Cc: kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Reviewed-by: Paolo Bonzini [Added x86 subject tag] Signed-off-by: Radim Krčmář Signed-off-by: Sasha Levin commit 9c5e89d59d56e5c2d8f329a5f675876803dbe915 Author: Darrick J. Wong 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: Signed-off-by: Darrick J. Wong Reviewed-by: Eric Sandeen Signed-off-by: Dave Chinner Signed-off-by: Sasha Levin commit d1375c3e4f2e89d36f7d6869cc1745bdc1c399a0 Author: Dinesh Israni 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 Tested-by: Nixon Vincent Cc: Nixon Vincent Tested-by: Dinesh Israni Signed-off-by: Dinesh Israni Cc: Dinesh Israni Cc: stable@vger.kernel.org # 3.14+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit ac49951623e11d78c4772d88ec54584bd4840e4c Author: Nicholas Bellinger Date: Tue Oct 4 16:37:05 2016 -0700 target: Re-add missing SCF_ACK_KREF assignment in v4.1.y [ Upstream commit 527268df31e57cf2b6d417198717c6d6afdb1e3e ] This patch fixes a regression in >= v4.1.y code where the original SCF_ACK_KREF assignment in target_get_sess_cmd() was dropped upstream in commit 054922bb, but the series for addressing TMR ABORT_TASK + LUN_RESET with fabric session reinstatement in commit febe562c20 still depends on this code in transport_cmd_finish_abort(). The regression manifests itself as a se_cmd->cmd_kref +1 leak, where ABORT_TASK + LUN_RESET can hang indefinately for a specific I_T session for drivers using SCF_ACK_KREF, resulting in hung kthreads. This patch has been verified with v4.1.y code. Reported-by: Vaibhav Tandon Tested-by: Vaibhav Tandon Cc: Vaibhav Tandon Cc: stable@vger.kernel.org # 4.1+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit eaf55207fe3b47951939d70a90c741ee8e789281 Author: Richard Weinberger Date: Wed Oct 19 12:43:07 2016 +0200 ubifs: Abort readdir upon error [ Upstream commit c83ed4c9dbb358b9e7707486e167e940d48bfeed ] If UBIFS is facing an error while walking a directory, it reports this error and ubifs_readdir() returns the error code. But the VFS readdir logic does not make the getdents system call fail in all cases. When the readdir cursor indicates that more entries are present, the system call will just return and the libc wrapper will try again since it also knows that more entries are present. This causes the libc wrapper to busy loop for ever when a directory is corrupted on UBIFS. A common approach do deal with corrupted directory entries is skipping them by setting the cursor to the next entry. On UBIFS this approach is not possible since we cannot compute the next directory entry cursor position without reading the current entry. So all we can do is setting the cursor to the "no more entries" position and make getdents exit. Cc: stable@vger.kernel.org Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit b9ce8700a2e38f36b8814e886ce2e5c8e9fc596f Author: Richard Weinberger Date: Mon Oct 12 23:35:36 2015 +0200 UBIFS: Fix possible memory leak in ubifs_readdir() [ Upstream commit aeeb14f763917ccf639a602cfbeee6957fd944a2 ] If ubifs_tnc_next_ent() returns something else than -ENOENT we leak file->private_data. Signed-off-by: Richard Weinberger Reviewed-by: David Gstir Signed-off-by: Sasha Levin commit cad1ca2a9485333c04581c69bbbe52fbd410d9ec Author: Richard Weinberger 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 Signed-off-by: Sasha Levin commit dfeb7e4f30e9179098fd8344f29478c6f3d1bb14 Author: Will Deacon Date: Mon Jul 4 17:44:48 2016 +0100 arm64: percpu: rewrite ll/sc loops in assembly [ Upstream commit 1e6e57d9b34a9075d5f9e2048ea7b09756590d11 ] Writing the outer loop of an LL/SC sequence using do {...} while constructs potentially allows the compiler to hoist memory accesses between the STXR and the branch back to the LDXR. On CPUs that do not guarantee forward progress of LL/SC loops when faced with memory accesses to the same ERG (up to 2k) between the failed STXR and the branch back, we may end up livelocking. This patch avoids this issue in our percpu atomics by rewriting the outer loop as part of the LL/SC inline assembly block. Cc: Fixes: f97fc810798c ("arm64: percpu: Implement this_cpu operations") Reviewed-by: Mark Rutland Tested-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 3c9c01324032e33d888f699bb694f7b4abcfb7d0 Author: Frederic Barrat 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 Acked-by: Ian Munsie Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit c1f5e5f89b9916333efc1c9bcf9c648c192e072b Author: Jan Kara 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 Reported-by: Karel Zak Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit b15662c8e266a4c22da60bd0a8a1adb655a8c3a6 Author: Vladimir Murzin Date: Mon Oct 17 16:00:46 2016 +0100 irqchip/gic-v3-its: Fix entry size mask for GITS_BASER [ Upstream commit 9224eb77e63f70f16c0b6b7a20ca7d395f3bc077 ] Entry Size in GITS_BASER occupies 5 bits [52:48], but we mask out 8 bits. Fixes: cc2d3216f53c ("irqchip: GICv3: ITS command queue") Cc: stable@vger.kernel.org Signed-off-by: Vladimir Murzin Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit af17243fc1b4d88e8c96f34852e765c77ac296d0 Author: Marc Zyngier Date: Mon Oct 17 13:47:34 2016 +0100 arm64: kernel: Init MDCR_EL2 even in the absence of a PMU [ Upstream commit 850540351bb1a4fa5f192e5ce55b89928cc57f42 ] Commit f436b2ac90a0 ("arm64: kernel: fix architected PMU registers unconditional access") made sure we wouldn't access unimplemented PMU registers, but also left MDCR_EL2 uninitialized in that case, leading to trap bits being potentially left set. Make sure we always write something in that register. Fixes: f436b2ac90a0 ("arm64: kernel: fix architected PMU registers unconditional access") Cc: Lorenzo Pieralisi Cc: Will Deacon Cc: Signed-off-by: Marc Zyngier Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit c911b72eaff1331b3810b74283970656643088e5 Author: Stefan Tauner 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 Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 59eabe8bb60f849151362bffcf038cfa6495925b Author: Ulf Hansson 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: Cc: Ritesh Raj Sarraf Cc: Alan Stern Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 86559fc191ca99f6345c21094ca6c573d2a6be70 Author: Alan Stern 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 Tested-by: Ritesh Raj Sarraf Signed-off-by: Alan Stern Cc: Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit a89634cf709b12cf1e03f730636ab976b84f8481 Author: Ulf Hansson 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 Tested-by: Ritesh Raj Sarraf Cc: Cc: Alan Stern Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit e79c2f2f7b30ac550a22b4cbe7bbf7267c035a57 Author: Ulf Hansson 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 Cc: Cc: Alan Stern Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit f125e7f2285c2ec9a9f6039073e95ab65700fc74 Author: Haibo Chen 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 Cc: stable@vger.kernel.org # v3.15+ Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 517052446f36f78b13502ccafc8884b6339643d2 Author: Felipe Balbi 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: Reported-by: Ville Syrjälä Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 66f38bf99faa0b30d7486906738da66b56fb7d80 Author: Nikolay Borisov Date: Mon Oct 10 15:38:18 2016 +0300 ceph: fix error handling in ceph_read_iter [ Upstream commit 0d7718f666be181fda1ba2d08f137d87c1419347 ] In case __ceph_do_getattr returns an error and the retry_op in ceph_read_iter is not READ_INLINE, then it's possible to invoke __free_page on a page which is NULL, this naturally leads to a crash. This can happen when, for example, a process waiting on a MDS reply receives sigterm. Fix this by explicitly checking whether the page is set or not. Cc: stable@vger.kernel.org # 3.19+ Signed-off-by: Nikolay Borisov Reviewed-by: Yan, Zheng Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 9e9ca450cd93936f0a40daf66ce45e93d0873088 Author: Dan Carpenter 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 Acked-by: Sudeep Holla Cc: Marc Zyngier Cc: kernel-janitors@vger.kernel.org Cc: Jason Cooper Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20161014072534.GA15168@mwanda Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit 88b6c9f4146af976bb4b9e12b137d520fdfc586e Author: Alex Deucher 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 Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit dcf4c1144f3af47e451773d4f989db255c46ff11 Author: Taesoo Kim 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 Signed-off-by: Theodore Ts'o Reviewed-by: Andreas Dilger Fixes: 6e4862a5bb9d12be87e4ea5d9a60836ebed71d28 Cc: stable@vger.kernel.org # 3.14+ Signed-off-by: Sasha Levin commit a3da255ead60b6c3208eba3abfa536f32aa58f3a Author: Ming Lei 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] [] dump_stack+0x65/0x84 [ 3.278797] [] kasan_object_err+0x21/0x70 [ 3.279063] device: 'psaux': device_add [ 3.279616] [] kasan_report_error+0x205/0x500 [ 3.279651] PM: Adding info for No Bus:psaux [ 3.280202] [] ? kfree_const+0x22/0x30 [ 3.280486] [] ? kobject_release+0x119/0x370 [ 3.280805] [] __asan_report_load4_noabort+0x43/0x50 [ 3.281170] [] ? __scsi_scan_target+0xd87/0xdf0 [ 3.281506] [] __scsi_scan_target+0xd87/0xdf0 [ 3.281848] [] ? scsi_add_device+0x30/0x30 [ 3.282156] [] ? pm_runtime_autosuspend_expiration+0x60/0x60 [ 3.282570] [] ? _raw_spin_lock+0x17/0x40 [ 3.282880] [] scsi_scan_channel+0x105/0x160 [ 3.283200] [] scsi_scan_host_selected+0x212/0x2f0 [ 3.283563] [] do_scsi_scan_host+0x1bc/0x250 [ 3.283882] [] do_scan_async+0x41/0x450 [ 3.284173] [] async_run_entry_fn+0xfe/0x610 [ 3.284492] [] ? pwq_dec_nr_in_flight+0x124/0x2a0 [ 3.284876] [] ? preempt_count_add+0x130/0x160 [ 3.285207] [] process_one_work+0x544/0x12d0 [ 3.285526] [] worker_thread+0xd9/0x12f0 [ 3.285844] [] ? process_one_work+0x12d0/0x12d0 [ 3.286182] [] kthread+0x1c5/0x260 [ 3.286443] [] ? __switch_to+0x88d/0x1430 [ 3.286745] [] ? kthread_worker_fn+0x5a0/0x5a0 [ 3.287085] [] ret_from_fork+0x1f/0x40 [ 3.287368] [] ? 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] [] save_stack_trace+0x2b/0x50 [ 3.288531] [] save_stack+0x46/0xd0 [ 3.288806] [] kasan_kmalloc+0xad/0xe0 [ 3.289098] [] __kmalloc+0x13e/0x250 [ 3.289378] [] scsi_alloc_sdev+0xea/0xcf0 [ 3.289701] [] __scsi_scan_target+0xa06/0xdf0 [ 3.290034] [] scsi_scan_channel+0x105/0x160 [ 3.290362] [] scsi_scan_host_selected+0x212/0x2f0 [ 3.290724] [] do_scsi_scan_host+0x1bc/0x250 [ 3.291055] [] do_scan_async+0x41/0x450 [ 3.291354] [] async_run_entry_fn+0xfe/0x610 [ 3.291695] [] process_one_work+0x544/0x12d0 [ 3.292022] [] worker_thread+0xd9/0x12f0 [ 3.292325] [] kthread+0x1c5/0x260 [ 3.292594] [] ret_from_fork+0x1f/0x40 [ 3.292886] Freed: [ 3.292945] PID = 27 [ 3.293016] [] save_stack_trace+0x2b/0x50 [ 3.293327] [] save_stack+0x46/0xd0 [ 3.293600] [] kasan_slab_free+0x71/0xb0 [ 3.293916] [] kfree+0xa2/0x1f0 [ 3.294168] [] scsi_device_dev_release_usercontext+0x50a/0x730 [ 3.294598] [] execute_in_process_context+0xda/0x130 [ 3.294974] [] scsi_device_dev_release+0x1c/0x20 [ 3.295322] [] device_release+0x76/0x1e0 [ 3.295626] [] kobject_release+0x107/0x370 [ 3.295942] [] kobject_put+0x4e/0xa0 [ 3.296222] [] put_device+0x17/0x20 [ 3.296497] [] scsi_device_put+0x7c/0xa0 [ 3.296801] [] __scsi_scan_target+0xd4c/0xdf0 [ 3.297132] [] scsi_scan_channel+0x105/0x160 [ 3.297458] [] scsi_scan_host_selected+0x212/0x2f0 [ 3.297829] [] do_scsi_scan_host+0x1bc/0x250 [ 3.298156] [] do_scan_async+0x41/0x450 [ 3.298453] [] async_run_entry_fn+0xfe/0x610 [ 3.298777] [] process_one_work+0x544/0x12d0 [ 3.299105] [] worker_thread+0xd9/0x12f0 [ 3.299408] [] kthread+0x1c5/0x260 [ 3.299676] [] 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 Cc: stable@vger.kernel.org Signed-off-by: Ming Lei Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8df981058e4f4714381df12f6bec495ebc86e807 Author: Jiri Slaby 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] drivers/mmc/card/block.c:1613:27: got restricted __le32 [usertype] ... So annotate cmd_hdr properly using __le32 to make everyone happy. Signed-off-by: Jiri Slaby Fixes: f68381a70bb2 (mmc: block: fix packed command header endianness) Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 7ea3d2e9c6aa73bc07d537ab4574d18bcfe2f680 Author: Tony Luck Date: Wed Feb 17 10:20:12 2016 -0800 x86/mm: Expand the exception table logic to allow new handling options [ Upstream commit 548acf19234dbda5a52d5a8e7e205af46e9da840 ] Huge amounts of help from Andy Lutomirski and Borislav Petkov to produce this. Andy provided the inspiration to add classes to the exception table with a clever bit-squeezing trick, Boris pointed out how much cleaner it would all be if we just had a new field. Linus Torvalds blessed the expansion with: ' I'd rather not be clever in order to save just a tiny amount of space in the exception table, which isn't really criticial for anybody. ' The third field is another relative function pointer, this one to a handler that executes the actions. We start out with three handlers: 1: Legacy - just jumps the to fixup IP 2: Fault - provide the trap number in %ax to the fixup code 3: Cleaned up legacy for the uaccess error hack Signed-off-by: Tony Luck Reviewed-by: Borislav Petkov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/f6af78fcbd348cf4939875cfda9c19689b5e50b8.1455732970.git.tony.luck@intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin