commit 3cf02960bc4def449050e7a65802611f550e20fb Author: Greg Kroah-Hartman Date: Fri Oct 28 03:51:31 2016 -0400 Linux 4.8.5 commit 7979d3c66d58e8926888eae2f2dde44a7a135a14 Author: Nicholas Bellinger Date: Sun Oct 16 00:27:42 2016 -0700 Revert "target: Fix residual overflow handling in target_complete_cmd_with_length" commit 61f36166c245e563c7a2b624f4c78c5ce0f680d6 upstream. This reverts commit c1ccbfe0311e2380a6d2dcb0714b36904f5d586f. Reverting this patch, as it incorrectly assumes the additional length for INQUIRY in target_complete_cmd_with_length() is SCSI allocation length, which breaks existing user-space code when SCSI allocation length is smaller than additional length. root@scsi-mq:~# sg_inq --len=4 -vvvv /dev/sdb found bsg_major=253 open /dev/sdb with flags=0x800 inquiry cdb: 12 00 00 00 04 00 duration=0 ms inquiry: pass-through requested 4 bytes (data-in) but got -28 bytes inquiry: pass-through can't get negative bytes, say it got none inquiry: got too few bytes (0) INQUIRY resid (32) should never exceed requested len=4 inquiry: failed requesting 4 byte response: Malformed response to SCSI command [resid=32] AFAICT the original change was not to address a specific host issue, so go ahead and revert to original logic for now. Cc: Douglas Gilbert Cc: Martin K. Petersen Cc: Sumit Rai Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit c24cc97368adc7bc708188f0e5652447b61117c5 Author: Dinesh Israni Date: Mon Oct 10 20:22:03 2016 -0700 target: Don't override EXTENDED_COPY xcopy_pt_cmd SCSI status code commit 926317de33998c112c5510301868ea9aa34097e2 upstream. 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 Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 1f0b8fc27f1cc41765bfca9a0fc977e7b7c95137 Author: Nicholas Bellinger Date: Sat Oct 8 17:26:44 2016 -0700 target: Make EXTENDED_COPY 0xe4 failure return COPY TARGET DEVICE NOT REACHABLE commit 449a137846c84829a328757cd21fd9ca65c08519 upstream. This patch addresses a bug where EXTENDED_COPY across multiple LUNs results in a CHECK_CONDITION when the source + destination are not located on the same physical node. ESX Host environments expect sense COPY_ABORTED w/ COPY TARGET DEVICE NOT REACHABLE to be returned when this occurs, in order to signal fallback to local copy method. As described in section 6.3.3 of spc4r22: "If it is not possible to complete processing of a segment because the copy manager is unable to establish communications with a copy target device, because the copy target device does not respond to INQUIRY, or because the data returned in response to INQUIRY indicates an unsupported logical unit, then the EXTENDED COPY command shall be terminated with CHECK CONDITION status, with the sense key set to COPY ABORTED, and the additional sense code set to COPY TARGET DEVICE NOT REACHABLE." Tested on v4.1.y with ESX v5.5u2+ with BlockCopy across multiple nodes. Reported-by: Nixon Vincent Tested-by: Nixon Vincent Cc: Nixon Vincent Tested-by: Dinesh Israni Signed-off-by: Dinesh Israni Cc: Dinesh Israni Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit cb5fbb200a481021365438cfdb85fd9de6d2abba Author: Nicholas Bellinger Date: Tue Oct 4 16:37:05 2016 -0700 target: Re-add missing SCF_ACK_KREF assignment in v4.1.y commit 527268df31e57cf2b6d417198717c6d6afdb1e3e upstream. 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 Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 57339009db54879f240c525a79ef86874a9356a6 Author: Hannes Reinecke Date: Mon Aug 22 10:54:11 2016 +0200 target/tcm_fc: use CPU affinity for responses commit 1ba0158fa66b5b2c597a748f87be1650c9960ccc upstream. The libfc stack assigns exchange IDs based on the CPU the request was received on, so we need to send the responses via the same CPU. Otherwise the send logic gets confuses and responses will be delayed, causing exchange timeouts on the initiator side. Signed-off-by: Hannes Reinecke Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit e435e0e30773b2817921edad74de9f8e8568d567 Author: Richard Weinberger Date: Tue Sep 20 10:08:30 2016 +0200 ubifs: Fix xattr_names length in exit paths commit 843741c5778398ea67055067f4cc65ae6c80ca0e upstream. When the operation fails we also have to undo the changes we made to ->xattr_names. Otherwise listxattr() will report wrong lengths. Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 58f620cf12494820c7f206abadb0096abc72e2e0 Author: Taesoo Kim Date: Wed Oct 12 23:19:18 2016 -0400 jbd2: fix incorrect unlock on j_list_lock commit 559cce698eaf4ccecb2213b2519ea3a0413e5155 upstream. 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 Signed-off-by: Greg Kroah-Hartman commit 224c1a195ed9534fd88d54af8aff24080249ddf9 Author: Eric Biggers Date: Wed Oct 12 23:24:51 2016 -0400 ext4: do not advertise encryption support when disabled commit c4704a4fbe834eee4109ca064131d440941f6235 upstream. The sysfs file /sys/fs/ext4/features/encryption was present on kernels compiled with CONFIG_EXT4_FS_ENCRYPTION=n. This was misleading because such kernels do not actually support ext4 encryption. Therefore, only provide this file on kernels compiled with CONFIG_EXT4_FS_ENCRYPTION=y. Note: since the ext4 feature files are all hardcoded to have a contents of "supported", it really is the presence or absence of the file that is significant, not the contents (and this change reflects that). Signed-off-by: Eric Biggers Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit deb197e9992f4b8d0af491b062fff602c68eaff3 Author: Eric Biggers Date: Sat Oct 15 09:48:50 2016 -0400 fscrypto: lock inode while setting encryption policy commit 8906a8223ad4909b391c5628f7991ebceda30e52 upstream. i_rwsem needs to be acquired while setting an encryption policy so that concurrent calls to FS_IOC_SET_ENCRYPTION_POLICY are correctly serialized (especially the ->get_context() + ->set_context() pair), and so that new files cannot be created in the directory during or after the ->empty_dir() check. Signed-off-by: Eric Biggers Signed-off-by: Theodore Ts'o Reviewed-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 8b722a45b3e2cc10dee3bb96e4fae0b2267607ce Author: Eric Biggers Date: Wed Oct 12 23:30:16 2016 -0400 fscrypto: make XTS tweak initialization endian-independent commit fb4454376df9d820d95452d71dd83da6971f9338 upstream. The XTS tweak (or IV) was initialized differently on little endian and big endian systems. Because the ciphertext depends on the XTS tweak, it was not possible to use an encrypted filesystem created by a little endian system on a big endian system and vice versa, even if they shared the same PAGE_SIZE. Fix this by always using little endian. This will break hypothetical big endian users of ext4 or f2fs encryption. However, all users we are aware of are little endian, and it's believed that "real" big endian users are unlikely to exist yet. So this might as well be fixed now before it's too late. Signed-off-by: Eric Biggers Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 628ab14b21e2f2114d0509fe9abe27abb2630f91 Author: Christian Borntraeger Date: Wed Sep 28 16:18:47 2016 +0200 KVM: s390: reject invalid modes for runtime instrumentation commit a5efb6b6c99a3a6dc4330f51d8066f638bdea0ac upstream. Usually a validity intercept is a programming error of the host because of invalid entries in the state description. We can get a validity intercept if the mode of the runtime instrumentation control block is wrong. As the host does not know which modes are valid, this can be used by userspace to trigger a WARN. Instead of printing a WARN let's return an error to userspace as this can only happen if userspace provides a malformed initial value (e.g. on migration). The kernel should never warn on bogus input. Instead let's log it into the s390 debug feature. While at it, let's return -EINVAL for all validity intercepts as this will trigger an error in QEMU like error: kvm run failed Invalid argument PSW=mask 0404c00180000000 addr 000000000063c226 cc 00 R00=000000000000004f R01=0000000000000004 R02=0000000000760005 R03=000000007fe0a000 R04=000000000064ba2a R05=000000049db73dd0 R06=000000000082c4b0 R07=0000000000000041 R08=0000000000000002 R09=000003e0804042a8 R10=0000000496152c42 R11=000000007fe0afb0 [...] This will avoid an endless loop of validity intercepts. Fixes: c6e5f166373a ("KVM: s390: implement the RI support of guest") Acked-by: Fan Zhang Reviewed-by: Pierre Morel Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 9d74d0b0c6be7fbe8753d3c9524f65f61ce25ed0 Author: Ulf Hansson Date: Thu Sep 15 14:46:21 2016 +0200 mmc: rtsx_usb_sdmmc: Handle runtime PM while changing the led commit 4f48aa7a11bfed9502a7c85a5b68cd40ea827f73 upstream. 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: Alan Stern Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 2b54566081dff518adb8b8e10654017f98c51f6f Author: Ulf Hansson Date: Tue Sep 27 08:44:33 2016 -0700 mmc: rtsx_usb_sdmmc: Avoid keeping the device runtime resumed when unused commit 31cf742f515c275d22843c4c756e048d2b6d716c upstream. 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: Alan Stern Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 509424fd0cb9ce1561b06ab7b4d74a61d602cde9 Author: Shawn Lin Date: Fri Sep 30 14:18:58 2016 +0800 mmc: core: switch to 1V8 or 1V2 for hs400es mode commit 1720d3545b772c49b2975eeb3b8f4d3f56dc2085 upstream. When introducing hs400es, I didn't notice that we haven't switched voltage to 1V2 or 1V8 for it. That happens to work as the first controller claiming to support hs400es, arasan(5.1), which is designed to only support 1V8. So the voltage is fixed to 1V8. But it actually is wrong, and will not fit for other host controllers. Let's fix it. Fixes: commit 81ac2af65793ecf ("mmc: core: implement enhanced strobe support") Signed-off-by: Shawn Lin Reviewed-by: Douglas Anderson Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 8573b7f65544294d93c1975b811bd0b21fcc57ca Author: Jiri Slaby Date: Mon Oct 3 10:58:28 2016 +0200 mmc: core: Annotate cmd_hdr as __le32 commit 3f2d26643595973e835e8356ea90c7c15cb1b0f1 upstream. 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) Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 389db4fefd642c9d03103cc5201d37ecbfc36222 Author: Frederic Barrat Date: Fri Jun 17 18:53:28 2016 +0200 powerpc/mm: Prevent unlikely crash in copro_calculate_slb() commit d2cf909cda5f8c5609cb7ed6cda816c3e15528c7 upstream. 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") Signed-off-by: Frederic Barrat Acked-by: Ian Munsie Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit d3f1ec54e3453e54463fcff5be36ec8ebc06de53 Author: Nikolay Borisov Date: Mon Oct 10 15:38:18 2016 +0300 ceph: fix error handling in ceph_read_iter commit 0d7718f666be181fda1ba2d08f137d87c1419347 upstream. 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. Signed-off-by: Nikolay Borisov Reviewed-by: Yan, Zheng Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit d08622e1f544a2cdc052a0c1f72feb9bd8b6dbae Author: Will Deacon Date: Thu Sep 29 12:37:01 2016 +0100 arm64: KVM: Take S1 walks into account when determining S2 write faults commit 60e21a0ef54cd836b9eb22c7cb396989b5b11648 upstream. 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: Julien Grall Reviewed-by: Marc Zyngier Reviewed-by: Christoffer Dall Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit ac591c10110bf1fb1da55dd7e2bda3adb8c713be Author: Andre Przywara Date: Wed Oct 19 14:40:54 2016 +0100 arm64: Cortex-A53 errata workaround: check for kernel addresses commit 87261d19046aeaeed8eb3d2793fde850ae1b5c9e upstream. Commit 7dd01aef0557 ("arm64: trap userspace "dc cvau" cache operation on errata-affected core") adds code to execute cache maintenance instructions in the kernel on behalf of userland on CPUs with certain ARM CPU errata. It turns out that the address hasn't been checked to be a valid user space address, allowing userland to clean cache lines in kernel space. Fix this by introducing an address check before executing the instructions on behalf of userland. Since the address doesn't come via a syscall parameter, we can't just reject tagged pointers and instead have to remove the tag when checking against the user address limit. Fixes: 7dd01aef0557 ("arm64: trap userspace "dc cvau" cache operation on errata-affected core") Reported-by: Kristina Martsenko Signed-off-by: Andre Przywara [will: rework commit message + replace access_ok with max_user_addr()] Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 32c0a66fad76d8dc6b83ed53db3c336d0a1706b9 Author: Marc Zyngier Date: Mon Oct 17 13:47:34 2016 +0100 arm64: kernel: Init MDCR_EL2 even in the absence of a PMU commit 850540351bb1a4fa5f192e5ce55b89928cc57f42 upstream. 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 Signed-off-by: Marc Zyngier Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 69e1b2d4399c39f4df4742be2b7675805bd56714 Author: Will Deacon Date: Mon Jul 4 17:44:48 2016 +0100 arm64: percpu: rewrite ll/sc loops in assembly commit 1e6e57d9b34a9075d5f9e2048ea7b09756590d11 upstream. 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. Fixes: f97fc810798c ("arm64: percpu: Implement this_cpu operations") Reviewed-by: Mark Rutland Tested-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit f1816cea0102651ce0924c57bb5a0dc0e15a9e49 Author: Ard Biesheuvel Date: Thu Oct 13 17:42:09 2016 +0100 arm64: kaslr: fix breakage with CONFIG_MODVERSIONS=y commit 9c0e83c371cf4696926c95f9c8c77cd6ea803426 upstream. As it turns out, the KASLR code breaks CONFIG_MODVERSIONS, since the kcrctab has an absolute address field that is relocated at runtime when the kernel offset is randomized. This has been fixed already for PowerPC in the past, so simply wire up the existing code dealing with this issue. Fixes: f80fb3a3d508 ("arm64: add support for kernel ASLR") Tested-by: Timur Tabi Signed-off-by: Ard Biesheuvel Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 44870b14a4b3fe0dba53858ba55851c7856847c3 Author: Will Deacon Date: Mon Jul 4 16:59:43 2016 +0100 arm64: swp emulation: bound LL/SC retries before rescheduling commit 1c5b51dfb7b4564008e0cadec5381a69e88b0d21 upstream. If a CPU does not implement a global monitor for certain memory types, then userspace can attempt a kernel DoS by issuing SWP instructions targetting the problematic memory (for example, a framebuffer mapped with non-cacheable attributes). The SWP emulation code protects against these sorts of attacks by checking for pending signals and potentially rescheduling when the STXR instruction fails during the emulation. Whilst this is good for avoiding livelock, it harms emulation of legitimate SWP instructions on CPUs where forward progress is not guaranteed if there are memory accesses to the same reservation granule (up to 2k) between the failing STXR and the retry of the LDXR. This patch solves the problem by retrying the STXR a bounded number of times (4) before breaking out of the LL/SC loop and looking for something else to do. Fixes: bd35a4adc413 ("arm64: Port SWP/SWPB emulation support from arm") Reviewed-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 5e09db27f6d63095ca42c67c903c8a31174cb603 Author: Ulf Hansson Date: Wed Sep 28 11:33:28 2016 -0700 memstick: rtsx_usb_ms: Manage runtime PM when accessing the device commit 9158cb29e7c2f10dd325eb1589f0fe745a271257 upstream. 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: Ritesh Raj Sarraf Cc: Alan Stern Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 959288b70e54e7add0849b5fc2d470112341c47c Author: Alan Stern Date: Mon Sep 26 15:45:41 2016 -0700 memstick: rtsx_usb_ms: Runtime resume the device when polling for cards commit 796aa46adf1d90eab36ae06a42e6d3f10b28a75c upstream. 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 Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit d0ee9157a9d7056b3352c0b9225049cd4b588a0b Author: Jan Kara Date: Tue Oct 4 13:44:06 2016 +0200 isofs: Do not return EACCES for unknown filesystems commit a2ed0b391dd9c3ef1d64c7c3e370f4a5ffcd324a upstream. 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. Fixes: 17b7f7cf58926844e1dd40f5eb5348d481deca6a Reported-by: Kent Overstreet Reported-by: Karel Zak Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 627da03975badd33d66197dfab79932e566238be Author: Vaibhav Jain Date: Fri Oct 14 15:08:36 2016 +0530 cxl: Prevent adapter reset if an active context exists commit 70b565bbdb911023373e035225ab10077e4ab937 upstream. This patch prevents resetting the cxl adapter via sysfs in presence of one or more active cxl_context on it. This protects against an unrecoverable error caused by PSL owning a dirty cache line even after reset and host tries to touch the same cache line. In case a force reset of the card is required irrespective of any active contexts, the int value -1 can be stored in the 'reset' sysfs attribute of the card. The patch introduces a new atomic_t member named contexts_num inside struct cxl that holds the number of active context attached to the card , which is checked against '0' before proceeding with the reset. To prevent against a race condition where a context is activated just after reset check is performed, the contexts_num is atomically set to '-1' after reset-check to indicate that no more contexts can be activated on the card anymore. Before activating a context we atomically test if contexts_num is non-negative and if so, increment its value by one. In case the value of contexts_num is negative then it indicates that the card is about to be reset and context activation is error-ed out at that point. Fixes: 62fa19d4b4fd ("cxl: Add ability to reset the card") Acked-by: Frederic Barrat Reviewed-by: Andrew Donnellan Signed-off-by: Vaibhav Jain Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit ee13e8a1ae2f2ed434bdcc24011bd722fb3b32d9 Author: Vladimir Murzin Date: Mon Oct 17 16:00:46 2016 +0100 irqchip/gic-v3-its: Fix entry size mask for GITS_BASER commit 9224eb77e63f70f16c0b6b7a20ca7d395f3bc077 upstream. Entry Size in GITS_BASER occupies 5 bits [52:48], but we mask out 8 bits. Fixes: cc2d3216f53c ("irqchip: GICv3: ITS command queue") Signed-off-by: Vladimir Murzin Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit eff4f765eab0feb13bb45512e316ee9d8910813c Author: Noam Camus Date: Thu Oct 13 16:15:32 2016 +0300 irqchip/eznps: Acknowledge NPS_IPI before calling the handler commit c0ca8df717061ae3d2ea624024033103c64210ae upstream. IPI_IRQ (also TIMER0_IRQ) should be acked before the action->handler is called in handle_percpu_devid_irq. The IPI irq is edge sensitive and we might miss an IPI interrupt if it is triggered again while the handler runs. Fixes: 44df427c894a ("irqchip: add nps Internal and external irqchips") Signed-off-by: Noam Camus Cc: marc.zyngier@arm.com Cc: jason@lakedaemon.net Link: http://lkml.kernel.org/r/1476364532-12634-1-git-send-email-noamca@mellanox.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 82301da7eb625228ae021add4ac9f178e9b3b8ba Author: Dan Carpenter Date: Fri Oct 14 10:26:21 2016 +0300 irqchip/gicv3: Handle loop timeout proper commit d102eb5c1ac5e6743b1c6d145c06a25d98ad1375 upstream. 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 Link: http://lkml.kernel.org/r/20161014072534.GA15168@mwanda Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 2bb293cb8254d579ab831c38585d58444cf421dd Author: Peter Zijlstra Date: Tue Sep 20 21:58:12 2016 +0200 sched/fair: Fix min_vruntime tracking commit b60205c7c558330e4e2b5df498355ec959457358 upstream. While going through enqueue/dequeue to review the movement of set_curr_task() I noticed that the (2nd) update_min_vruntime() call in dequeue_entity() is suspect. It turns out, its actually wrong because it will consider cfs_rq->curr, which could be the entry we just normalized. This mixes different vruntime forms and leads to fail. The purpose of the second update_min_vruntime() is to move min_vruntime forward if the entity we just removed is the one that was holding it back; _except_ for the DEQUEUE_SAVE case, because then we know its a temporary removal and it will come back. However, since we do put_prev_task() _after_ dequeue(), cfs_rq->curr will still be set (and per the above, can be tranformed into a different unit), so update_min_vruntime() should also consider curr->on_rq. This also fixes another corner case where the enqueue (which also does update_curr()->update_min_vruntime()) happens on the rq->lock break in schedule(), between dequeue and put_prev_task. Signed-off-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.org Fixes: 1e876231785d ("sched: Fix ->min_vruntime calculation in dequeue_entity()") Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit f6ba261425740b0225aefb438a8509cdcb9a2122 Author: Vincent Guittot Date: Wed Oct 19 14:45:23 2016 +0200 sched/fair: Fix incorrect task group ->load_avg commit b5a9b340789b2b24c6896bcf7a065c31a4db671c upstream. A scheduler performance regression has been reported by Joseph Salisbury, which he bisected back to: 3d30544f0212 ("sched/fair: Apply more PELT fixes) The regression triggers when several levels of task groups are involved (read: SystemD) and cpu_possible_mask != cpu_present_mask. The root cause is that group entity's load (tg_child->se[i]->avg.load_avg) is initialized to scale_load_down(se->load.weight). During the creation of a child task group, its group entities on possible CPUs are attached to parent's cfs_rq (tg_parent) and their loads are added to the parent's load (tg_parent->load_avg) with update_tg_load_avg(). But only the load on online CPUs will then be updated to reflect real load, whereas load on other CPUs will stay at the initial value. The result is a tg_parent->load_avg that is higher than the real load, the weight of group entities (tg_parent->se[i]->load.weight) on online CPUs is smaller than it should be, and the task group gets a less running time than what it could expect. ( This situation can be detected with /proc/sched_debug. The ".tg_load_avg" of the task group will be much higher than sum of ".tg_load_avg_contrib" of online cfs_rqs of the task group. ) The load of group entities don't have to be intialized to something else than 0 because their load will increase when an entity is attached. Reported-by: Joseph Salisbury Tested-by: Dietmar Eggemann Signed-off-by: Vincent Guittot Acked-by: Peter Zijlstra Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: joonwoop@codeaurora.org Fixes: 3d30544f0212 ("sched/fair: Apply more PELT fixes) Link: http://lkml.kernel.org/r/1476881123-10159-1-git-send-email-vincent.guittot@linaro.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit cbc82f170d8408d275105e103a55b11bdbafeb74 Author: Ville Syrjälä Date: Mon Oct 3 17:56:55 2016 +0300 pinctrl: baytrail: Fix lockdep commit a171bc51fa697021e1b2082d7e95c12a363bc0a9 upstream. Initialize the spinlock before using it. INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.8.0-dwc-bisect #4 Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLAKFF81.X64.0088.R10.1403240443 FFD8_X64_R_2014_13_1_00 03/24/2014 0000000000000000 ffff8800788ff770 ffffffff8133d597 0000000000000000 0000000000000000 ffff8800788ff7e0 ffffffff810cfb9e 0000000000000002 ffff8800788ff7d0 ffffffff8205b600 0000000000000002 ffff8800788ff7f0 Call Trace: [] dump_stack+0x67/0x90 [] register_lock_class+0x52e/0x540 [] __lock_acquire+0x81/0x16b0 [] ? save_trace+0x41/0xd0 [] ? __lock_acquire+0x13b2/0x16b0 [] ? __lock_is_held+0x4a/0x70 [] lock_acquire+0xba/0x220 [] ? byt_gpio_get_direction+0x3e/0x80 [] _raw_spin_lock_irqsave+0x47/0x60 [] ? byt_gpio_get_direction+0x3e/0x80 [] byt_gpio_get_direction+0x3e/0x80 [] gpiochip_add_data+0x319/0x7d0 [] ? _raw_spin_unlock_irqrestore+0x43/0x70 [] byt_pinctrl_probe+0x2fb/0x620 [] platform_drv_probe+0x3c/0xa0 ... Based on the diff it looks like the problem was introduced in commit 71e6ca61e826 ("pinctrl: baytrail: Register pin control handling") but I wasn't able to verify that empirically as the parent commit just oopsed when I tried to boot it. Cc: Cristina Ciocan Fixes: 71e6ca61e826 ("pinctrl: baytrail: Register pin control handling") Signed-off-by: Ville Syrjälä Acked-by: Mika Westerberg Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 2e141f626d596f7b4972531b7aad1acd4565401a Author: Mika Westerberg Date: Mon Oct 10 16:39:31 2016 +0300 pinctrl: intel: Only restore pins that are used by the driver commit c538b9436751a0be2e1246b48353bc23156bdbcc upstream. Dell XPS 13 (and maybe some others) uses a GPIO (CPU_GP_1) during suspend to explicitly disable USB touchscreen interrupt. This is done to prevent situation where the lid is closed the touchscreen is left functional. The pinctrl driver (wrongly) assumes it owns all pins which are owned by host and not locked down. It is perfectly fine for BIOS to use those pins as it is also considered as host in this context. What happens is that when the lid of Dell XPS 13 is closed, the BIOS configures CPU_GP_1 low disabling the touchscreen interrupt. During resume we restore all host owned pins to the known state which includes CPU_GP_1 and this overwrites what the BIOS has programmed there causing the touchscreen to fail as no interrupts are reaching the CPU anymore. Fix this by restoring only those pins we know are explicitly requested by the kernel one way or other. Link: https://bugzilla.kernel.org/show_bug.cgi?id=176361 Reported-by: AceLan Kao Tested-by: AceLan Kao Signed-off-by: Mika Westerberg Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 85533a1ae7b6cdc71832c4669845d9faa7f04438 Author: Ville Syrjälä Date: Sat Oct 22 05:18:04 2016 +0300 x86/boot/smp: Don't try to poke disabled/non-existent APIC commit ff8560512b8d4b7ca3ef4fd69166634ac30b2525 upstream. Apparently trying to poke a disabled or non-existent APIC leads to a box that doesn't even boot. Let's not do that. No real clue if this is the right fix, but at least my P3 machine boots again. Signed-off-by: Ville Syrjälä Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: Eric Biederman Cc: H. Peter Anvin Cc: Jiri Olsa Cc: Josh Poimboeuf Cc: Juergen Gross Cc: Len Brown Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Prarit Bhargava Cc: Thomas Gleixner Cc: Yinghai Lu Cc: dyoung@redhat.com Cc: kexec@lists.infradead.org Fixes: 2a51fe083eba ("arch/x86: Handle non enumerated CPU after physical hotplug") Link: http://lkml.kernel.org/r/1477102684-5092-1-git-send-email-ville.syrjala@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 5f874b4b44ea7eeac995e054360fb0a2e436e527 Author: Alex Thorlton Date: Wed Oct 19 20:48:51 2016 -0500 x86/platform/UV: Fix support for EFI_OLD_MEMMAP after BIOS callback updates commit caef78b6cdeddf4ad364f95910bba6b43b8eb9bf upstream. Some time ago, we brought our UV BIOS callback code up to speed with the new EFI memory mapping scheme, in commit: d1be84a232e3 ("x86/uv: Update uv_bios_call() to use efi_call_virt_pointer()") By leveraging some changes that I made to a few of the EFI runtime callback mechanisms, in commit: 80e75596079f ("efi: Convert efi_call_virt() to efi_call_virt_pointer()") This got everything running smoothly on UV, with the new EFI mapping code. However, this left one, small loose end, in that EFI_OLD_MEMMAP (a.k.a. efi=old_map) will no longer work on UV, on kernels that include the aforementioned changes. At the time this was not a major issue (in fact, it still really isn't), but there's no reason that EFI_OLD_MEMMAP *shouldn't* work on our systems. This commit adds a check into uv_bios_call(), to see if we have the EFI_OLD_MEMMAP bit set in efi.flags. If it is set, we fall back to using our old callback method, which uses efi_call() directly on the __va() of our function pointer. Signed-off-by: Alex Thorlton Acked-by: Matt Fleming Cc: Andy Lutomirski Cc: Ard Biesheuvel Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: Dimitri Sivanich Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Masahiro Yamada Cc: Mike Travis Cc: Peter Zijlstra Cc: Russ Anderson Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1476928131-170101-1-git-send-email-athorlton@sgi.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 05574eae80dafcdfea8b8662ddc353003ff35b9e Author: Jiri Slaby Date: Thu Oct 13 17:45:20 2016 +0200 kvm: x86: memset whole irq_eoi commit 8678654e3c7ad7b0f4beb03fa89691279cba71f9 upstream. 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 Reviewed-by: Paolo Bonzini [Added x86 subject tag] Signed-off-by: Radim Krčmář Signed-off-by: Greg Kroah-Hartman commit 9c50927f802acd403ad6fd70b0a090c7439375e0 Author: Dan Williams Date: Wed Oct 12 11:01:48 2016 -0700 x86/e820: Don't merge consecutive E820_PRAM ranges commit 23446cb66c073b827779e5eb3dec301623299b32 upstream. Commit: 917db484dc6a ("x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation") ... fixed up the broken manipulations of max_pfn in the presence of E820_PRAM ranges. However, it also broke the sanitize_e820_map() support for not merging E820_PRAM ranges. Re-introduce the enabling to keep resource boundaries between consecutive defined ranges. Otherwise, for example, an environment that boots with memmap=2G!8G,2G!10G will end up with a single 4G /dev/pmem0 device instead of a /dev/pmem0 and /dev/pmem1 device 2G in size. Reported-by: Dave Chinner Signed-off-by: Dan Williams Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Jeff Moyer Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Zhang Yi Cc: linux-nvdimm@lists.01.org Fixes: 917db484dc6a ("x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation") Link: http://lkml.kernel.org/r/147629530854.10618.10383744751594021268.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit f974fb2623b409f59eda7abbebb6c4626e7614ab Author: Bart Van Assche Date: Thu Sep 29 08:33:30 2016 -0700 blkcg: Unlock blkcg_pol_mutex only once when cpd == NULL commit bbb427e342495df1cda10051d0566388697499c0 upstream. Unlocking a mutex twice is wrong. Hence modify blkcg_policy_register() such that blkcg_pol_mutex is unlocked once if cpd == NULL. This patch avoids that smatch reports the following error: block/blk-cgroup.c:1378: blkcg_policy_register() error: double unlock 'mutex:&blkcg_pol_mutex' Fixes: 06b285bd1125 ("blkcg: fix blkcg_policy_data allocation bug") Signed-off-by: Bart Van Assche Cc: Tejun Heo Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 38c7c171b160f84113c10e9428e03ed4dc33cfe6 Author: Sachin Prabhu Date: Tue Sep 6 13:22:34 2016 +0100 Fix regression which breaks DFS mounting commit d171356ff11ab1825e456dfb979755e01b3c54a1 upstream. Patch a6b5058 results in -EREMOTE returned by is_path_accessible() in cifs_mount() to be ignored which breaks DFS mounting. Signed-off-by: Sachin Prabhu Reviewed-by: Aurelien Aptel Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 917395fb15dcdf94c019ae3d1137fdbb519b56b0 Author: Steve French Date: Thu Sep 29 04:20:23 2016 -0500 Cleanup missing frees on some ioctls commit 24df1483c272c99ed88b0cba135d0e1dfdee3930 upstream. Cleanup some missing mem frees on some cifs ioctls, and clarify others to make more obvious that no data is returned. Signed-off-by: Steve French Acked-by: Sachin Prabhu Signed-off-by: Greg Kroah-Hartman commit b56cd33b56f339131644eddac4fd473fb6a5b778 Author: Steve French Date: Mon Sep 26 14:23:08 2016 -0500 Do not send SMB3 SET_INFO request if nothing is changing commit 18dd8e1a65ddae2351d0f0d6dd4a334f441fc5fa upstream. [CIFS] We had cases where we sent a SMB2/SMB3 setinfo request with all timestamp (and DOS attribute) fields marked as 0 (ie do not change) e.g. on chmod or chown. Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 72c4b9964afccf5cc87636878c588dbeb15328f5 Author: Steve French Date: Thu Sep 22 00:39:34 2016 -0500 SMB3: GUIDs should be constructed as random but valid uuids commit fa70b87cc6641978b20e12cc5d517e9ffc0086d4 upstream. GUIDs although random, and 16 bytes, need to be generated as proper uuids. Signed-off-by: Steve French Reviewed-by: Aurelien Aptel Reported-by: David Goebels Signed-off-by: Greg Kroah-Hartman commit 39829d8a546f670186afd7e0a6b5e068ef7e8578 Author: Steve French Date: Tue Sep 20 22:56:13 2016 -0500 Set previous session id correctly on SMB3 reconnect commit c2afb8147e69819885493edf3a7c1ce03aaf2d4e upstream. Signed-off-by: Steve French Reported-by: David Goebel Signed-off-by: Greg Kroah-Hartman commit 14d73491641ed6a1fc2be136fd9c4ce171a03129 Author: Steve French Date: Mon Sep 19 22:06:35 2016 -0500 Display number of credits available commit 9742805d6b1bfb45d7f267648c34fb5bcd347397 upstream. In debugging smb3, it is useful to display the number of credits available, so we can see when the server has not granted sufficient operations for the client to make progress, or alternatively the client has requested too many credits (as we saw in a recent bug) so we can compare with the number of credits the server thinks we have. Add a /proc/fs/cifs/DebugData line to display the client view on how many credits are available. Signed-off-by: Steve French Reported-by: Germano Percossi Signed-off-by: Greg Kroah-Hartman commit 1e70e271564fdd38daf444ef2e5cb754ecc8ebc8 Author: Steve French Date: Thu Sep 22 18:58:16 2016 -0500 Clarify locking of cifs file and tcon structures and make more granular commit 3afca265b5f53a0b15b79531c13858049505582d upstream. Remove the global file_list_lock to simplify cifs/smb3 locking and have spinlocks that more closely match the information they are protecting. Add new tcon->open_file_lock and file->file_info_lock spinlocks. Locks continue to follow a heirachy, cifs_socket --> cifs_ses --> cifs_tcon --> cifs_file where global tcp_ses_lock still protects socket and cifs_ses, while the the newer locks protect the lower level structure's information (tcon and cifs_file respectively). Signed-off-by: Steve French Signed-off-by: Pavel Shilovsky Reviewed-by: Aurelien Aptel Reviewed-by: Germano Percossi Signed-off-by: Greg Kroah-Hartman commit 363906789bb5053970d60190e173eeac3ce4bffe Author: Aurelien Aptel Date: Thu Sep 22 07:38:50 2016 +0200 fs/cifs: keep guid when assigning fid to fileinfo commit 94f873717571c759b7928399cbbddfa3d569bd01 upstream. When we open a durable handle we give a Globally Unique Identifier (GUID) to the server which we must keep for later reference e.g. when reopening persistent handles on reconnection. Without this the GUID generated for a new persistent handle was lost and 16 zero bytes were used instead on re-opening. Signed-off-by: Aurelien Aptel Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit e3c8bb30a6228392406ba98c331d35aaf00d1037 Author: Ross Lagerwall Date: Tue Sep 20 13:37:13 2016 +0100 cifs: Limit the overall credit acquired commit 7d414f396c91a3382e51cf628c1cf0709ad0188b upstream. The kernel client requests 2 credits for many operations even though they only use 1 credit (presumably to build up a buffer of credit). Some servers seem to give the client as much credit as is requested. In this case, the amount of credit the client has continues increasing to the point where (server->credits * MAX_BUFFER_SIZE) overflows in smb2_wait_mtu_credits(). Fix this by throttling the credit requests if an set limit is reached. For async requests where the credit charge may be > 1, request as much credit as what is charged. The limit is chosen somewhat arbitrarily. The Windows client defaults to 128 credits, the Windows server allows clients up to 512 credits (or 8192 for Windows 2016), and the NetApp server (and at least one other) does not limit clients at all. Choose a high enough value such that the client shouldn't limit performance. This behavior was seen with a NetApp filer (NetApp Release 9.0RC2). Signed-off-by: Ross Lagerwall Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 39bcd9f92d534c9abe69be349ca3ea4e6a7b8a87 Author: Oleg Nesterov Date: Mon Sep 26 18:07:48 2016 +0200 fs/super.c: fix race between freeze_super() and thaw_super() commit 89f39af129382a40d7cd1f6914617282cfeee28e upstream. Change thaw_super() to check frozen != SB_FREEZE_COMPLETE rather than frozen == SB_UNFROZEN, otherwise it can race with freeze_super() which drops sb->s_umount after SB_FREEZE_WRITE to preserve the lock ordering. In this case thaw_super() will wrongly call s_op->unfreeze_fs() before it was actually frozen, and call sb_freeze_unlock() which leads to the unbalanced percpu_up_write(). Unfortunately lockdep can't detect this, so this triggers misc BUG_ON()'s in kernel/rcu/sync.c. Reported-and-tested-by: Nikolay Borisov Signed-off-by: Oleg Nesterov Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 54203cf6fcf4d4519a79819aa2e90a21f98bc5e2 Author: Al Viro Date: Sat Sep 10 16:31:04 2016 -0400 arc: don't leak bits of kernel stack into coredump commit 7798bf2140ebcc36eafec6a4194fffd8d585d471 upstream. On faulting sigreturn we do get SIGSEGV, all right, but anything we'd put into pt_regs could end up in the coredump. And since __copy_from_user() never zeroed on arc, we'd better bugger off on its failure without copying random uninitialized bits of kernel stack into pt_regs... Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit aa8f9876b8029372191ca3687d8a188975adc74c Author: Vladimir Murzin Date: Thu Sep 1 15:29:03 2016 +0100 arm64: KVM: VHE: reset PSTATE.PAN on entry to EL2 commit cb96408da4e11698674abd04aeac941c1bed2038 upstream. SCTLR_EL2.SPAN bit controls what happens with the PSTATE.PAN bit on an exception. However, this bit has no effect on the PSTATE.PAN when HCR_EL2.E2H or HCR_EL2.TGE is unset. Thus when VHE is used and exception taken from a guest PSTATE.PAN bit left unchanged and we continue with a value guest has set. To address that always reset PSTATE.PAN on entry from EL1. Fixes: 1f364c8c48a0 ("arm64: VHE: Add support for running Linux in EL2 mode") Signed-off-by: Vladimir Murzin Reviewed-by: James Morse Acked-by: Marc Zyngier Signed-off-by: Christoffer Dall [ rebased for v4.7+ ] Signed-off-by: Greg Kroah-Hartman commit 8790ff414ffcb3868dde6e61b707349138512b4b Author: Christophe Leroy Date: Tue Aug 16 08:26:20 2016 +0200 soc/fsl/qe: fix Oops on CPM1 (and likely CPM2) commit 4d486e0083796b54d5aeddd7a5794f897fca1008 upstream. Commit 0e6e01ff694ee ("CPM/QE: use genalloc to manage CPM/QE muram") has changed the way muram is managed. genalloc uses kmalloc(), hence requires the SLAB to be up and running. On powerpc 8xx, cpm_reset() is called early during startup. cpm_reset() then calls cpm_muram_init() before SLAB is available, hence the following Oops. cpm_reset() cannot be called during initcalls because the CPM is needed for console. This patch removes the call to cpm_muram_init() from cpm_reset(). cpm_muram_init() will be called from a new function called cpm_init() which is declared as subsys_initcall, unless cpm_muram_alloc() is called earlier for the serial console in which case cpm_muram_init() will be called from there. The reason for calling it from two places is that some drivers (e.g. i2c-cpm) need some of the initialisations done by cpm_muram_init() but don't call cpm_muram_alloc(). The console driver calls cpm_muram_alloc() but some platforms might not use the CPM serial ports for console. [ 0.000000] Unable to handle kernel paging request for data at address 0x00000008 [ 0.000000] Faulting instruction address: 0xc01acce0 [ 0.000000] Oops: Kernel access of bad area, sig: 11 [#1] [ 0.000000] PREEMPT CMPC885 [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.4.14-g0886ed8 #5 [ 0.000000] task: c05183e0 ti: c0536000 task.ti: c0536000 [ 0.000000] NIP: c01acce0 LR: c0011068 CTR: 00000000 [ 0.000000] REGS: c0537e50 TRAP: 0300 Not tainted (4.4.14-s3k-dev-g0886ed8-svn) [ 0.000000] MSR: 00001032 CR: 28044428 XER: 00000000 [ 0.000000] DAR: 00000008 DSISR: c0000000 GPR00: c0011068 c0537f00 c05183e0 00000000 00009000 ffffffff 00000bc0 ffffffff GPR08: ff003000 ff00b000 ff003bbf 00000000 22044422 100d43a8 00000000 07ff94e8 GPR16: 00000000 07bb5d70 00000000 07ff81f4 07ff81f4 07ff81f4 00000000 00000000 GPR24: 07ffb3a0 07fe7628 c0550000 c7ffa190 c0540000 ff003bbf 00000000 00000001 [ 0.000000] NIP [c01acce0] gen_pool_add_virt+0x14/0xdc [ 0.000000] LR [c0011068] cpm_muram_init+0xd4/0x18c [ 0.000000] Call Trace: [ 0.000000] [c0537f00] [00000200] 0x200 (unreliable) [ 0.000000] [c0537f20] [c0011068] cpm_muram_init+0xd4/0x18c [ 0.000000] [c0537f70] [c0494684] cpm_reset+0xb4/0xc8 [ 0.000000] [c0537f90] [c0494c64] cmpc885_setup_arch+0x10/0x30 [ 0.000000] [c0537fa0] [c0493cd4] setup_arch+0x130/0x168 [ 0.000000] [c0537fb0] [c04906bc] start_kernel+0x88/0x380 [ 0.000000] [c0537ff0] [c0002224] start_here+0x38/0x98 [ 0.000000] Instruction dump: [ 0.000000] 91430010 91430014 80010014 83e1000c 7c0803a6 38210010 4e800020 7c0802a6 [ 0.000000] 9421ffe0 bf61000c 90010024 7c7e1b78 <80630008> 7c9c2378 7cc31c30 3863001f [ 0.000000] ---[ end trace dc8fa200cb88537f ]--- fixes: 0e6e01ff694ee ("CPM/QE: use genalloc to manage CPM/QE muram") Signed-off-by: Christophe Leroy [scottwood: Removed some string changes unrelated to bugfix] Signed-off-by: Scott Wood Signed-off-by: Greg Kroah-Hartman commit b726aaa131c6fa43699b6b52a94b0998c452e337 Author: Christophe Leroy Date: Tue Sep 6 00:52:16 2016 +0200 soc/fsl/qe: fix gpio save_regs functions commit 5dc6f3fedee58efa343e822558fc3e2f0eb2ad1f upstream. of_mm_gpiochip_add_data() calls mm_gc->save_regs() before setting the data. Therefore ->save_regs() cannot use gpiochip_get_data() An Oops is encountered without this fix. fixes: 1e714e54b5ca5 ("powerpc: qe_lib-gpio: use gpiochip data pointer") Signed-off-by: Christophe Leroy Reviewed-by: Linus Walleij Signed-off-by: Scott Wood Signed-off-by: Greg Kroah-Hartman commit eeacb70be849be0cd02626e5635500870b00d286 Author: Guenter Roeck Date: Fri Oct 7 10:40:59 2016 -0700 metag: Only define atomic_dec_if_positive conditionally commit 35d04077ad96ed33ceea2501f5a4f1eacda77218 upstream. The definition of atomic_dec_if_positive() assumes that atomic_sub_if_positive() exists, which is only the case if metag specific atomics are used. This results in the following build error when trying to build metag1_defconfig. kernel/ucount.c: In function 'dec_ucount': kernel/ucount.c:211: error: implicit declaration of function 'atomic_sub_if_positive' Moving the definition of atomic_dec_if_positive() into the metag conditional code fixes the problem. Fixes: 6006c0d8ce94 ("metag: Atomics, locks and bitops") Signed-off-by: Guenter Roeck Signed-off-by: James Hogan Signed-off-by: Greg Kroah-Hartman commit f316bc2b64c8ca4811117fb8b085662732f528e7 Author: Guenter Roeck Date: Mon Sep 12 06:16:51 2016 -0700 watchdog: mt7621_wdt: Remove assignment of dev pointer commit 8355b3f94425ac8b9683869354be935795f055ca upstream. Commit 0254e953537c ("watchdog: Drop pointer to watchdog device from struct watchdog_device") removed the dev pointer from struct watchdog_device, but this driver was still assigning it, leading to a compilation error: drivers/watchdog/mt7621_wdt.c: In function 'mt7621_wdt_probe': drivers/watchdog/mt7621_wdt.c:142:16: error: 'struct watchdog_device' has no member named 'dev' Fix this by removing the assignment. Fixes: 0254e953537c ("watchdog: Drop pointer to watchdog device ...") Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman commit bfdc15a4f726ff86bf938762324ab3ffde2aebd2 Author: Matt Redfearn Date: Mon Sep 12 10:35:12 2016 +0100 watchdog: rt2880_wdt: Remove assignment of dev pointer commit df9c692b5618914d4ce7c9e3e011c5683fc16226 upstream. Commit 0254e953537c ("watchdog: Drop pointer to watchdog device from struct watchdog_device") removed the dev pointer from struct watchdog_device, but this driver was still assigning it, leading to a compilation error: drivers/watchdog/rt2880_wdt.c: In function ‘rt288x_wdt_probe’: drivers/watchdog/rt2880_wdt.c:161:16: error: ‘struct watchdog_device’ has no member named ‘dev’ rt288x_wdt_dev.dev = &pdev->dev; ^ scripts/Makefile.build:289: recipe for target 'drivers/watchdog/rt2880_wdt.o' failed Fix this by removing the assignment. Fixes: 0254e953537c ("watchdog: Drop pointer to watchdog device ...") Signed-off-by: Matt Redfearn Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman commit 8bfe1c78242a333a78674e4bda6e5040ae0b048c Author: Ming Lei Date: Sun Oct 9 13:23:27 2016 +0800 scsi: Fix use-after-free commit bcd8f2e94808fcddf6ef3af5f060a36820dcc432 upstream. 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 Signed-off-by: Ming Lei Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit d8928265bd89ff1bada90e82c1800ac595cac9f6 Author: Benjamin Coddington Date: Tue Oct 11 15:53:21 2016 -0400 pnfs/blocklayout: fix last_write_offset incorrectly set to page boundary commit a3f9d1b58a9ffce011ef4f074bfa36ae30eade28 upstream. Commit 41963c10c47a35185e68cb9049f7a3493c94d2d7 sets the block layout's last written byte to the offset of the end of the extent rather than the end of the write which incorrectly updates the inode's size for partial-page writes. Fixes: 41963c10c47a ("pnfs/blocklayout: update last_write_offset atomically with extents") Signed-off-by: Benjamin Coddington Reviewed-by: Christoph Hellwig Tested-by: Christoph Hellwig Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 573be97afe13eca55ded0266251a67fa65328b51 Author: Jeff Layton Date: Tue Oct 4 00:07:43 2016 -0400 NFSv4.2: Fix a reference leak in nfs42_proc_layoutstats_generic commit 3f807e5ae5597bd65a6fff684083e8eaa21f3fa7 upstream. The caller of rpc_run_task also gets a reference that must be put. Signed-off-by: Jeff Layton Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit a86b85c2b6b878b6806a1c0656a2bc680b41845f Author: Trond Myklebust Date: Thu Sep 22 13:39:18 2016 -0400 NFSv4: Open state recovery must account for file permission changes commit 304020fe48c6c7fff8b5a38f382b54404f0f79d3 upstream. If the file permissions change on the server, then we may not be able to recover open state. If so, we need to ensure that we mark the file descriptor appropriately. Signed-off-by: Trond Myklebust Tested-by: Oleg Drokin Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit b9ab7db437b6d94b5e706ce9b33a82256bb66186 Author: Trond Myklebust Date: Thu Sep 22 13:38:54 2016 -0400 NFSv4: nfs4_copy_delegation_stateid() must fail if the delegation is invalid commit aa05c87f23efe417adc7ff9b4193b7201ec0dd79 upstream. We must not allow the use of delegations that have been revoked or are being returned. Signed-off-by: Trond Myklebust Fixes: 869f9dfa4d6d ("NFSv4: Fix races between nfs_remove_bad_delegation()...") Signed-off-by: Trond Myklebust Tested-by: Oleg Drokin Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 26bd9968d5e8f2576b346034468180e34cd863b1 Author: Trond Myklebust Date: Thu Sep 22 13:38:53 2016 -0400 NFSv4: Don't report revoked delegations as valid in nfs_have_delegation() commit b3f9e7239074613aa6bdafa4caf7c104fe1e7276 upstream. If the delegation is revoked, then it can't be used for caching. Fixes: 869f9dfa4d6d ("NFSv4: Fix races between nfs_remove_bad_delegation()...") Signed-off-by: Trond Myklebust Tested-by: Oleg Drokin Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 78ee5302854aef3b95a69b807d179ea57e6608d7 Author: Trond Myklebust Date: Thu Sep 22 13:38:52 2016 -0400 NFS: Fix inode corruption in nfs_prime_dcache() commit 7dc72d5f7a0ec97a53e126c46e2cbd2560757955 upstream. Due to inode number reuse in filesystems, we can end up corrupting the inode on our client if we apply the file attributes without ensuring that the filehandle matches. Typical symptoms include spurious "mode changed" reports in the syslog. We still do want to ensure that we don't invalidate the dentry if the inode number matches, but we don't have a filehandle. Fixes: fa9233699cc1 ("NFS: Don't require a filehandle to refresh...") Signed-off-by: Trond Myklebust Tested-by: Oleg Drokin Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 73839f59c07cbfda7167093e1d69cbc592dd1b96 Author: Vasily Averin Date: Wed Sep 21 15:33:05 2016 +0300 NFSD: fix corruption in notifier registration commit 1eca45f8a840987d0df355e0176921653e4f7ec2 upstream. By design notifier can be registered once only, however nfsd registers the same inetaddr notifiers per net-namespace. When this happen it corrupts list of notifiers, as result some notifiers can be not called on proper event, traverse on list can be cycled forever, and second unregister can access already freed memory. fixes: 36684996 ("nfsd: Register callbacks on the inetaddr_chain and inet6addr_chain") Signed-off-by: Vasily Averin Reviewed-by: Jeff Layton Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 3f7b0fa48a3ce648c05bf4267219fa8f9f620486 Author: David Vrabel Date: Mon Sep 19 13:58:30 2016 +0100 sunrpc: fix write space race causing stalls commit d48f9ce73c997573e1b512893fa6eddf353a6f69 upstream. Write space becoming available may race with putting the task to sleep in xprt_wait_for_buffer_space(). The existing mechanism to avoid the race does not work. This (edited) partial trace illustrates the problem: [1] rpc_task_run_action: task:43546@5 ... action=call_transmit [2] xs_write_space <-xs_tcp_write_space [3] xprt_write_space <-xs_write_space [4] rpc_task_sleep: task:43546@5 ... [5] xs_write_space <-xs_tcp_write_space [1] Task 43546 runs but is out of write space. [2] Space becomes available, xs_write_space() clears the SOCKWQ_ASYNC_NOSPACE bit. [3] xprt_write_space() attemts to wake xprt->snd_task (== 43546), but this has not yet been queued and the wake up is lost. [4] xs_nospace() is called which calls xprt_wait_for_buffer_space() which queues task 43546. [5] The call to sk->sk_write_space() at the end of xs_nospace() (which is supposed to handle the above race) does not call xprt_write_space() as the SOCKWQ_ASYNC_NOSPACE bit is clear and thus the task is not woken. Fix the race by resetting the SOCKWQ_ASYNC_NOSPACE bit in xs_nospace() so the second call to sk->sk_write_space() calls xprt_write_space(). Suggested-by: Trond Myklebust Signed-off-by: David Vrabel Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit b235f0b5ba45b240be07d1ac3d2396c786bfe824 Author: Dmitry Torokhov Date: Wed Oct 5 22:49:30 2016 -0700 Input: elantech - add Fujitsu Lifebook E556 to force crc_enabled commit 62837b3c1a95535d1a287c9c8c6563bbd8d37033 upstream. Another Lifebook machine that needs the same quirk as other similar models to make the driver working. Also let's reorder elantech_dmi_force_crc_enabled list so LIfebook enries are in alphabetical order. Reported-by: William Linna Tested-by: William Linna Reviewed-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit b2fb6ea36dff852c6688948ac905b3a8ef48d49a Author: Matti Kurkela Date: Mon Oct 3 16:48:17 2016 -0700 Input: elantech - force needed quirks on Fujitsu H760 commit f9a703a54d16ba2470391c4b12236ee56591d50c upstream. Just like Fujitsu CELSIUS H730, the H760 also has an Elantech touchpad with the same quirks. Without this patch, the touchpad is useless out-of-the-box as the mouse pointer won't move. This patch makes the driver aware of both the crc_enabled=1 requirement and the middle button, making the touchpad fully functional out-of-the-box. Signed-off-by: Matti Kurkela Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 5d6b57eb1021da62db394896eeba23829f672665 Author: Marcos Paulo de Souza Date: Sat Oct 1 12:07:35 2016 -0700 Input: i8042 - skip selftest on ASUS laptops commit 930e19248e9b61da36c967687ca79c4d5f977919 upstream. On suspend/resume cycle, selftest is executed to reset i8042 controller. But when this is done in Asus devices, subsequent calls to detect/init functions to elantech driver fails. Skipping selftest fixes this problem. An easier step to reproduce this problem is adding i8042.reset=1 as a kernel parameter. On Asus laptops, it'll make the system to start with the touchpad already stuck, since psmouse_probe forcibly calls the selftest function. This patch was inspired by John Hiesey's change[1], but, since this problem affects a lot of models of Asus, let's avoid running selftests on them. All models affected by this problem: A455LD K401LB K501LB K501LX R409L V502LX X302LA X450LCP X450LD X455LAB X455LDB X455LF Z450LA [1]: https://marc.info/?l=linux-input&m=144312209020616&w=2 Fixes: "ETPS/2 Elantech Touchpad dies after resume from suspend" (https://bugzilla.kernel.org/show_bug.cgi?id=107971) Signed-off-by: Marcos Paulo de Souza Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 270e1295688c1830a8fc498e84c17f7e512fcfb2 Author: Marcin Nowakowski Date: Wed Oct 12 09:32:56 2016 +0200 MIPS: ptrace: Fix regs_return_value for kernel context commit 74f1077b5b783e7bf4fa3007cefdc8dbd6c07518 upstream. Currently regs_return_value always negates reg[2] if it determines the syscall has failed, but when called in kernel context this check is invalid and may result in returning a wrong value. This fixes errors reported by CONFIG_KPROBES_SANITY_TEST Fixes: d7e7528bcd45 ("Audit: push audit success and retcode into arch ptrace.h") Signed-off-by: Marcin Nowakowski Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14381/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 201c954a1b71e0640eff8ded91b748f72313be64 Author: James Hogan Date: Thu Oct 6 23:10:41 2016 +0100 MIPS: Fix -mabi=64 build of vdso.lds commit 034827c727f7f3946a18355b63995b402c226c82 upstream. The native ABI vDSO linker script vdso.lds is built by preprocessing vdso.lds.S, with the native -mabi flag passed in to get the correct ABI definitions. Unfortunately however certain toolchains choke on -mabi=64 without a corresponding compatible -march flag, for example: cc1: error: ‘-march=mips32r2’ is not compatible with the selected ABI scripts/Makefile.build:338: recipe for target 'arch/mips/vdso/vdso.lds' failed Fix this by including ccflags-vdso in the KBUILD_CPPFLAGS for vdso.lds, which includes the appropriate -march flag. Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO") Signed-off-by: James Hogan Reviewed-by: Maciej W. Rozycki Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14368/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 7e98c29e0bb25fe1df584099fe2ac7b5db91968c Author: Hui Wang Date: Tue Oct 11 10:48:58 2016 +0800 ALSA: hda - Fix a failure of micmute led when having multi adcs commit 4875a5f7218068cdeea5f998330dfa3d118b2fea upstream. On a Dell laptop, there is no global adcs for all input devices, so the input devices use the different adc, as a result, dyn_adc_switch is set to true. In this situation, it is safe to control the micmute led according to user's choice of muting/unmuting the current input device, since only current input device path is active, while other input device paths are inactive and powered down. Fixes: 00ef99408b6c ('ALSA: hda - add mic mute led hook for dell machines') Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7e511d9ee3f4fcf6d6b655b45e8571819c779a39 Author: Mauro Carvalho Chehab Date: Mon Sep 5 05:56:37 2016 -0300 cx231xx: can't proceed if I2C bus register fails commit 461af077d349b11106ca084e9ef2973a753d33ff upstream. The driver should not ignore errors while registering the I2C bus, as this device can't even minimally work without the buses, as it uses those buses internally to talk with the several IP blocks inside the chip. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 5dfa69791d0fe7dd8f0cf08030636f4ac3ca871c Author: Mauro Carvalho Chehab Date: Sun Sep 4 10:06:39 2016 -0300 cx231xx: fix GPIOs for Pixelview SBTVD hybrid commit 24b923f073ac37eb744f56a2c7f77107b8219ab2 upstream. This device uses GPIOs: 28 to switch between analog and digital modes: on digital mode, it should be set to 1. The code that sets it on analog mode is OK, but it misses the logic that sets it on digital mode. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit c28907151b188ba5d944b07719642449f4efea1d Author: Mauro Carvalho Chehab Date: Sun Sep 4 09:56:33 2016 -0300 cx231xx: don't return error on success commit 1871d718a9db649b70f0929d2778dc01bc49b286 upstream. The cx231xx_set_agc_analog_digital_mux_select() callers expect it to return 0 or an error. Returning a positive value makes the first attempt to switch between analog/digital to fail. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 43e5cd3be47759c2820c27dd6682e2ac19074abf Author: Mauro Carvalho Chehab Date: Sun Sep 4 10:43:53 2016 -0300 mb86a20s: fix demod settings commit 505a0ea706fc1db4381baa6c6bd2e596e730a55e upstream. With the current settings, only one channel locks properly. That's likely because, when this driver was written, Brazil were still using experimental transmissions. Change it to reproduce the settings used by the newer drivers. That makes it lock on other channels. Tested with both PixelView SBTVD Hybrid (cx231xx-based) and C3Tech Digital Duo HDTV/SDTV (em28xx-based) devices. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit f761acfaf21f8862be946a960ab965282d085a5b Author: Mauro Carvalho Chehab Date: Sun Sep 4 10:16:18 2016 -0300 mb86a20s: fix the locking logic commit dafb65fb98d85d8e78405e82c83e81975e5d5480 upstream. On this frontend, it takes a while to start output normal TS data. That only happens on state S9. On S8, the TS output is enabled, but it is not reliable enough. However, the zigzag loop is too fast to let it sync. As, on practical tests, the zigzag software loop doesn't seem to be helping, but just slowing down the tuning, let's switch to hardware algorithm, as the tuners used on such devices are capable of work with frequency drifts without any help from software. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 5a7d384203fcc75d020a6f10179fe571151c2e2d Author: Miklos Szeredi Date: Fri Sep 16 14:12:11 2016 +0200 ovl: copy_up_xattr(): use strnlen commit 8b326c61de08f5ca4bc454a168f19e7e43c4cc2a upstream. Be defensive about what underlying fs provides us in the returned xattr list buffer. strlen() may overrun the buffer, so use strnlen() and WARN if the contents are not properly null terminated. Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 05cc17e076ea335385db7ac2896c4f3db46ccd15 Author: Richard Weinberger Date: Fri Sep 16 11:45:24 2016 +0200 ovl: Fix info leak in ovl_lookup_temp() commit 6a45b3628ce4dcf7498b39c87d475bab6e2a9b24 upstream. The function uses the memory address of a struct dentry as unique id. While the address-based directory entry is only visible to root it is IMHO still worth fixing since the temporary name does not have to be a kernel address. It can be any unique number. Replace it by an atomic integer which is allowed to wrap around. Signed-off-by: Richard Weinberger Reviewed-by: Kees Cook Signed-off-by: Miklos Szeredi Fixes: e9be9d5e76e3 ("overlay filesystem") Signed-off-by: Greg Kroah-Hartman commit ef59d3a1fb690bceded02fad728a2b8909146219 Author: Max Staudt Date: Mon Jun 13 19:15:59 2016 +0200 fbdev/efifb: Fix 16 color palette entry calculation commit d50b3f43db739f03fcf8c0a00664b3d2fed0496e upstream. When using efifb with a 16-bit (5:6:5) visual, fbcon's text is rendered in the wrong colors - e.g. text gray (#aaaaaa) is rendered as green (#50bc50) and neighboring pixels have slightly different values (such as #50bc78). The reason is that fbcon loads its 16 color palette through efifb_setcolreg(), which in turn calculates a 32-bit value to write into memory for each palette index. Until now, this code could only handle 8-bit visuals and didn't mask overlapping values when ORing them. With this patch, fbcon displays the correct colors when a qemu VM is booted in 16-bit mode (in GRUB: "set gfxpayload=800x600x16"). Fixes: 7c83172b98e5 ("x86_64 EFI boot support: EFI frame buffer driver") # v2.6.24+ Signed-off-by: Max Staudt Acked-By: Peter Jones Signed-off-by: Tomi Valkeinen Signed-off-by: Greg Kroah-Hartman commit b9c75896696e360e471c7b8aba02ea0d866544a4 Author: Dan Carpenter Date: Fri Oct 14 16:18:39 2016 -0400 scsi: zfcp: spin_lock_irqsave() is not nestable commit e7cb08e894a0b876443ef8fdb0706575dc00a5d2 upstream. We accidentally overwrite the original saved value of "flags" so that we can't re-enable IRQs at the end of the function. Presumably this function is mostly called with IRQs disabled or it would be obvious in testing. Fixes: aceeffbb59bb ("zfcp: trace full payload of all SAN records (req,resp,iels)") Signed-off-by: Dan Carpenter Signed-off-by: Steffen Maier Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 43f9b541715c90c9fb158f6becdfd6ddd96c30fb Author: Steffen Maier Date: Wed Aug 10 18:30:53 2016 +0200 zfcp: trace full payload of all SAN records (req,resp,iels) commit aceeffbb59bb91404a0bda32a542d7ebf878433a upstream. This was lost with commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.") but is necessary for problem determination, e.g. to see the currently active zone set during automatic port scan. For the large GPN_FT response (4 pages), save space by not dumping any empty residual entries. Signed-off-by: Steffen Maier Fixes: 2c55b750a884 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.") Reviewed-by: Alexey Ishchuk Reviewed-by: Benjamin Block Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit e5951b41710f37c6166839eb26eed0d344b4861e Author: Steffen Maier Date: Wed Aug 10 18:30:52 2016 +0200 zfcp: fix payload trace length for SAN request&response commit 94db3725f049ead24c96226df4a4fb375b880a77 upstream. commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.") started to add FC_CT_HDR_LEN which made zfcp dump random data out of bounds for RSPN GS responses because u.rspn.rsp is the largest and last field in the union of struct zfcp_fc_req. Other request/response types only happened to stay within bounds due to the padding of the union or due to the trace capping of u.gspn.rsp to ZFCP_DBF_SAN_MAX_PAYLOAD. Timestamp : ... Area : SAN Subarea : 00 Level : 1 Exception : - CPU id : .. Caller : ... Record id : 2 Tag : fsscth2 Request id : 0x... Destination ID : 0x00fffffc Payload short : 01000000 fc020000 80020000 00000000 xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx <=== 00000000 00000000 00000000 00000000 Payload length : 32 <=== struct zfcp_fc_req { [0] struct zfcp_fsf_ct_els ct_els; [56] struct scatterlist sg_req; [96] struct scatterlist sg_rsp; union { struct {req; rsp;} adisc; SIZE: 28+28= 56 struct {req; rsp;} gid_pn; SIZE: 24+20= 44 struct {rspsg; req;} gpn_ft; SIZE: 40*4+20=180 struct {req; rsp;} gspn; SIZE: 20+273= 293 struct {req; rsp;} rspn; SIZE: 277+16= 293 [136] } u; } SIZE: 432 Signed-off-by: Steffen Maier Fixes: 2c55b750a884 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.") Reviewed-by: Alexey Ishchuk Reviewed-by: Benjamin Block Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit f1bebeca1a9d069b802936053397d857d4aeb4ee Author: Steffen Maier Date: Wed Aug 10 18:30:51 2016 +0200 zfcp: fix D_ID field with actual value on tracing SAN responses commit 771bf03537ddfa4a4dde62ef9dfbc82e4f77ab20 upstream. With commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.") we lost the N_Port-ID where an ELS response comes from. With commit 7c7dc196814b9e1d5cc254dc579a5fa78ae524f7 ("[SCSI] zfcp: Simplify handling of ct and els requests") we lost the N_Port-ID where a CT response comes from. It's especially useful if the request SAN trace record with D_ID was already lost due to trace buffer wrap. GS uses an open WKA port handle and ELS just a D_ID, and only for ELS we could get D_ID from QTCB bottom via zfcp_fsf_req. To cover both cases, add a new field to zfcp_fsf_ct_els and fill it in on request to use in SAN response trace. Strictly speaking the D_ID on SAN response is the FC frame's S_ID. We don't need a field for the other end which is always us. Signed-off-by: Steffen Maier Fixes: 2c55b750a884 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.") Fixes: 7c7dc196814b ("[SCSI] zfcp: Simplify handling of ct and els requests") Reviewed-by: Benjamin Block Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit e340e2a4b79c014f657377594a6b62b91439a26d Author: Steffen Maier Date: Wed Aug 10 18:30:50 2016 +0200 zfcp: restore tracing of handle for port and LUN with HBA records commit 7c964ffe586bc0c3d9febe9bf97a2e4b2866e5b7 upstream. This information was lost with commit a54ca0f62f953898b05549391ac2a8a4dad6482b ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.") but is required to debug e.g. invalid handle situations. Signed-off-by: Steffen Maier Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.") Reviewed-by: Benjamin Block Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit b8ece195d88a98dd677a2ee39d968ebccff26994 Author: Steffen Maier Date: Wed Aug 10 18:30:49 2016 +0200 zfcp: trace on request for open and close of WKA port commit d27a7cb91960cf1fdd11b10071e601828cbf4b1f upstream. Since commit a54ca0f62f953898b05549391ac2a8a4dad6482b ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.") HBA records no longer contain WWPN, D_ID, or LUN to reduce duplicate information which is already in REC records. In contrast to "regular" target ports, we don't use recovery to open WKA ports such as directory/nameserver, so we don't get REC records. Therefore, introduce pseudo REC running records without any actual recovery action but including D_ID of WKA port on open/close. Signed-off-by: Steffen Maier Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.") Reviewed-by: Benjamin Block Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit b4b59508872640a7532d505fafc95121c187af71 Author: Steffen Maier Date: Wed Aug 10 18:30:48 2016 +0200 zfcp: restore: Dont use 0 to indicate invalid LUN in rec trace commit 0102a30a6ff60f4bb4c07358ca3b1f92254a6c25 upstream. bring back commit d21e9daa63e009ce5b87bbcaa6d11ce48e07bbbe ("[SCSI] zfcp: Dont use 0 to indicate invalid LUN in rec trace") which was lost with commit ae0904f60fab7cb20c48d32eefdd735e478b91fb ("[SCSI] zfcp: Redesign of the debug tracing for recovery actions.") Signed-off-by: Steffen Maier Fixes: ae0904f60fab ("[SCSI] zfcp: Redesign of the debug tracing for recovery actions.") Reviewed-by: Benjamin Block Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 932db5a82a0bf1552b714977fd9428ca09a542c7 Author: Steffen Maier Date: Wed Aug 10 18:30:47 2016 +0200 zfcp: retain trace level for SCSI and HBA FSF response records commit 35f040df97fa0e94c7851c054ec71533c88b4b81 upstream. While retaining the actual filtering according to trace level, the following commits started to write such filtered records with a hardcoded record level of 1 instead of the actual record level: commit 250a1352b95e1db3216e5c5d4f4365bea5122f4a ("[SCSI] zfcp: Redesign of the debug tracing for SCSI records.") commit a54ca0f62f953898b05549391ac2a8a4dad6482b ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.") Now we can distinguish written records again for offline level filtering. Signed-off-by: Steffen Maier Fixes: 250a1352b95e ("[SCSI] zfcp: Redesign of the debug tracing for SCSI records.") Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.") Reviewed-by: Benjamin Block Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 2c537206e8b802af9d1038f994a433d28fe7fce2 Author: Steffen Maier Date: Wed Aug 10 18:30:46 2016 +0200 zfcp: close window with unblocked rport during rport gone commit 4eeaa4f3f1d6c47b69f70e222297a4df4743363e upstream. On a successful end of reopen port forced, zfcp_erp_strategy_followup_success() re-uses the port erp_action and the subsequent zfcp_erp_action_cleanup() now sees ZFCP_ERP_SUCCEEDED with erp_action->action==ZFCP_ERP_ACTION_REOPEN_PORT instead of ZFCP_ERP_ACTION_REOPEN_PORT_FORCED but must not perform zfcp_scsi_schedule_rport_register(). We can detect this because the fresh port reopen erp_action is in its very first step ZFCP_ERP_STEP_UNINITIALIZED. Otherwise this opens a time window with unblocked rport (until the followup port reopen recovery would block it again). If a scsi_cmnd timeout occurs during this time window fc_timed_out() cannot work as desired and such command would indeed time out and trigger scsi_eh. This prevents a clean and timely path failover. This should not happen if the path issue can be recovered on FC transport layer such as path issues involving RSCNs. Also, unnecessary and repeated DID_IMM_RETRY for pending and undesired new requests occur because internally zfcp still has its zfcp_port blocked. As follow-on errors with scsi_eh, it can cause, in the worst case, permanently lost paths due to one of: sd : [] Medium access timeout failure. Offlining disk! sd : Device offlined - not ready after error recovery For fix validation and to aid future debugging with other recoveries we now also trace (un)blocking of rports. Signed-off-by: Steffen Maier Fixes: 5767620c383a ("[SCSI] zfcp: Do not unblock rport from REOPEN_PORT_FORCED") Fixes: a2fa0aede07c ("[SCSI] zfcp: Block FC transport rports early on errors") Fixes: 5f852be9e11d ("[SCSI] zfcp: Fix deadlock between zfcp ERP and SCSI") Fixes: 338151e06608 ("[SCSI] zfcp: make use of fc_remote_port_delete when target port is unavailable") Fixes: 3859f6a248cb ("[PATCH] zfcp: add rports to enable scsi_add_device to work again") Reviewed-by: Benjamin Block Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 06b13dc3673cc46b7bb83aee5e2582360c9ab702 Author: Steffen Maier Date: Wed Aug 10 18:30:45 2016 +0200 zfcp: fix ELS/GS request&response length for hardware data router commit 70369f8e15b220f50a16348c79a61d3f7054813c upstream. In the hardware data router case, introduced with kernel 3.2 commit 86a9668a8d29 ("[SCSI] zfcp: support for hardware data router") the ELS/GS request&response length needs to be initialized as in the chained SBAL case. Otherwise, the FCP channel rejects ELS requests with FSF_REQUEST_SIZE_TOO_LARGE. Such ELS requests can be issued by user space through BSG / HBA API, or zfcp itself uses ADISC ELS for remote port link test on RSCN. The latter can cause a short path outage due to unnecessary remote target port recovery because the always failing ADISC cannot detect extremely short path interruptions beyond the local FCP channel. Below example is decoded with zfcpdbf from s390-tools: Timestamp : ... Area : SAN Subarea : 00 Level : 1 Exception : - CPU id : .. Caller : zfcp_dbf_san_req+0408 Record id : 1 Tag : fssels1 Request id : 0x Destination ID : 0x00 Payload info : 52000000 00000000 [ADISC] 00 00000000 00000000 00000000 00000000 00000000 Timestamp : ... Area : HBA Subarea : 00 Level : 1 Exception : - CPU id : .. Caller : zfcp_dbf_hba_fsf_res+0740 Record id : 1 Tag : fs_ferr Request id : 0x Request status : 0x00000010 FSF cmnd : 0x0000000b [FSF_QTCB_SEND_ELS] FSF sequence no: 0x... FSF issued : ... FSF stat : 0x00000061 [FSF_REQUEST_SIZE_TOO_LARGE] FSF stat qual : 00000000 00000000 00000000 00000000 Prot stat : 0x00000100 Prot stat qual : 00000000 00000000 00000000 00000000 Signed-off-by: Steffen Maier Fixes: 86a9668a8d29 ("[SCSI] zfcp: support for hardware data router") Reviewed-by: Benjamin Block Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit d40baef91213137d2fcee046ad6cf1dadaed632f Author: Steffen Maier Date: Wed Aug 10 18:30:44 2016 +0200 zfcp: fix fc_host port_type with NPIV commit bd77befa5bcff8c51613de271913639edf85fbc2 upstream. For an NPIV-enabled FCP device, zfcp can erroneously show "NPort (fabric via point-to-point)" instead of "NPIV VPORT" for the port_type sysfs attribute of the corresponding fc_host. s390-tools that can be affected are dbginfo.sh and ziomon. zfcp_fsf_exchange_config_evaluate() ignores fsf_qtcb_bottom_config.connection_features indicating NPIV and only sets fc_host_port_type to FC_PORTTYPE_NPORT if fsf_qtcb_bottom_config.fc_topology is FSF_TOPO_FABRIC. Only the independent zfcp_fsf_exchange_port_evaluate() evaluates connection_features to overwrite fc_host_port_type to FC_PORTTYPE_NPIV in case of NPIV. Code was introduced with upstream kernel 2.6.30 commit 0282985da5923fa6365adcc1a1586ae0c13c1617 ("[SCSI] zfcp: Report fc_host_port_type as NPIV"). This works during FCP device recovery (such as set online) because it performs FSF_QTCB_EXCHANGE_CONFIG_DATA followed by FSF_QTCB_EXCHANGE_PORT_DATA in sequence. However, the zfcp-specific scsi host sysfs attributes "requests", "megabytes", or "seconds_active" trigger only zfcp_fsf_exchange_config_evaluate() resetting fc_host port_type to FC_PORTTYPE_NPORT despite NPIV. The zfcp-specific scsi host sysfs attribute "utilization" triggers only zfcp_fsf_exchange_port_evaluate() correcting the fc_host port_type again in case of NPIV. Evaluate fsf_qtcb_bottom_config.connection_features in zfcp_fsf_exchange_config_evaluate() where it belongs to. Signed-off-by: Steffen Maier Fixes: 0282985da592 ("[SCSI] zfcp: Report fc_host_port_type as NPIV") Reviewed-by: Benjamin Block Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 51f3bab53276ea760b4fe552d5427939ea08ef0d Author: Richard Weinberger Date: Wed Aug 24 14:36:13 2016 +0200 ubi: Deal with interrupted erasures in WL commit 2365418879e9abf12ea9def7f9f3caf0dfa7ffb0 upstream. When Fastmap is used we can face here an -EBADMSG since Fastmap cannot know about unmaps. If the erasure was interrupted the PEB may show ECC errors and UBI would go to ro-mode as it assumes that the PEB was check during attach time, which is not the case with Fastmap. Fixes: dbb7d2a88d ("UBI: Add fastmap core") Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit bc76783dfb2d29b6fbe9cd403c3209ef437535de Author: Steve Wise Date: Thu Sep 29 07:31:33 2016 -0700 IB/core: correctly handle rdma_rw_init_mrs() failure commit b6bc1c731f0b985e91f618561fc82c6e252dfaf4 upstream. Function ib_create_qp() was failing to return an error when rdma_rw_init_mrs() fails, causing a crash further down in ib_create_qp() when trying to dereferece the qp pointer which was actually a negative errno. The crash: crash> log|grep BUG [ 136.458121] BUG: unable to handle kernel NULL pointer dereference at 0000000000000098 crash> bt PID: 3736 TASK: ffff8808543215c0 CPU: 2 COMMAND: "kworker/u64:2" #0 [ffff88084d323340] machine_kexec at ffffffff8105fbb0 #1 [ffff88084d3233b0] __crash_kexec at ffffffff81116758 #2 [ffff88084d323480] crash_kexec at ffffffff8111682d #3 [ffff88084d3234b0] oops_end at ffffffff81032bd6 #4 [ffff88084d3234e0] no_context at ffffffff8106e431 #5 [ffff88084d323530] __bad_area_nosemaphore at ffffffff8106e610 #6 [ffff88084d323590] bad_area_nosemaphore at ffffffff8106e6f4 #7 [ffff88084d3235a0] __do_page_fault at ffffffff8106ebdc #8 [ffff88084d323620] do_page_fault at ffffffff8106f057 #9 [ffff88084d323660] page_fault at ffffffff816e3148 [exception RIP: ib_create_qp+427] RIP: ffffffffa02554fb RSP: ffff88084d323718 RFLAGS: 00010246 RAX: 0000000000000004 RBX: fffffffffffffff4 RCX: 000000018020001f RDX: ffff880830997fc0 RSI: 0000000000000001 RDI: ffff88085f407200 RBP: ffff88084d323778 R8: 0000000000000001 R9: ffffea0020bae210 R10: ffffea0020bae218 R11: 0000000000000001 R12: ffff88084d3237c8 R13: 00000000fffffff4 R14: ffff880859fa5000 R15: ffff88082eb89800 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #10 [ffff88084d323780] rdma_create_qp at ffffffffa0782681 [rdma_cm] #11 [ffff88084d3237b0] nvmet_rdma_create_queue_ib at ffffffffa07c43f3 [nvmet_rdma] #12 [ffff88084d323860] nvmet_rdma_alloc_queue at ffffffffa07c5ba9 [nvmet_rdma] #13 [ffff88084d323900] nvmet_rdma_queue_connect at ffffffffa07c5c96 [nvmet_rdma] #14 [ffff88084d323980] nvmet_rdma_cm_handler at ffffffffa07c6450 [nvmet_rdma] #15 [ffff88084d3239b0] iw_conn_req_handler at ffffffffa0787480 [rdma_cm] #16 [ffff88084d323a60] cm_conn_req_handler at ffffffffa0775f06 [iw_cm] #17 [ffff88084d323ab0] process_event at ffffffffa0776019 [iw_cm] #18 [ffff88084d323af0] cm_work_handler at ffffffffa0776170 [iw_cm] #19 [ffff88084d323cb0] process_one_work at ffffffff810a1483 #20 [ffff88084d323d90] worker_thread at ffffffff810a211d #21 [ffff88084d323ec0] kthread at ffffffff810a6c5c #22 [ffff88084d323f50] ret_from_fork at ffffffff816e1ebf Fixes: 632bc3f65081 ("IB/core, RDMA RW API: Do not exceed QP SGE send limit") Signed-off-by: Steve Wise Reviewed-by: Bart Van Assche Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 9d57a641c4ece9965e022bd6be117202a06c5980 Author: Bart Van Assche Date: Mon Sep 26 12:58:49 2016 -0700 IB/srp: Fix infinite loop when FMR sg[0].offset != 0 commit 681cc3608355737c1effebc8145f95c8c3344bc3 upstream. Avoid that mapping an sg-list in which the first element has a non-zero offset triggers an infinite loop when using FMR. This patch makes the FMR mapping code similar to that of ib_sg_to_pages(). Note: older Mellanox HCAs do not support non-zero offsets for FMR. See also commit 8c4037b501ac ("IB/srp: always avoid non-zero offsets into an FMR"). Reported-by: Alex Estrin Signed-off-by: Bart Van Assche Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 14ec354717bc99689026ebaa848bff08e30e3443 Author: Michael Ellerman Date: Tue Oct 11 21:15:04 2016 +1100 powerpc/mm/hash64: Fix might_have_hea() check commit 08bf75ba852ef8304a84b6a030466b4b4850382e upstream. In commit 2b4e3ad8f579 ("powerpc/mm/hash64: Don't test for machine type to detect HEA special case") we changed the logic in might_have_hea() to check FW_FEATURE_SPLPAR rather than machine_is(pseries). However the check was incorrectly negated, leading to crashes on machines with HEA adapters, such as: mm: Hashing failure ! EA=0xd000080080004040 access=0x800000000000000e current=NetworkManager trap=0x300 vsid=0x13d349c ssize=1 base psize=2 psize 2 pte=0xc0003cc033e701ae Unable to handle kernel paging request for data at address 0xd000080080004040 Call Trace: .ehea_create_cq+0x148/0x340 [ehea] (unreliable) .ehea_up+0x258/0x1200 [ehea] .ehea_open+0x44/0x1a0 [ehea] ... Fix it by removing the negation. Fixes: 2b4e3ad8f579 ("powerpc/mm/hash64: Don't test for machine type to detect HEA special case") Reported-by: Denis Kirjanov Reported-by: Jan Stancek Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 67b098d08f5a0d13c915cf2575ced300bc224e0a Author: Laurent Dufour Date: Thu Oct 6 15:33:21 2016 +0200 powerpc/pseries: Fix stack corruption in htpe code commit 05af40e885955065aee8bb7425058eb3e1adca08 upstream. This commit fixes a stack corruption in the pseries specific code dealing with the huge pages. In __pSeries_lpar_hugepage_invalidate() the buffer used to pass arguments to the hypervisor is not large enough. This leads to a stack corruption where a previously saved register could be corrupted leading to unexpected result in the caller, like the following panic: Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=2048 NUMA pSeries Modules linked in: virtio_balloon ip_tables x_tables autofs4 virtio_blk 8139too virtio_pci virtio_ring 8139cp virtio CPU: 11 PID: 1916 Comm: mmstress Not tainted 4.8.0 #76 task: c000000005394880 task.stack: c000000005570000 NIP: c00000000027bf6c LR: c00000000027bf64 CTR: 0000000000000000 REGS: c000000005573820 TRAP: 0300 Not tainted (4.8.0) MSR: 8000000000009033 CR: 84822884 XER: 20000000 CFAR: c00000000010a924 DAR: 420000000014e5e0 DSISR: 40000000 SOFTE: 1 GPR00: c00000000027bf64 c000000005573aa0 c000000000e02800 c000000004447964 GPR04: c00000000404de18 c000000004d38810 00000000042100f5 00000000f5002104 GPR08: e0000000f5002104 0000000000000001 042100f5000000e0 00000000042100f5 GPR12: 0000000000002200 c00000000fe02c00 c00000000404de18 0000000000000000 GPR16: c1ffffffffffe7ff 00003fff62000000 420000000014e5e0 00003fff63000000 GPR20: 0008000000000000 c0000000f7014800 0405e600000000e0 0000000000010000 GPR24: c000000004d38810 c000000004447c10 c00000000404de18 c000000004447964 GPR28: c000000005573b10 c000000004d38810 00003fff62000000 420000000014e5e0 NIP [c00000000027bf6c] zap_huge_pmd+0x4c/0x470 LR [c00000000027bf64] zap_huge_pmd+0x44/0x470 Call Trace: [c000000005573aa0] [c00000000027bf64] zap_huge_pmd+0x44/0x470 (unreliable) [c000000005573af0] [c00000000022bbd8] unmap_page_range+0xcf8/0xed0 [c000000005573c30] [c00000000022c2d4] unmap_vmas+0x84/0x120 [c000000005573c80] [c000000000235448] unmap_region+0xd8/0x1b0 [c000000005573d80] [c0000000002378f0] do_munmap+0x2d0/0x4c0 [c000000005573df0] [c000000000237be4] SyS_munmap+0x64/0xb0 [c000000005573e30] [c000000000009560] system_call+0x38/0x108 Instruction dump: fbe1fff8 fb81ffe0 7c7f1b78 7ca32b78 7cbd2b78 f8010010 7c9a2378 f821ffb1 7cde3378 4bfffea9 7c7b1b79 41820298 48000130 7fa5eb78 7fc4f378 Most of the time, the bug is surfacing in a caller up in the stack from __pSeries_lpar_hugepage_invalidate() which is quite confusing. This bug is pending since v3.11 but was hidden if a caller of the caller of __pSeries_lpar_hugepage_invalidate() has pushed the corruped register (r18 in this case) in the stack and is not using it until restoring it. GCC 6.2.0 seems to raise it more frequently. This commit also change the definition of the parameter buffer in pSeries_lpar_flush_hash_range() to rely on the global define PLPAR_HCALL9_BUFSIZE (no functional change here). Fixes: 1a5272866f87 ("powerpc: Optimize hugepage invalidate") Signed-off-by: Laurent Dufour Reviewed-by: Aneesh Kumar K.V Acked-by: Balbir Singh Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 4b73efd467b57526f6022d9d2d628c948c683045 Author: Paul Mackerras Date: Tue Oct 11 22:25:47 2016 +1100 powerpc/64: Fix incorrect return value from __copy_tofrom_user commit 1a34439e5a0b2235e43f96816dbb15ee1154f656 upstream. Debugging a data corruption issue with virtio-net/vhost-net led to the observation that __copy_tofrom_user was occasionally returning a value 16 larger than it should. Since the return value from __copy_tofrom_user is the number of bytes not copied, this means that __copy_tofrom_user can occasionally return a value larger than the number of bytes it was asked to copy. In turn this can cause higher-level copy functions such as copy_page_to_iter_iovec to corrupt memory by copying data into the wrong memory locations. It turns out that the failing case involves a fault on the store at label 79, and at that point the first unmodified byte of the destination is at R3 + 16. Consequently the exception handler for that store needs to add 16 to R3 before using it to work out how many bytes were not copied, but in this one case it was not adding the offset to R3. To fix it, this moves the label 179 to the point where we add 16 to R3. I have checked manually all the exception handlers for the loads and stores in this code and the rest of them are correct (it would be excellent to have an automated test of all the exception cases). This bug has been present since this code was initially committed in May 2002 to Linux version 2.5.20. Signed-off-by: Paul Mackerras Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 9f04abc4e4f4f0a1f443362e612bcd5f670787ad Author: Aneesh Kumar K.V Date: Mon Sep 19 23:01:33 2016 +0530 powerpc/mm: Update FORCE_MAX_ZONEORDER range to allow hugetlb w/4K commit d5a1e42cb4be016a45a787953dd70c3bc4509da5 upstream. For hugetlb to work with 4K page size, we need MAX_ORDER to be 13 or more. When switching from a 64K page size to 4K linux page size using make oldconfig, we end up with a CONFIG_FORCE_MAX_ZONEORDER value of 9. This results in a 16M hugepage beiing considered as a gigantic huge page which in turn results in failure to setup hugepages if gigantic hugepage support is not enabled. This also results in kernel crash with 4K radix configuration. We hit the below BUG_ON on radix: kernel BUG at mm/huge_memory.c:364! Oops: Exception in kernel mode, sig: 5 [#1] SMP NR_CPUS=2048 NUMA PowerNV CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc1-00006-gbae9cc6 #1 task: c0000000f1af8000 task.stack: c0000000f1aec000 NIP: c000000000c5fa0c LR: c000000000c5f9d8 CTR: c000000000c5f9a4 REGS: c0000000f1aef920 TRAP: 0700 Not tainted (4.8.0-rc1-00006-gbae9cc6) MSR: 9000000102029033 CR: 24000844 XER: 00000000 CFAR: c000000000c5f9e0 SOFTE: 1 .... NIP [c000000000c5fa0c] hugepage_init+0x68/0x238 LR [c000000000c5f9d8] hugepage_init+0x34/0x238 Fixes: a7ee539584acf ("powerpc/Kconfig: Update config option based on page size") Reported-by: Santhosh Signed-off-by: Aneesh Kumar K.V Acked-by: Balbir Singh Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 0ce9561f9db5f2f506a1b37e7fadb590c583ae8f Author: Gavin Shan Date: Tue Aug 2 14:10:32 2016 +1000 powerpc/powernv: Use CPU-endian PEST in pnv_pci_dump_p7ioc_diag_data() commit 5adaf8629b193f185ca5a1665b9e777a0579f518 upstream. This fixes the warnings reported from sparse: pci.c:312:33: warning: restricted __be64 degrades to integer pci.c:313:33: warning: restricted __be64 degrades to integer Fixes: cee72d5bb489 ("powerpc/powernv: Display diag data on p7ioc EEH errors") Signed-off-by: Gavin Shan Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit b6755b85fa8ccff46ad5230c4b595fd6d4ff8312 Author: Gavin Shan Date: Tue Aug 2 14:10:30 2016 +1000 powerpc/powernv: Use CPU-endian hub diag-data type in pnv_eeh_get_and_dump_hub_diag() commit a7032132d7560a8434e1f54b71efd7fa20f073bd upstream. The hub diag-data type is filled with big-endian data by OPAL call opal_pci_get_hub_diag_data(). We need convert it to CPU-endian value before using it. The issue is reported by sparse as pointed by Michael Ellerman: eeh-powernv.c:1309:21: warning: restricted __be16 degrades to integer This converts hub diag-data type to CPU-endian before using it in pnv_eeh_get_and_dump_hub_diag(). Fixes: 2a485ad7c88d ("powerpc/powernv: Drop PHB operation next_error()") Suggested-by: Michael Ellerman Signed-off-by: Gavin Shan Reviewed-by: Russell Currey Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 99e4d3ddb6782e126a87dfcda48ecd4d1e11cb06 Author: Russell Currey Date: Mon Sep 12 14:17:22 2016 +1000 powerpc/eeh: Null check uses of eeh_pe_bus_get commit 04fec21c06e35b169a83e75a84a015ab4606bf5e upstream. eeh_pe_bus_get() can return NULL if a PCI bus isn't found for a given PE. Some callers don't check this, and can cause a null pointer dereference under certain circumstances. Fix this by checking NULL everywhere eeh_pe_bus_get() is called. Fixes: 8a6b1bc70dbb ("powerpc/eeh: EEH core to handle special event") Signed-off-by: Russell Currey Reviewed-by: Andrew Donnellan Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 45b2b0cea8e5244e22bfa964625cd6964ef17fec Author: Gavin Shan Date: Tue Aug 2 14:10:29 2016 +1000 powerpc/powernv: Pass CPU-endian PE number to opal_pci_eeh_freeze_clear() commit d63e51b31e0b655ed0f581b8a8fd4c4b4f8d1919 upstream. The PE number (@frozen_pe_no), filled by opal_pci_next_error() is in big-endian format. It should be converted to CPU-endian before it is passed to opal_pci_eeh_freeze_clear() when clearing the frozen state if the PE is invalid one. As Michael Ellerman pointed out, the issue is also detected by sparse: eeh-powernv.c:1541:41: warning: incorrect type in argument 2 (different base types) This passes CPU-endian PE number to opal_pci_eeh_freeze_clear() and it should be part of commit <0f36db77643b> ("powerpc/eeh: Fix wrong printed PE number"), which was merged to 4.3 kernel. Fixes: 71b540adffd9 ("powerpc/powernv: Don't escalate non-existing frozen PE") Suggested-by: Paul Mackerras Signed-off-by: Gavin Shan Reviewed-by: Russell Currey Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 33b094fa2450e777bc49b466a8d258e06d7991eb Author: Anton Blanchard Date: Sun Sep 25 17:16:53 2016 +1000 powerpc/vdso64: Use double word compare on pointers commit 5045ea37377ce8cca6890d32b127ad6770e6dce5 upstream. __kernel_get_syscall_map() and __kernel_clock_getres() use cmpli to check if the passed in pointer is non zero. cmpli maps to a 32 bit compare on binutils, so we ignore the top 32 bits. A simple test case can be created by passing in a bogus pointer with the bottom 32 bits clear. Using a clk_id that is handled by the VDSO, then one that is handled by the kernel shows the problem: printf("%d\n", clock_getres(CLOCK_REALTIME, (void *)0x100000000)); printf("%d\n", clock_getres(CLOCK_BOOTTIME, (void *)0x100000000)); And we get: 0 -1 The bigger issue is if we pass a valid pointer with the bottom 32 bits clear, in this case we will return success but won't write any data to the pointer. I stumbled across this issue because the LLVM integrated assembler doesn't accept cmpli with 3 arguments. Fix this by converting them to cmpldi. Fixes: a7f290dad32e ("[PATCH] powerpc: Merge vdso's and add vdso support to 32 bits kernel") Signed-off-by: Anton Blanchard Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit ed04eda809930530e8900928d490eee4c67b9212 Author: Michael Ellerman Date: Fri Sep 9 14:01:07 2016 +1000 powerpc/xmon: Don't use ld on 32-bit commit b42d9023a31e384504f5b53fc9a437d5536a3f63 upstream. In commit 31cdd0c39c75 ("powerpc/xmon: Fix SPR read/write commands and add command to dump SPRs") I added two uses of the "ld" instruction in spr_access.S. "ld" is a 64-bit instruction, so shouldn't be used on 32-bit CPUs. Replace it with PPC_LL which is a macro that gives us either "ld" or "lwz" depending on whether we're 64 or 32-bit. Fixes: 31cdd0c39c75 ("powerpc/xmon: Fix SPR read/write commands and add command to dump SPRs") Reported-by: John Paul Adrian Glaubitz Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit acc97010548c073ccfc4f68073bd22fc65d1cab6 Author: Rabin Vincent Date: Wed Sep 21 16:22:29 2016 +0200 dm crypt: fix crash on exit commit f659b10087daaf4ce0087c3f6aec16746be9628f upstream. As the documentation for kthread_stop() says, "if threadfn() may call do_exit() itself, the caller must ensure task_struct can't go away". dm-crypt does not ensure this and therefore crashes when crypt_dtr() calls kthread_stop(). The crash is trivially reproducible by adding a delay before the call to kthread_stop() and just opening and closing a dm-crypt device. general protection fault: 0000 [#1] PREEMPT SMP CPU: 0 PID: 533 Comm: cryptsetup Not tainted 4.8.0-rc7+ #7 task: ffff88003bd0df40 task.stack: ffff8800375b4000 RIP: 0010: kthread_stop+0x52/0x300 Call Trace: crypt_dtr+0x77/0x120 dm_table_destroy+0x6f/0x120 __dm_destroy+0x130/0x250 dm_destroy+0x13/0x20 dev_remove+0xe6/0x120 ? dev_suspend+0x250/0x250 ctl_ioctl+0x1fc/0x530 ? __lock_acquire+0x24f/0x1b10 dm_ctl_ioctl+0x13/0x20 do_vfs_ioctl+0x91/0x6a0 ? ____fput+0xe/0x10 ? entry_SYSCALL_64_fastpath+0x5/0xbd ? trace_hardirqs_on_caller+0x151/0x1e0 SyS_ioctl+0x41/0x70 entry_SYSCALL_64_fastpath+0x1f/0xbd This problem was introduced by bcbd94ff481e ("dm crypt: fix a possible hang due to race condition on exit"). Looking at the description of that patch (excerpted below), it seems like the problem it addresses can be solved by just using set_current_state instead of __set_current_state, since we obviously need the memory barrier. | dm crypt: fix a possible hang due to race condition on exit | | A kernel thread executes __set_current_state(TASK_INTERRUPTIBLE), | __add_wait_queue, spin_unlock_irq and then tests kthread_should_stop(). | It is possible that the processor reorders memory accesses so that | kthread_should_stop() is executed before __set_current_state(). If | such reordering happens, there is a possible race on thread | termination: [...] So this patch just reverts the aforementioned patch and changes the __set_current_state(TASK_INTERRUPTIBLE) to set_current_state(...). This fixes the crash and should also fix the potential hang. Fixes: bcbd94ff481e ("dm crypt: fix a possible hang due to race condition on exit") Cc: Mikulas Patocka Signed-off-by: Rabin Vincent Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit df5c2ee063903af62f5126e085e5c25de9fb4d7d Author: Mike Snitzer Date: Thu Sep 1 12:06:37 2016 -0400 dm mpath: check if path's request_queue is dying in activate_path() commit f10e06b744074824fb8ec7066bc03ecc90918f5b upstream. If pg_init_retries is set and a request is queued against a multipath device with all underlying block device request_queues in the "dying" state then an infinite loop is triggered because activate_path() never succeeds and hence never calls pg_init_done(). This change avoids that device removal triggers an infinite loop by failing the activate_path() which causes the "dying" path to be failed. Reported-by: Bart Van Assche Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 4a48b94239422c2c3c89b79dbbc39a1e2981babb Author: Mike Snitzer Date: Thu Sep 1 11:59:33 2016 -0400 dm rq: take request_queue lock while clearing QUEUE_FLAG_STOPPED commit 9dbeaeabacb26260d1621fe58f0f6fdedc8860d4 upstream. Every call of queue_flag_clear_unlocked() after block device initialization has finished is wrong if blk_cleanup_queue() can be called concurrently. Convert queue_flag_clear_unlocked() into queue_flag_clear() and protect it by the block layer queue lock. Also, factor out dm_mq_start_queue(). Reported-by: Bart Van Assche Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 35f46e73b6a00b5be185eed691613ba0ba54c6ed Author: Minfei Huang Date: Tue Sep 6 16:00:29 2016 +0800 dm: return correct error code in dm_resume()'s retry loop commit 8dc23658b7aaa8b6b0609c81c8ad75e98b612801 upstream. dm_resume() will return success (0) rather than -EINVAL if !dm_suspended_md() upon retry within dm_resume(). Reset the error code at the start of dm_resume()'s retry loop. Also, remove a useless assignment at the end of dm_resume(). Fixes: ffcc393641 ("dm: enhance internal suspend and resume interface") Signed-off-by: Minfei Huang Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit f8ce90291d3b3e50c7044c98c07e102e70d51181 Author: Bart Van Assche Date: Wed Aug 31 15:17:49 2016 -0700 dm: mark request_queue dead before destroying the DM device commit 3b785fbcf81c3533772c52b717f77293099498d3 upstream. This avoids that new requests are queued while __dm_destroy() is in progress. Signed-off-by: Bart Van Assche Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 171159e08f8f5055f8ad861a621d5535b72b3ef1 Author: Adrian Hunter Date: Wed Sep 28 14:41:36 2016 +0300 perf intel-pt: Fix MTC timestamp calculation for large MTC periods commit 3bccbe20f6d188ce7b00326e776b745cfd35b10a upstream. The MTC packet provides a 8-bit slice of CTC which is related to TSC by the TMA packet, however the TMA packet only provides the lower 16 bits of CTC. If mtc_shift > 8 then some of the MTC bits are not in the CTC provided by the TMA packet. Fix-up the last_mtc calculated from the TMA packet by copying the missing bits from the current MTC assuming the least difference between the two, and that the current MTC comes after last_mtc. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Link: http://lkml.kernel.org/r/1475062896-22274-2-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit dab15533be0cad71550c8276e2a0aba6b965b7a2 Author: Adrian Hunter Date: Wed Sep 28 14:41:35 2016 +0300 perf intel-pt: Fix estimated timestamps for cycle-accurate mode commit 51ee6481fa8e879cc942bcc1b0af713e158b7a98 upstream. In cycle-accurate mode, timestamps can be calculated from CYC packets. The decoder also estimates timestamps based on the number of instructions since the last timestamp. For that to work in cycle-accurate mode, the instruction count needs to be reset to zero when a timestamp is calculated from a CYC packet, but that wasn't happening, so fix it. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Link: http://lkml.kernel.org/r/1475062896-22274-1-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 1f7958109a19db599e668a6105bd173f12a441df Author: Adrian Hunter Date: Fri Sep 23 17:38:41 2016 +0300 perf intel-pt: Fix snapshot overlap detection decoder errors commit 810c398bc09b2f2dfde52a7d2483a710612c5fb8 upstream. Fix occasional decoder errors decoding trace data collected in snapshot mode. Snapshot mode can take successive snapshots of trace which might overlap. The decoder checks whether there is an overlap but only looks at the current and previous buffer. However buffers that do not contain synchronization (i.e. PSB) packets cannot be decoded or used for overlap checking. That means the decoder actually needs to check overlaps between the current buffer and the previous buffer that contained usable data. Make that change. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Mathieu Poirier Link: http://lkml.kernel.org/r/1474641528-18776-10-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit e5f8b2ed954d897f430a031bb03cfaec8a8dc2d5 Author: Andrew Bresticker Date: Mon Feb 15 09:19:49 2016 +0100 pstore/ram: Use memcpy_fromio() to save old buffer commit d771fdf94180de2bd811ac90cba75f0f346abf8d upstream. The ramoops buffer may be mapped as either I/O memory or uncached memory. On ARM64, this results in a device-type (strongly-ordered) mapping. Since unnaligned accesses to device-type memory will generate an alignment fault (regardless of whether or not strict alignment checking is enabled), it is not safe to use memcpy(). memcpy_fromio() is guaranteed to only use aligned accesses, so use that instead. Signed-off-by: Andrew Bresticker Signed-off-by: Enric Balletbo Serra Reviewed-by: Puneet Kumar Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit 504c848749428aa3450075b8535885140e189589 Author: Furquan Shaikh Date: Mon Feb 15 09:19:48 2016 +0100 pstore/ram: Use memcpy_toio instead of memcpy commit 7e75678d23167c2527e655658a8ef36a36c8b4d9 upstream. persistent_ram_update uses vmap / iomap based on whether the buffer is in memory region or reserved region. However, both map it as non-cacheable memory. For armv8 specifically, non-cacheable mapping requests use a memory type that has to be accessed aligned to the request size. memcpy() doesn't guarantee that. Signed-off-by: Furquan Shaikh Signed-off-by: Enric Balletbo Serra Reviewed-by: Aaron Durbin Reviewed-by: Olof Johansson Tested-by: Furquan Shaikh Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit 71bba4ad9d11d725f4e216bf71021932778512d3 Author: Sebastian Andrzej Siewior Date: Thu Sep 8 13:48:06 2016 +0200 pstore/core: drop cmpxchg based updates commit d5a9bf0b38d2ac85c9a693c7fb851f74fd2a2494 upstream. I have here a FPGA behind PCIe which exports SRAM which I use for pstore. Now it seems that the FPGA no longer supports cmpxchg based updates and writes back 0xff…ff and returns the same. This leads to crash during crash rendering pstore useless. Since I doubt that there is much benefit from using cmpxchg() here, I am dropping this atomic access and use the spinlock based version. Cc: Anton Vorontsov Cc: Colin Cross Cc: Kees Cook Cc: Tony Luck Cc: Rabin Vincent Tested-by: Rabin Vincent Signed-off-by: Sebastian Andrzej Siewior Reviewed-by: Guenter Roeck [kees: remove "_locked" suffix since it's the only option now] Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit f33909bb21252e3c93876feb5bc28f0d33bf0ac9 Author: Sebastian Andrzej Siewior Date: Thu Sep 8 13:48:05 2016 +0200 pstore/ramoops: fixup driver removal commit 4407de74df18ed405cc5998990004c813ccfdbde upstream. A basic rmmod ramoops segfaults. Let's see why. Since commit 34f0ec82e0a9 ("pstore: Correct the max_dump_cnt clearing of ramoops") sets ->max_dump_cnt to zero before looping over ->przs but we didn't use it before that either. And since commit ee1d267423a1 ("pstore: add pstore unregister") we free that memory on rmmod. But even then, we looped until a NULL pointer or ERR. I don't see where it is ensured that the last member is NULL. Let's try this instead: simply error recovery and free. Clean up in error case where resources were allocated. And then, in the free path, rely on ->max_dump_cnt in the free path. Cc: Anton Vorontsov Cc: Colin Cross Cc: Kees Cook Cc: Tony Luck Cc: Namhyung Kim Acked-by: Namhyung Kim Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit ba28eebf4164fb05c4778ea0612c1e95b6cef45d Author: Helge Deller Date: Sun Oct 9 09:57:54 2016 +0200 parisc: Increase initial kernel mapping size commit 65bf34f59594c11f13d371c5334a6a0a385cd7ae upstream. Increase the initial kernel default page mapping size for 64-bit kernels to 64 MB and for 32-bit kernels to 32 MB. Due to the additional support of ftrace, tracepoint and huge pages the kernel size can exceed the sizes we used up to now. Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 5112972e37079b54fbee64d35015d70e28576474 Author: Helge Deller Date: Sun Oct 9 11:12:34 2016 +0200 parisc: Fix kernel memory layout regarding position of __gp commit f8850abb7ba68229838014b3409460e576751c6d upstream. Architecturally we need to keep __gp below 0x1000000. But because of ftrace and tracepoint support, the RO_DATA_SECTION now gets much bigger than it was before. By moving the linkage tables before RO_DATA_SECTION we can avoid that __gp gets positioned at a too high address. Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit c82eadf0401607aea969fcf7d48fe66172d7d995 Author: Helge Deller Date: Sat Sep 24 22:22:12 2016 +0200 parisc: Fix self-detected CPU stall warnings on Mako machines commit 92420bd0d01f040bbf754e1d090be49ca6a1c8d6 upstream. The config option HAVE_UNSTABLE_SCHED_CLOCK is set automatically when compiling for SMP. There is no need to clear the stable-clock flag via clear_sched_clock_stable() when starting secondary CPUs, and even worse, clearing it triggers wrong self-detected CPU stall warnings on 64bit Mako machines. Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 97f1848f46ec2217a1814614aea31e169a78cdbb Author: Helge Deller Date: Fri Oct 7 18:19:55 2016 +0200 parisc: Increase KERNEL_INITIAL_SIZE for 32-bit SMP kernels commit 690d097c00c88fa9d93d198591e184164b1d8c20 upstream. Increase the initial kernel default page mapping size for SMP kernels to 32MB and add a runtime check which panics early if the kernel is bigger than the initial mapping size. This fixes boot crashes of 32bit SMP kernels. Due to the introduction of huge page support in kernel 4.4 and it's required initial kernel layout in memory, a 32bit SMP kernel usually got bigger (in layout, not size) than 16MB. Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 73fe3f93108a39d2b353569fbfc96cfbf2b2657a Author: Sergey Senozhatsky Date: Tue Oct 18 00:41:12 2016 +0900 cpufreq: fix overflow in cpufreq_table_find_index_dl() commit c6fe46a79ecd79606bb96fada4515f6b23f87b62 upstream. 'best' is always less or equals to 'pos', so `best - pos' returns a negative value which is then getting casted to `unsigned int' and passed to __cpufreq_driver_target()->acpi_cpufreq_target() for policy->freq_table selection. This results in BUG: unable to handle kernel paging request at ffff881019b469f8 IP: [] acpi_cpufreq_target+0x4f/0x190 [acpi_cpufreq] PGD 267f067 PUD 0 Oops: 0000 [#1] PREEMPT SMP CPU: 6 PID: 70 Comm: kworker/6:1 Not tainted 4.9.0-rc1-next-20161017-dbg-dirty Workqueue: events dbs_work_handler task: ffff88041b808000 task.stack: ffff88041b810000 RIP: 0010:[] [] acpi_cpufreq_target+0x4f/0x190 [acpi_cpufreq] RSP: 0018:ffff88041b813c60 EFLAGS: 00010282 RAX: ffff880419b46a00 RBX: ffff88041b848400 RCX: ffff880419b20f80 RDX: 00000000001dff38 RSI: 00000000ffffffff RDI: ffff88041b848400 RBP: ffff88041b813cb0 R08: 0000000000000006 R09: 0000000000000040 R10: ffffffff8207f9e0 R11: ffffffff8173595b R12: 0000000000000000 R13: ffff88041f1dff38 R14: 0000000000262900 R15: 0000000bfffffff4 FS: 0000000000000000(0000) GS:ffff88041f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff881019b469f8 CR3: 000000041a2d3000 CR4: 00000000001406e0 Stack: ffff88041b813cb0 ffffffff813347f9 ffff88041b813ca0 ffffffff81334663 ffff88041f1d4bc0 ffff88041b848400 0000000000000000 0000000000000000 0000000000262900 0000000000000000 ffff88041b813d00 ffffffff813355dc Call Trace: [] ? cpufreq_freq_transition_begin+0xf1/0xfc [] ? get_cpu_idle_time+0x97/0xa6 [] __cpufreq_driver_target+0x3b6/0x44e [] cs_dbs_timer+0x11a/0x135 [] dbs_work_handler+0x39/0x62 [] process_one_work+0x280/0x4a5 [] worker_thread+0x24f/0x397 [] ? rescuer_thread+0x30b/0x30b [] ? nl80211_get_key+0x29/0x36a [] kthread+0xfc/0x104 [] ? put_lock_stats.isra.9+0xe/0x20 [] ? kthread_create_on_node+0x3f/0x3f [] ret_from_fork+0x22/0x30 Code: 56 4d 6b ff 0c 41 55 41 54 53 48 83 ec 28 48 8b 15 ad 1e 00 00 44 8b 41 08 48 8b 87 c8 00 00 00 49 89 d5 4e 03 2c c5 80 b2 78 81 <46> 8b 74 38 04 45 3b 75 00 75 11 31 c0 83 39 00 0f 84 1c 01 00 RIP [] acpi_cpufreq_target+0x4f/0x190 [acpi_cpufreq] RSP CR2: ffff881019b469f8 ---[ end trace 16d9fc7a17897d37 ]--- [ rjw: In some cases this bug may also cause incorrect frequencies to be selected by cpufreq governors. ] Fixes: 899bb6642f2a (cpufreq: skip invalid entries when searching the frequency) Link: http://marc.info/?l=linux-kernel&m=147672030714331&w=2 Reported-and-tested-by: Sedat Dilek Reported-and-tested-by: Jörg Otte Signed-off-by: Sergey Senozhatsky Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit dc04e6ce01005b511a2371726553992f27109f5d Author: Srinivas Pandruvada Date: Sat Oct 8 12:42:38 2016 -0700 cpufreq: intel_pstate: Fix unsafe HWP MSR access commit f9f4872df6e1801572949f8a370c886122d4b6da upstream. This is a requirement that MSR MSR_PM_ENABLE must be set to 0x01 before reading MSR_HWP_CAPABILITIES on a given CPU. If cpufreq init() is scheduled on a CPU which is not same as policy->cpu or migrates to a different CPU before calling msr read for MSR_HWP_CAPABILITIES, it is possible that MSR_PM_ENABLE was not to set to 0x01 on that CPU. This will cause GP fault. So like other places in this path rdmsrl_on_cpu should be used instead of rdmsrl. Moreover the scope of MSR_HWP_CAPABILITIES is on per thread basis, so it should be read from the same CPU, for which MSR MSR_HWP_REQUEST is getting set. dmesg dump or warning: [ 22.014488] WARNING: CPU: 139 PID: 1 at arch/x86/mm/extable.c:50 ex_handler_rdmsr_unsafe+0x68/0x70 [ 22.014492] unchecked MSR access error: RDMSR from 0x771 [ 22.014493] Modules linked in: [ 22.014507] CPU: 139 PID: 1 Comm: swapper/0 Not tainted 4.7.5+ #1 ... ... [ 22.014516] Call Trace: [ 22.014542] [] dump_stack+0x63/0x82 [ 22.014558] [] __warn+0xcb/0xf0 [ 22.014561] [] warn_slowpath_fmt+0x4f/0x60 [ 22.014563] [] ex_handler_rdmsr_unsafe+0x68/0x70 [ 22.014564] [] fixup_exception+0x39/0x50 [ 22.014604] [] do_general_protection+0x80/0x150 [ 22.014610] [] general_protection+0x28/0x30 [ 22.014635] [] ? get_target_pstate_use_performance+0xb0/0xb0 [ 22.014642] [] ? native_read_msr+0x7/0x40 [ 22.014657] [] intel_pstate_hwp_set+0x23/0x130 [ 22.014660] [] intel_pstate_set_policy+0x1b6/0x340 [ 22.014662] [] cpufreq_set_policy+0xeb/0x2c0 [ 22.014664] [] cpufreq_init_policy+0x79/0xe0 [ 22.014666] [] ? cpufreq_update_policy+0x120/0x120 [ 22.014669] [] cpufreq_online+0x406/0x820 [ 22.014671] [] cpufreq_add_dev+0x5f/0x90 [ 22.014717] [] subsys_interface_register+0xb8/0x100 [ 22.014719] [] cpufreq_register_driver+0x14c/0x210 [ 22.014749] [] intel_pstate_init+0x39d/0x4d5 [ 22.014751] [] ? cpufreq_gov_dbs_init+0x12/0x12 Signed-off-by: Srinivas Pandruvada Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 80143d9f6e5c62211b27af2bb703f9a2b40b70c3 Author: Aaro Koskinen Date: Wed Oct 12 08:45:05 2016 +0530 cpufreq: skip invalid entries when searching the frequency commit 899bb6642f2a2f2cd3f77abd6c5a14550e3b37e6 upstream. Skip invalid entries when searching the frequency. This fixes cpufreq at least on loongson2 MIPS board. Fixes: da0c6dc00c69 (cpufreq: Handle sorted frequency tables more efficiently) Signed-off-by: Aaro Koskinen Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 31f4285f3c50de3355fc20a94ca3f7bf390f4506 Author: Rafael J. Wysocki Date: Wed Oct 12 21:47:03 2016 +0200 cpufreq: conservative: Fix next frequency selection commit abb6627910a1e783c8e034b35b7c80e5e7f98f41 upstream. Commit d352cf47d93e (cpufreq: conservative: Do not use transition notifications) overlooked the case when the "frequency step" used by the conservative governor is small relative to the distances between the available frequencies and broke the algorithm by using policy->cur instead of the previously requested frequency when computing the next one. As a result, the governor may not be able to go outside of a narrow range between two consecutive available frequencies. Fix the problem by making the governor save the previously requested frequency and select the next one relative that value (unless it is out of range, in which case policy->cur will be used instead). Fixes: d352cf47d93e (cpufreq: conservative: Do not use transition notifications) Link: https://bugzilla.kernel.org/show_bug.cgi?id=177171 Reported-and-tested-by: Aleksey Rybalkin Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit f33fa3b8e0dcd804f5b6fe8178c1f7b608973b58 Author: Dave Gerlach Date: Wed Sep 14 15:41:37 2016 -0500 cpufreq: ti: Use generic platdev driver commit e01072d22d4e7f9ca966f848def22fe41eaef4de upstream. Now that the cpufreq-dt-platdev is used to create the cpufreq-dt platform device for all OMAP platforms and the platform code that did it before has been removed, add ti,am33xx and ti,dra7xx to the machine list in cpufreq-dt-platdev which had relied on the removed platform code to do this previously. Fixes: 7694ca6e1d6f (cpufreq: omap: Use generic platdev driver) Signed-off-by: Dave Gerlach Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 33fe037cdcac990dffabac804982c9f2e1551888 Author: Sergei Shtylyov Date: Mon Jul 4 01:04:24 2016 +0300 platform: don't return 0 from platform_get_irq[_byname]() on error commit e330b9a6bb35dc7097a4f02cb1ae7b6f96df92af upstream. of_irq_get[_byname]() return 0 iff irq_create_of_mapping() call fails. Returning both error code and 0 on failure is a sign of a misdesigned API, it makes the failure check unnecessarily complex and error prone. We should rely on the platform IRQ resource in this case, not return 0, especially as 0 can be a valid IRQ resource too... Fixes: aff008ad813c ("platform_get_irq: Revert to platform_get_resource if of_irq_get fails") Signed-off-by: Sergei Shtylyov Signed-off-by: Greg Kroah-Hartman commit bf07d2609f57a56e9a401c4c10cb83b7eca44bcc Author: Bjorn Helgaas Date: Wed Oct 5 16:04:13 2016 -0500 PCI: tegra: Fix argument order in tegra_pcie_phy_disable() commit 8dd99bca7bfa4b62753b556c45d26f45ec9da6e6 upstream. The tegra_pcie_phy_disable() path called pads_writel() with arguments in the wrong order. Swap them to be the "value, offset" order expected by pads_writel(). Fixes: 6fe7c187e026 ("PCI: tegra: Support per-lane PHYs") Signed-off-by: Bjorn Helgaas Acked-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit aed23c6dda243c6cb1bcbd6399f936eeb9f3b1e5 Author: Maik Broemme Date: Tue Aug 9 16:41:31 2016 +0200 PCI: Mark Atheros AR9580 to avoid bus reset commit 8e2e03179923479ca0c0b6fdc7c93ecf89bce7a8 upstream. Similar to the AR93xx and the AR94xx series, the AR95xx also have the same quirk for the Bus Reset. It will lead to instant system reset if the device is assigned via VFIO to a KVM VM. I've been able reproduce this behavior with a MikroTik R11e-2HnD. Fixes: c3e59ee4e766 ("PCI: Mark Atheros AR93xx to avoid bus reset") Signed-off-by: Maik Broemme Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 123213c6c618ba23b270d84264a18d8c2ffe1e8b 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 commit 02265cd60335a2c1417abae4192611e1fc05a6e5 upstream. 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 Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 52473372a360f2f6607f420bb4a33e3a22a4f3db Author: Daniel Glöckner Date: Tue Aug 30 14:17:30 2016 +0200 mmc: block: don't use CMD23 with very old MMC cards commit 0ed50abb2d8fc81570b53af25621dad560cd49b3 upstream. CMD23 aka SET_BLOCK_COUNT was introduced with MMC v3.1. Older versions of the specification allowed to terminate multi-block transfers only with CMD12. The patch fixes the following problem: mmc0: new MMC card at address 0001 mmcblk0: mmc0:0001 SDMB-16 15.3 MiB mmcblk0: timed out sending SET_BLOCK_COUNT command, card status 0x400900 ... blk_update_request: I/O error, dev mmcblk0, sector 0 Buffer I/O error on dev mmcblk0, logical block 0, async page read mmcblk0: unable to read partition table Signed-off-by: Daniel Glöckner Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 2ada397f9fe3a5c0ad8954165b75c12fd9aa1f03 Author: Larry Finger Date: Mon Aug 22 14:27:59 2016 -0500 rtlwifi: Fix missing country code for Great Britain commit 0c9d3491530773858ff9d705ec2a9c382f449230 upstream. Some RTL8821AE devices sold in Great Britain have the country code of 0x25 encoded in their EEPROM. This value is not tested in the routine that establishes the regulatory info for the chip. The fix is to set this code to have the same capabilities as the EU countries. In addition, the channels allowed for COUNTRY_CODE_ETSI were more properly suited for China and Israel, not the EU. This problem has also been fixed. Signed-off-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 8a9398b95cfba21d8bc38fad3db9236d56a823d4 Author: Rajkumar Manoharan Date: Wed Sep 21 16:28:06 2016 +0530 ath10k: fix copy engine 5 destination ring stuck commit 0628467f97b5227755428bac10a68257322f7e34 upstream. Firmware is running watchdog timer for tracking copy engine ring index and write index. Whenever both indices are stuck at same location for given duration, watchdog will be trigger to assert target. While updating copy engine destination ring write index, driver ensures that write index will not be same as read index by finding delta between these two indices (CE_RING_DELTA). HTT target to host copy engine (CE5) is special case where ring buffers will be reused and delta check is not applied while updating write index. In rare scenario, whenever CE5 ring is full, both indices will be referring same location and this is causing CE ring stuck issue as explained above. This issue is originally reported on IPQ4019 during long hour stress testing and during veriwave max clients testsuites. The same issue is also observed in other chips as well. Fix this by ensuring that write index is one less than read index which means that full ring is available for receiving data. Tested-by: Tamizh chelvam Signed-off-by: Rajkumar Manoharan Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit cf2bf9597b5c445a200a0a7e01af5e05479f218d Author: Lin Huang Date: Thu Aug 4 19:32:33 2016 +0900 PM / devfreq: event: remove duplicate devfreq_event_get_drvdata() commit c8a9a6daccad495c48d5435d3487956ce01bc6a1 upstream. there define two devfreq_event_get_drvdata() function in devfreq-event.h when disable CONFIG_PM_DEVFREQ_EVENT, it will lead to build fail. So remove devfreq_event_get_drvdata() function. Fixes: f262f28c1470 ("PM / devfreq: event: Add devfreq_event class") Signed-off-by: Lin Huang Signed-off-by: Chanwoo Choi Signed-off-by: MyungJoo Ham Signed-off-by: Greg Kroah-Hartman commit 19db6eeffcb6784a24374e410c64188a21455ec2 Author: Geert Uytterhoeven Date: Fri Sep 9 09:02:51 2016 +0200 spi: spidev_test: Fix buffer overflow in unescape() commit 0278b34bf15f8d8a609595b15909cd8622dd64ca upstream. Sometimes spidev_test crashes with: *** Error in `spidev_test': munmap_chunk(): invalid pointer: 0x00022020 *** Aborted or just Segmentation fault This is due to transfer_escaped_string() miscalculating the required size of the buffer by one byte, causing a buffer overflow in unescape(). Drop the bogus "+ 1" in the strlen() parameter to fix this. Note that unescape() never copies the zero-terminator of the source string, so it writes at most as many bytes as the length of the source string. Fixes: 30061915be6e3a2c (spi: spidev_test: Added input buffer from the terminal) Signed-off-by: Geert Uytterhoeven Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e4211e4685efd982531f6f5989228ff144114fb2 Author: Lucas Stach Date: Fri Sep 16 11:16:10 2016 +0200 clk: imx6: fix i.MX6DL clock tree to reflect reality commit b1d51b448e4e6a392283b3eab06a7c5ec6d8a4e2 upstream. The current clock tree only implements the minimal set of differences between the i.MX6Q and the i.MX6DL, but that doesn't really reflect reality. Apply the following fixes to match the RM: - DL has no GPU3D_SHADER_SEL/PODF, the shader domain is clocked by GPU3D_CORE - GPU3D_SHADER_SEL/PODF has been repurposed as GPU2D_CORE_SEL/PODF - GPU2D_CORE_SEL/PODF has been repurposed as MLB_SEL/PODF Signed-off-by: Lucas Stach Acked-by: Shawn Guo Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit cd7b3bb326d30d079ed98625dec5e6de6e623ec1 Author: Lucas Stach Date: Fri Sep 16 11:16:11 2016 +0200 clk: imx6: initialize GPU clocks commit d8846023aed1293e54d33499558fc2aa2b2f393f upstream. Initialize the GPU clock muxes to sane inputs. Until now they have not been changed from their default values, which means that both GPU3D shader and GPU2D core were fed by clock inputs whose rates exceed the maximium allowed frequency of the cores by as much as 200MHz. This fixes a severe GPU stability issue on i.MX6DL. Signed-off-by: Lucas Stach Acked-by: Shawn Guo Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit d6ae60398fae5b74ab8898a213bd03d7162aba9c Author: Jan Remmet Date: Fri Sep 23 10:52:00 2016 +0200 regulator: tps65910: Work around silicon erratum SWCZ010 commit 8f9165c981fed187bb483de84caf9adf835aefda upstream. http://www.ti.com/lit/pdf/SWCZ010: DCDC o/p voltage can go higher than programmed value Impact: VDDI, VDD2, and VIO output programmed voltage level can go higher than expected or crash, when coming out of PFM to PWM mode or using DVFS. Description: When DCDC CLK SYNC bits are 11/01: * VIO 3-MHz oscillator is the source clock of the digital core and input clock of VDD1 and VDD2 * Turn-on of VDD1 and VDD2 HSD PFETis synchronized or at a constant phase shift * Current pulled though VCC1+VCC2 is Iload(VDD1) + Iload(VDD2) * The 3 HSD PFET will be turned-on at the same time, causing the highest possible switching noise on the application. This noise level depends on the layout, the VBAT level, and the load current. The noise level increases with improper layout. When DCDC CLK SYNC bits are 00: * VIO 3-MHz oscillator is the source clock of digital core * VDD1 and VDD2 are running on their own 3-MHz oscillator * Current pulled though VCC1+VCC2 average of Iload(VDD1) + Iload(VDD2) * The switching noise of the 3 SMPS will be randomly spread over time, causing lower overall switching noise. Workaround: Set DCDCCTRL_REG[1:0]= 00. Signed-off-by: Jan Remmet Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 48be1e74c5b15d3e88de46a91479096346b15d93 Author: Alexander Usyskin Date: Mon Sep 12 16:21:43 2016 +0300 mei: me: add kaby point device ids commit ac182e8abc6f93c1c4cc12f042af64c9d7be0d1e upstream. Add device ids for Intel Kabypoint PCH (Kabylake) Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit 02ff08421a0949e4bdf7dff287ec49833fe928b9 Author: Tomas Winkler Date: Thu Jun 23 00:25:31 2016 +0300 mei: fix return value on disconnection commit 2d4d5481e2d6f93b25fcfb13a9f20bbfbf54266a upstream. Correct errno on client disconnection is -ENODEV not -EBUSY Signed-off-by: Tomas Winkler Signed-off-by: Alexander Usyskin Signed-off-by: Greg Kroah-Hartman commit 43d585e18a29604236a81c3b669067d420f47d14 Author: Liu Gang Date: Fri Oct 21 15:31:28 2016 +0800 gpio: mpc8xxx: Correct irq handler function commit d71cf15b865bdd45925f7b094d169aaabd705145 upstream. From the beginning of the gpio-mpc8xxx.c, the "handle_level_irq" has being used to handle GPIO interrupts in the PowerPC/Layerscape platforms. But actually, almost all PowerPC/Layerscape platforms assert an interrupt request upon either a high-to-low change or any change on the state of the signal. So the "handle_level_irq" is not reasonable for PowerPC/Layerscape GPIO interrupt, it should be "handle_edge_irq". Otherwise the system may lost some interrupts from the PIN's state changes. Signed-off-by: Liu Gang Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman