commit 99f614a3bb23603a947be2e95b78507112c484e5 Author: Sasha Levin Date: Mon Aug 22 09:50:48 2016 -0400 Linux 4.1.31 Signed-off-by: Sasha Levin commit 432273c710ae564a9530f44c0deb92b9e7a463d8 Author: James Hogan Date: Thu Aug 18 10:01:29 2016 +0100 MIPS: KVM: Propagate kseg0/mapped tlb fault errors commit 9b731bcfdec4c159ad2e4312e25d69221709b96a upstream. Propagate errors from kvm_mips_handle_kseg0_tlb_fault() and kvm_mips_handle_mapped_seg_tlb_fault(), usually triggering an internal error since they normally indicate the guest accessed bad physical memory or the commpage in an unexpected way. Fixes: 858dd5d45733 ("KVM/MIPS32: MMU/TLB operations for the Guest.") Fixes: e685c689f3a8 ("KVM/MIPS32: Privileged instruction/target branch emulation.") Signed-off-by: James Hogan Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Signed-off-by: Radim Krčmář [james.hogan@imgtec.com: Backport to v4.7] Signed-off-by: James Hogan Signed-off-by: Sasha Levin commit 7fe3930e1f146476e81eca06ca0833bd477b3da8 Author: James Hogan Date: Thu Aug 18 10:01:28 2016 +0100 MIPS: KVM: Fix gfn range check in kseg0 tlb faults commit 0741f52d1b980dbeb290afe67d88fc2928edd8ab upstream. Two consecutive gfns are loaded into host TLB, so ensure the range check isn't off by one if guest_pmap_npages is odd. Fixes: 858dd5d45733 ("KVM/MIPS32: MMU/TLB operations for the Guest.") Signed-off-by: James Hogan Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Signed-off-by: Radim Krčmář [james.hogan@imgtec.com: Backport to v4.7] Signed-off-by: James Hogan Signed-off-by: Sasha Levin commit 0fbddc006492a05e061bfa61170f155c989f6a15 Author: James Hogan Date: Thu Aug 18 10:01:27 2016 +0100 MIPS: KVM: Add missing gfn range check commit 8985d50382359e5bf118fdbefc859d0dbf6cebc7 upstream. kvm_mips_handle_mapped_seg_tlb_fault() calculates the guest frame number based on the guest TLB EntryLo values, however it is not range checked to ensure it lies within the guest_pmap. If the physical memory the guest refers to is out of range then dump the guest TLB and emit an internal error. Fixes: 858dd5d45733 ("KVM/MIPS32: MMU/TLB operations for the Guest.") Signed-off-by: James Hogan Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Signed-off-by: Radim Krčmář [james.hogan@imgtec.com: Backport to v4.7] Signed-off-by: James Hogan Signed-off-by: Sasha Levin commit 342b88eb5999fc0c2c587082c4dce6e40eb62a20 Author: James Hogan Date: Thu Aug 18 10:01:26 2016 +0100 MIPS: KVM: Fix mapped fault broken commpage handling commit c604cffa93478f8888bec62b23d6073dad03d43a upstream. kvm_mips_handle_mapped_seg_tlb_fault() appears to map the guest page at virtual address 0 to PFN 0 if the guest has created its own mapping there. The intention is unclear, but it may have been an attempt to protect the zero page from being mapped to anything but the comm page in code paths you wouldn't expect from genuine commpage accesses (guest kernel mode cache instructions on that address, hitting trapping instructions when executing from that address with a coincidental TLB eviction during the KVM handling, and guest user mode accesses to that address). Fix this to check for mappings exactly at KVM_GUEST_COMMPAGE_ADDR (it may not be at address 0 since commit 42aa12e74e91 ("MIPS: KVM: Move commpage so 0x0 is unmapped")), and set the corresponding EntryLo to be interpreted as 0 (invalid). Fixes: 858dd5d45733 ("KVM/MIPS32: MMU/TLB operations for the Guest.") Signed-off-by: James Hogan Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Signed-off-by: Radim Krčmář [james.hogan@imgtec.com: Backport to v4.7] Signed-off-by: James Hogan Signed-off-by: Sasha Levin commit 867df5e12818bca1d37fc4c9a35346764879f2af Author: Vegard Nossum Date: Fri Jul 15 00:22:07 2016 -0400 ext4: verify extent header depth [ Upstream commit 7bc9491645118c9461bd21099c31755ff6783593 ] Although the extent tree depth of 5 should enough be for the worst case of 2*32 extents of length 1, the extent tree code does not currently to merge nodes which are less than half-full with a sibling node, or to shrink the tree depth if possible. So it's possible, at least in theory, for the tree depth to be greater than 5. However, even in the worst case, a tree depth of 32 is highly unlikely, and if the file system is maliciously corrupted, an insanely large eh_depth can cause memory allocation failures that will trigger kernel warnings (here, eh_depth = 65280): JBD2: ext4.exe wants too many credits credits:195849 rsv_credits:0 max:256 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 50 at fs/jbd2/transaction.c:293 start_this_handle+0x569/0x580 CPU: 0 PID: 50 Comm: ext4.exe Not tainted 4.7.0-rc5+ #508 Stack: 604a8947 625badd8 0002fd09 00000000 60078643 00000000 62623910 601bf9bc 62623970 6002fc84 626239b0 900000125 Call Trace: [<6001c2dc>] show_stack+0xdc/0x1a0 [<601bf9bc>] dump_stack+0x2a/0x2e [<6002fc84>] __warn+0x114/0x140 [<6002fdff>] warn_slowpath_null+0x1f/0x30 [<60165829>] start_this_handle+0x569/0x580 [<60165d4e>] jbd2__journal_start+0x11e/0x220 [<60146690>] __ext4_journal_start_sb+0x60/0xa0 [<60120a81>] ext4_truncate+0x131/0x3a0 [<60123677>] ext4_setattr+0x757/0x840 [<600d5d0f>] notify_change+0x16f/0x2a0 [<600b2b16>] do_truncate+0x76/0xc0 [<600c3e56>] path_openat+0x806/0x1300 [<600c55c9>] do_filp_open+0x89/0xf0 [<600b4074>] do_sys_open+0x134/0x1e0 [<600b4140>] SyS_open+0x20/0x30 [<6001ea68>] handle_syscall+0x88/0x90 [<600295fd>] userspace+0x3fd/0x500 [<6001ac55>] fork_handler+0x85/0x90 ---[ end trace 08b0b88b6387a244 ]--- [ Commit message modified and the extent tree depath check changed from 5 to 32 -- tytso ] Cc: Darrick J. Wong Signed-off-by: Vegard Nossum Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit cd5108403bda69524fd07a035e804d64ee8ae5b8 Author: Kangjie Lu Date: Tue May 3 16:44:32 2016 -0400 ALSA: timer: Fix leak in events via snd_timer_user_tinterrupt [ Upstream commit e4ec8cc8039a7063e24204299b462bd1383184a5 ] The stack object “r1” has a total size of 32 bytes. Its field “event” and “val” both contain 4 bytes padding. These 8 bytes padding bytes are sent to user without being initialized. Signed-off-by: Kangjie Lu Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1fbc4fd13bd04fd7c7fd033fdfde97e96d2865e5 Author: Kangjie Lu Date: Tue May 3 16:44:20 2016 -0400 ALSA: timer: Fix leak in events via snd_timer_user_ccallback [ Upstream commit 9a47e9cff994f37f7f0dbd9ae23740d0f64f9fe6 ] The stack object “r1” has a total size of 32 bytes. Its field “event” and “val” both contain 4 bytes padding. These 8 bytes padding bytes are sent to user without being initialized. Signed-off-by: Kangjie Lu Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1b7d7bce7467cf10f21007a5c952688877ead95e Author: Kangjie Lu Date: Tue May 3 16:44:07 2016 -0400 ALSA: timer: Fix leak in SNDRV_TIMER_IOCTL_PARAMS [ Upstream commit cec8f96e49d9be372fdb0c3836dcf31ec71e457e ] The stack object “tread” has a total size of 32 bytes. Its field “event” and “val” both contain 4 bytes padding. These 8 bytes padding bytes are sent to user without being initialized. Signed-off-by: Kangjie Lu Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c65b5c9c0085bab46706f35c4889dd03cf2b0c08 Author: Michał Pecio Date: Tue Jun 7 12:34:45 2016 +0200 USB: OHCI: Don't mark EDs as ED_OPER if scheduling fails [ Upstream commit c66f59ee5050447b3da92d36f5385a847990a894 ] Since ed_schedule begins with marking the ED as "operational", the ED may be left in such state even if scheduling actually fails. This allows future submission attempts to smuggle this ED to the hardware behind the scheduler's back and without linking it to the ohci->eds_in_use list. The former causes bandwidth saturation and data loss on isoc endpoints, the latter crashes the kernel when attempt is made to unlink such ED from this list. Fix ed_schedule to update ED state only on successful return. Signed-off-by: Michal Pecio Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6412c3ae6b415ca83264a2c11e24bfb63cd74629 Author: Miklos Szeredi Date: Mon Mar 21 17:31:44 2016 +0100 ovl: verify upper dentry before unlink and rename [ Upstream commit 11f3710417d026ea2f4fcf362d866342c5274185 ] Unlink and rename in overlayfs checked the upper dentry for staleness by verifying upper->d_parent against upperdir. However the dentry can go stale also by being unhashed, for example. Expand the verification to actually look up the name again (under parent lock) and check if it matches the upper dentry. This matches what the VFS does before passing the dentry to filesytem's unlink/rename methods, which excludes any inconsistency caused by overlayfs. Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 40b9a8f49d1e1e75dfdedbc25d0a3c9fea716bab Author: Mark Brown Date: Mon Jun 20 13:53:34 2016 +0100 iio:ad7266: Fix probe deferral for vref [ Upstream commit 68b356eb3d9f5e38910fb62e22a78e2a18d544ae ] Currently the ad7266 driver treats any failure to get vref as though the regulator were not present but this means that if probe deferral is triggered the driver will act as though the regulator were not present. Instead only use the internal reference if we explicitly got -ENODEV which is what is returned for absent regulators. Signed-off-by: Mark Brown Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit fb079b49a29bf9e25c493525b228f7b33dbbe44f Author: Mark Brown Date: Mon Jun 20 13:53:33 2016 +0100 iio:ad7266: Fix support for optional regulators [ Upstream commit e5511c816e5ac4909bdd38e85ac344e2b9b8e984 ] The ad7266 driver attempts to support deciding between the use of internal and external power supplies by checking to see if an error is returned when requesting the regulator. This doesn't work with the current code since the driver uses a normal regulator_get() which is for non-optional supplies and so assumes that if a regulator is not provided by the platform then this is a bug in the platform integration and so substitutes a dummy regulator. Use regulator_get_optional() instead which indicates to the framework that the regulator may be absent and provides a dummy regulator instead. Signed-off-by: Mark Brown Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 44cdc9fa258bde621577ac36fcab6fd674f4bf98 Author: Mark Brown Date: Mon Jun 20 13:53:32 2016 +0100 iio:ad7266: Fix broken regulator error handling [ Upstream commit 6b7f4e25f3309f106a5c7ff42c8231494cf285d3 ] All regulator_get() variants return either a pointer to a regulator or an ERR_PTR() so testing for NULL makes no sense and may lead to bugs if we use NULL as a valid regulator. Fix this by using IS_ERR() as expected. Signed-off-by: Mark Brown Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 94f93848624aea581967a37e462909b3b0e6f0cb Author: Linus Walleij Date: Fri Jun 17 15:22:24 2016 +0200 iio: accel: kxsd9: fix the usage of spi_w8r8() [ Upstream commit 0c1f91b98552da49d9d8eed32b3132a58d2f4598 ] These two spi_w8r8() calls return a value with is used by the code following the error check. The dubious use was caused by a cleanup patch. Fixes: d34dbee8ac8e ("staging:iio:accel:kxsd9 cleanup and conversion to iio_chan_spec.") Signed-off-by: Linus Walleij Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit b2372ff74a06656f67b24e73477f81e25956df89 Author: Luis de Bethencourt Date: Wed Jun 22 20:43:30 2016 +0100 staging: iio: accel: fix error check [ Upstream commit ef3149eb3ddb7f9125e11c90f8330e371b55cffd ] sca3000_read_ctrl_reg() returns a negative number on failure, check for this instead of zero. Signed-off-by: Luis de Bethencourt Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit c1a8303fb95f6933709831d5d5c742caee13d592 Author: Matt Ranostay Date: Sat May 21 20:01:03 2016 -0700 iio: proximity: as3935: fix buffer stack trashing [ Upstream commit 37b1ba2c68cfbe37f5f45bb91bcfaf2b016ae6a1 ] Buffer wasn't of a valid size to allow the timestamp, and correct padding. This patchset also moves the buffer off the stack, and onto the heap. Cc: george.mccollister@gmail.com Signed-off-by: Matt Ranostay Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 9db892c0c7d71779bafcac2e26121357519fc615 Author: Matt Ranostay Date: Sat May 21 20:01:02 2016 -0700 iio: proximity: as3935: remove triggered buffer processing [ Upstream commit 7d0643634ea567969bf3f3ed6193a9d6fc75653b ] Triggered buffers shouldn't return processed data, and the respective conversion was overflowing the defined .realbits for the channel. Cc: george.mccollister@gmail.com Signed-off-by: Matt Ranostay Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit e2a296e94cabe8f39420bec1936d9ef146c3dcee Author: Matt Ranostay Date: Sat May 21 20:01:01 2016 -0700 iio: proximity: as3935: correct IIO_CHAN_INFO_RAW output [ Upstream commit 5138806f16c74c7cb8ac3e408a859c79eb7c9567 ] IIO_CHAN_INFO_RAW was returning processed data which was incorrect. This also adds the IIO_CHAN_INFO_SCALE value to convert to a processed value. Signed-off-by: Matt Ranostay Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit f247adf96f98a21b130a5844435a36f917c2a98a Author: Gregor Boirie Date: Tue Apr 19 11:18:33 2016 +0200 iio:st_pressure: fix sampling gains (bring inline with ABI) [ Upstream commit d43a41152f8e9e4c0d19850884d1fada076dee10 ] Temperature channels report scaled samples in Celsius although expected as milli degree Celsius in Documentation/ABI/testing/sysfs-bus-iio. Gains are not implemented at all for LPS001WP pressure and temperature channels. This patch ensures that proper offsets and scales are exposed to userpace for both pressure and temperature channels. Also fix a NULL pointer exception when userspace reads content of sysfs scale attribute when gains are not defined. Signed-off-by: Gregor Boirie Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 3bdfc8b57f57425b6fc6d1bca4accfbb72d755f8 Author: Crestez Dan Leonard Date: Tue May 3 15:27:09 2016 +0300 iio: Fix error handling in iio_trigger_attach_poll_func [ Upstream commit 99543823357966ac938d9a310947e731b67338e6 ] When attaching a pollfunc iio_trigger_attach_poll_func will allocate a virtual irq and call the driver's set_trigger_state function. Fix error handling to undo previous steps if any fails. In particular this fixes handling errors from a driver's set_trigger_state function. When using triggered buffers a failure to enable the trigger used to make the buffer unusable. Signed-off-by: Crestez Dan Leonard Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit f3c7b15dc141f5b3c9deddf8164fae28a9b4de5f Author: Andrey Ryabinin Date: Wed May 11 16:51:51 2016 +0300 perf/x86: Fix undefined shift on 32-bit kernels [ Upstream commit 6d6f2833bfbf296101f9f085e10488aef2601ba5 ] Jim reported: UBSAN: Undefined behaviour in arch/x86/events/intel/core.c:3708:12 shift exponent 35 is too large for 32-bit type 'long unsigned int' The use of 'unsigned long' type obviously is not correct here, make it 'unsigned long long' instead. Reported-by: Jim Cromie Signed-off-by: Andrey Ryabinin Signed-off-by: Peter Zijlstra (Intel) Cc: Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: H. Peter Anvin Cc: Imre Palik Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Fixes: 2c33645d366d ("perf/x86: Honor the architectural performance monitoring version") Link: http://lkml.kernel.org/r/1462974711-10037-1-git-send-email-aryabinin@virtuozzo.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 7ceedf586399587f2d3c2ae33377bfcf8b654b6d Author: Michael S. Tsirkin Date: Tue May 17 13:31:18 2016 +0300 virtio_balloon: fix PFN format for virtio-1 [ Upstream commit 87c9403b0d1de4676b0bd273eea68fcf6de68e68 ] Everything should be LE when using virtio-1, but the linux balloon driver does not seem to care about that. Reported-by: Cornelia Huck Signed-off-by: Michael S. Tsirkin Tested-by: Cornelia Huck Reviewed-by: Cornelia Huck Signed-off-by: Sasha Levin commit 4dbc156a8610abfa9209d23ad2bdb4692cf63730 Author: Denis V. Lunev Date: Thu Aug 20 00:49:49 2015 +0300 virtio_balloon: do not change memory amount visible via /proc/meminfo [ Upstream commit 997e120843e82609c8d99a9d5714e6cf91e14cbe ] Balloon device is frequently used as a mean of cooperative memory control in between guest and host to manage memory overcommitment. This is the typical case for any hosting workload when KVM guest is provided for end-user. Though there is a problem in this setup. The end-user and hosting provider have signed SLA agreement in which some amount of memory is guaranted for the guest. The good thing is that this memory will be given to the guest when the guest will really need it (f.e. with OOM in guest and with VIRTIO_BALLOON_F_DEFLATE_ON_OOM configuration flag set). The bad thing is that end-user does not know this. Balloon by default reduce the amount of memory exposed to the end-user each time when the page is stolen from guest or returned back by using adjust_managed_page_count and thus /proc/meminfo shows reduced amount of memory. Fortunately the solution is simple, we should just avoid to call adjust_managed_page_count with VIRTIO_BALLOON_F_DEFLATE_ON_OOM set. Signed-off-by: Denis V. Lunev CC: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 55f883cb777124d1f9c197c5f6c1bd80840fbe2a Author: Mark Rutland Date: Tue Mar 1 14:18:50 2016 +0000 arm64: Rework valid_user_regs [ Upstream commit dbd4d7ca563fd0a8949718d35ce197e5642d5d9d ] We validate pstate using PSR_MODE32_BIT, which is part of the user-provided pstate (and cannot be trusted). Also, we conflate validation of AArch32 and AArch64 pstate values, making the code difficult to reason about. Instead, validate the pstate value based on the associated task. The task may or may not be current (e.g. when using ptrace), so this must be passed explicitly by callers. To avoid circular header dependencies via sched.h, is_compat_task is pulled out of asm/ptrace.h. To make the code possible to reason about, the AArch64 and AArch32 validation is split into separate functions. Software must respect the RES0 policy for SPSR bits, and thus the kernel mirrors the hardware policy (RAZ/WI) for bits as-yet unallocated. When these acquire an architected meaning writes may be permitted (potentially with additional validation). Signed-off-by: Mark Rutland Acked-by: Will Deacon Cc: Dave Martin Cc: James Morse Cc: Peter Maydell Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 5c4642407d9c696dadef7fba557244c2d69d96dd Author: Bjørn Mork Date: Sun Jul 3 22:24:50 2016 +0200 cdc_ncm: workaround for EM7455 "silent" data interface [ Upstream commit c086e7096170390594c425114d98172bc9aceb8a ] Several Lenovo users have reported problems with their Sierra Wireless EM7455 modem. The driver has loaded successfully and the MBIM management channel has appeared to work, including establishing a connection to the mobile network. But no frames have been received over the data interface. The problem affects all EM7455 and MC7455, and is assumed to affect other modems based on the same Qualcomm chipset and baseband firmware. Testing narrowed the problem down to what seems to be a firmware timing bug during initialization. Adding a short sleep while probing is sufficient to make the problem disappear. Experiments have shown that 1-2 ms is too little to have any effect, while 10-20 ms is enough to reliably succeed. Reported-by: Stefan Armbruster Reported-by: Ralph Plawetzki Reported-by: Andreas Fett Reported-by: Rasmus Lerdorf Reported-by: Samo Ratnik Reported-and-tested-by: Aleksander Morgado Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 28a6d048eb841a6bca10558a6c9e30ec5ca2b1af Author: Ben Hutchings Date: Wed Jun 22 19:43:35 2016 +0100 nfsd: check permissions when setting ACLs [ Upstream commit 999653786df6954a31044528ac3f7a5dadca08f4 ] Use set_posix_acl, which includes proper permission checks, instead of calling ->set_acl directly. Without this anyone may be able to grant themselves permissions to a file by setting the ACL. Lock the inode to make the new checks atomic with respect to set_acl. (Also, nfsd was the only caller of set_acl not locking the inode, so I suspect this may fix other races.) This also simplifies the code, and ensures our ACLs are checked by posix_acl_valid. The permission checks and the inode locking were lost with commit 4ac7249e, which changed nfsd to use the set_acl inode operation directly instead of going through xattr handlers. Reported-by: David Sinquin [agreunba@redhat.com: use set_posix_acl] Fixes: 4ac7249e Cc: Christoph Hellwig Cc: Al Viro Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 173f43c05f782df4fe42cc1152f9306ef76dc6eb Author: Andreas Gruenbacher Date: Wed Jun 22 23:57:25 2016 +0200 posix_acl: Add set_posix_acl [ Upstream commit 485e71e8fb6356c08c7fc6bcce4bf02c9a9a663f ] Factor out part of posix_acl_xattr_set into a common function that takes a posix_acl, which nfsd can also call. The prototype already exists in include/linux/posix_acl.h. Signed-off-by: Andreas Gruenbacher Cc: stable@vger.kernel.org Cc: Christoph Hellwig Cc: Al Viro Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 63933c775e08459df80b6e76ead685bf20105494 Author: Gavin Shan Date: Thu May 26 09:56:07 2016 +1000 powerpc/pseries: Fix PCI config address for DDW [ Upstream commit 8a934efe94347eee843aeea65bdec8077a79e259 ] In commit 8445a87f7092 "powerpc/iommu: Remove the dependency on EEH struct in DDW mechanism", the PE address was replaced with the PCI config address in order to remove dependency on EEH. According to PAPR spec, firmware (pHyp or QEMU) should accept "xxBBSSxx" format PCI config address, not "xxxxBBSS" provided by the patch. Note that "BB" is PCI bus number and "SS" is the combination of slot and function number. This fixes the PCI address passed to DDW RTAS calls. Fixes: 8445a87f7092 ("powerpc/iommu: Remove the dependency on EEH struct in DDW mechanism") Cc: stable@vger.kernel.org # v3.4+ Reported-by: Guilherme G. Piccoli Signed-off-by: Gavin Shan Tested-by: Guilherme G. Piccoli Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 049de1972f59980634d4b3a31ce7defaa194d471 Author: Guilherme G. Piccoli Date: Mon Apr 11 16:17:23 2016 -0300 powerpc/iommu: Remove the dependency on EEH struct in DDW mechanism [ Upstream commit 8445a87f7092bc8336ea1305be9306f26b846d93 ] Commit 39baadbf36ce ("powerpc/eeh: Remove eeh information from pci_dn") changed the pci_dn struct by removing its EEH-related members. As part of this clean-up, DDW mechanism was modified to read the device configuration address from eeh_dev struct. As a consequence, now if we disable EEH mechanism on kernel command-line for example, the DDW mechanism will fail, generating a kernel oops by dereferencing a NULL pointer (which turns to be the eeh_dev pointer). This patch just changes the configuration address calculation on DDW functions to a manual calculation based on pci_dn members instead of using eeh_dev-based address. No functional changes were made. This was tested on pSeries, both in PHyp and qemu guest. Fixes: 39baadbf36ce ("powerpc/eeh: Remove eeh information from pci_dn") Cc: stable@vger.kernel.org # v3.4+ Reviewed-by: Gavin Shan Signed-off-by: Guilherme G. Piccoli Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit d9ee963b61b93366103b88f10495b4680b256273 Author: Vegard Nossum Date: Fri Jul 29 10:40:31 2016 +0200 block: fix use-after-free in seq file [ Upstream commit 77da160530dd1dc94f6ae15a981f24e5f0021e84 ] I got a KASAN report of use-after-free: ================================================================== BUG: KASAN: use-after-free in klist_iter_exit+0x61/0x70 at addr ffff8800b6581508 Read of size 8 by task trinity-c1/315 ============================================================================= BUG kmalloc-32 (Not tainted): kasan: bad access detected ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: Allocated in disk_seqf_start+0x66/0x110 age=144 cpu=1 pid=315 ___slab_alloc+0x4f1/0x520 __slab_alloc.isra.58+0x56/0x80 kmem_cache_alloc_trace+0x260/0x2a0 disk_seqf_start+0x66/0x110 traverse+0x176/0x860 seq_read+0x7e3/0x11a0 proc_reg_read+0xbc/0x180 do_loop_readv_writev+0x134/0x210 do_readv_writev+0x565/0x660 vfs_readv+0x67/0xa0 do_preadv+0x126/0x170 SyS_preadv+0xc/0x10 do_syscall_64+0x1a1/0x460 return_from_SYSCALL_64+0x0/0x6a INFO: Freed in disk_seqf_stop+0x42/0x50 age=160 cpu=1 pid=315 __slab_free+0x17a/0x2c0 kfree+0x20a/0x220 disk_seqf_stop+0x42/0x50 traverse+0x3b5/0x860 seq_read+0x7e3/0x11a0 proc_reg_read+0xbc/0x180 do_loop_readv_writev+0x134/0x210 do_readv_writev+0x565/0x660 vfs_readv+0x67/0xa0 do_preadv+0x126/0x170 SyS_preadv+0xc/0x10 do_syscall_64+0x1a1/0x460 return_from_SYSCALL_64+0x0/0x6a CPU: 1 PID: 315 Comm: trinity-c1 Tainted: G B 4.7.0+ #62 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 ffffea0002d96000 ffff880119b9f918 ffffffff81d6ce81 ffff88011a804480 ffff8800b6581500 ffff880119b9f948 ffffffff8146c7bd ffff88011a804480 ffffea0002d96000 ffff8800b6581500 fffffffffffffff4 ffff880119b9f970 Call Trace: [] dump_stack+0x65/0x84 [] print_trailer+0x10d/0x1a0 [] object_err+0x2f/0x40 [] kasan_report_error+0x221/0x520 [] __asan_report_load8_noabort+0x3e/0x40 [] klist_iter_exit+0x61/0x70 [] class_dev_iter_exit+0x9/0x10 [] disk_seqf_stop+0x3a/0x50 [] seq_read+0x4b2/0x11a0 [] proc_reg_read+0xbc/0x180 [] do_loop_readv_writev+0x134/0x210 [] do_readv_writev+0x565/0x660 [] vfs_readv+0x67/0xa0 [] do_preadv+0x126/0x170 [] SyS_preadv+0xc/0x10 This problem can occur in the following situation: open() - pread() - .seq_start() - iter = kmalloc() // succeeds - seqf->private = iter - .seq_stop() - kfree(seqf->private) - pread() - .seq_start() - iter = kmalloc() // fails - .seq_stop() - class_dev_iter_exit(seqf->private) // boom! old pointer As the comment in disk_seqf_stop() says, stop is called even if start failed, so we need to reinitialise the private pointer to NULL when seq iteration stops. An alternative would be to set the private pointer to NULL when the kmalloc() in disk_seqf_start() fails. Cc: stable@vger.kernel.org Signed-off-by: Vegard Nossum Acked-by: Tejun Heo Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 403f056afd87471b1ef68c0519c8723afae4babb Author: James Hogan Date: Thu Aug 4 17:36:08 2016 +0100 metag: Fix __cmpxchg_u32 asm constraint for CMP [ Upstream commit 6154c187b97ee7513046bb4eb317a89f738f13ef ] The LNKGET based atomic sequence in __cmpxchg_u32 has slightly incorrect constraints for the return value which under certain circumstances can allow an address unit register to be used as the first operand of a CMP instruction. This isn't a valid instruction however as the encodings only allow a data unit to be specified. This would result in an assembler error like the following: Error: failed to assemble instruction: "CMP A0.2,D0Ar6" Fix by changing the constraint from "=&da" (assigned, early clobbered, data or address unit register) to "=&d" (data unit register only). The constraint for the second operand, "bd" (an op2 register where op1 is a data unit register and the instruction supports O2R) is already correct assuming the first operand is a data unit register. Other cases of CMP in inline asm have had their constraints checked, and appear to all be fine. Fixes: 6006c0d8ce94 ("metag: Atomics, locks and bitops") Signed-off-by: James Hogan Cc: linux-metag@vger.kernel.org Cc: # 3.9.x- Signed-off-by: Sasha Levin commit a2036fb1a801d2b75ddc1d407b97519f9cac5a0b Author: Hui Wang Date: Thu Aug 4 15:28:04 2016 +0800 ALSA: hda - Fix headset mic detection problem for two dell machines [ Upstream commit 59ec4b57bcaede46546d54d037a21004b9aa5cef ] One of the machines has ALC255 on it, another one has ALC298 on it. On the machine with the codec ALC298, it also has the speaker volume problem, so we add the fixup chained to ALC298_FIXUP_SPK_VOLUME rather than adding a group of pin definition in the pin quirk table, since the speak volume problem does not happen on other machines yet. Cc: Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 31ebbeb6e1e57a61dc091c9d321eeb330fa49c16 Author: Woodrow Shen Date: Sat Jul 25 10:36:16 2015 +0800 ALSA: hda - Fix the headset mic that will not work on Dell desktop machine [ Upstream commit e9c28e16a0b7071c88a206ad8ce0c73f6605bba7 ] When the headset was plugged in the Dell desktop, the mic of headset can't be detected and workable. According to the alsa-info, we found the differece between alsa and init_pin_configs on the machine, so we need to add the pin configs to make headset work. Codec: Realtek ALC3234 Vendor Id: 0x10ec0255 Subsystem Id: 0x102806bb BugLink: https://bugs.launchpad.net/bugs/1477900 Signed-off-by: Woodrow Shen Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 0224028e1bcf2d49531308b971b8485c552c1510 Author: Takashi Iwai Date: Wed Aug 3 15:13:00 2016 +0200 ALSA: hda: Fix krealloc() with __GFP_ZERO usage [ Upstream commit 33baefe5e72f17a6df378e48196cd8cada11deec ] krealloc() doesn't work always properly with __GFP_ZERO flag as expected. For clearing the reallocated area, we need to clear explicitly instead. Reported-by: Joe Perches Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit df75887f42357dd8392bd856280be8e835d10a02 Author: Maruthi Srinivas Bayyavarapu Date: Wed Aug 3 16:46:39 2016 +0530 ALSA: hda: add AMD Bonaire AZ PCI ID with proper driver caps [ Upstream commit fd48331f9b71d2add941adaee3619f5b8527182d ] This commit fixes garbled audio on Bonaire HDMI Signed-off-by: Maruthi Bayyavarapu Reviewed-by: Alex Deucher Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 333c2cf51f6a01388d4e5962ed585176ef7b6a86 Author: Matt Redfearn Date: Tue Jun 14 14:59:38 2016 +0100 MIPS: mm: Fix definition of R6 cache instruction [ Upstream commit 4f53989b0652ffe2605221c81ca8ffcfc90aed2a ] Commit a168b8f1cde6 ("MIPS: mm: Add MIPS R6 instruction encodings") added an incorrect definition of the redefined MIPSr6 cache instruction. Executing any kernel code including this instuction results in a reserved instruction exception and kernel panic. Fix the instruction definition. Fixes: a168b8f1cde6588ff7a67699fa11e01bc77a5ddd Signed-off-by: Matt Redfearn Cc: # 4.x- Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13663/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit e2b438fdfa4d7041b883e5f2acd2c39da1fe5e68 Author: Fabian Frederick Date: Tue Aug 2 14:03:07 2016 -0700 sysv, ipc: fix security-layer leaking [ Upstream commit 9b24fef9f0410fb5364245d6cc2bd044cc064007 ] Commit 53dad6d3a8e5 ("ipc: fix race with LSMs") updated ipc_rcu_putref() to receive rcu freeing function but used generic ipc_rcu_free() instead of msg_rcu_free() which does security cleaning. Running LTP msgsnd06 with kmemleak gives the following: cat /sys/kernel/debug/kmemleak unreferenced object 0xffff88003c0a11f8 (size 8): comm "msgsnd06", pid 1645, jiffies 4294672526 (age 6.549s) hex dump (first 8 bytes): 1b 00 00 00 01 00 00 00 ........ backtrace: kmemleak_alloc+0x23/0x40 kmem_cache_alloc_trace+0xe1/0x180 selinux_msg_queue_alloc_security+0x3f/0xd0 security_msg_queue_alloc+0x2e/0x40 newque+0x4e/0x150 ipcget+0x159/0x1b0 SyS_msgget+0x39/0x40 entry_SYSCALL_64_fastpath+0x13/0x8f Manfred Spraul suggested to fix sem.c as well and Davidlohr Bueso to only use ipc_rcu_free in case of security allocation failure in newary() Fixes: 53dad6d3a8e ("ipc: fix race with LSMs") Link: http://lkml.kernel.org/r/1470083552-22966-1-git-send-email-fabf@skynet.be Signed-off-by: Fabian Frederick Cc: Davidlohr Bueso Cc: Manfred Spraul Cc: [3.12+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 4ef5c9aa794064d8dd5bbe82921e26befb97a7c7 Author: Jia He Date: Tue Aug 2 14:02:31 2016 -0700 mm/hugetlb: avoid soft lockup in set_max_huge_pages() [ Upstream commit 649920c6ab93429b94bc7c1aa7c0e8395351be32 ] In powerpc servers with large memory(32TB), we watched several soft lockups for hugepage under stress tests. The call traces are as follows: 1. get_page_from_freelist+0x2d8/0xd50 __alloc_pages_nodemask+0x180/0xc20 alloc_fresh_huge_page+0xb0/0x190 set_max_huge_pages+0x164/0x3b0 2. prep_new_huge_page+0x5c/0x100 alloc_fresh_huge_page+0xc8/0x190 set_max_huge_pages+0x164/0x3b0 This patch fixes such soft lockups. It is safe to call cond_resched() there because it is out of spin_lock/unlock section. Link: http://lkml.kernel.org/r/1469674442-14848-1-git-send-email-hejianet@gmail.com Signed-off-by: Jia He Reviewed-by: Naoya Horiguchi Acked-by: Michal Hocko Acked-by: Dave Hansen Cc: Mike Kravetz Cc: "Kirill A. Shutemov" Cc: Paul Gortmaker Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 834ced1a13bdf510eae34d08bae1f1ae49b33141 Author: Mike Snitzer Date: Tue Aug 2 13:07:20 2016 -0400 dm: set DMF_SUSPENDED* _before_ clearing DMF_NOFLUSH_SUSPENDING [ Upstream commit eaf9a7361f47727b166688a9f2096854eef60fbe ] Otherwise, there is potential for both DMF_SUSPENDED* and DMF_NOFLUSH_SUSPENDING to not be set during dm_suspend() -- which is definitely _not_ a valid state. This fix, in conjuction with "dm rq: fix the starting and stopping of blk-mq queues", addresses the potential for request-based DM multipath's __multipath_map() to see !dm_noflush_suspending() during suspend. Reported-by: Bart Van Assche Signed-off-by: Mike Snitzer Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 655fe78746d0b9141fe763535fc16d6652665c13 Author: Sasha Levin Date: Sat Aug 13 07:45:12 2016 -0400 dm rq: fix the starting and stopping of blk-mq queues [ Upstream commit 7d9595d848cdff5c7939f68eec39e0c5d36a1d67 ] Improve dm_stop_queue() to cancel any requeue_work. Also, have dm_start_queue() and dm_stop_queue() clear/set the QUEUE_FLAG_STOPPED for the blk-mq request_queue. On suspend dm_stop_queue() handles stopping the blk-mq request_queue BUT: even though the hw_queues are marked BLK_MQ_S_STOPPED at that point there is still a race that is allowing block/blk-mq.c to call ->queue_rq against a hctx that it really shouldn't. Add a check to dm_mq_queue_rq() that guards against this rarity (albeit _not_ race-free). Signed-off-by: Mike Snitzer Cc: stable@vger.kernel.org # must patch dm.c on < 4.8 kernels Signed-off-by: Sasha Levin commit 980b6556a8df88e6160da185f72a4bc548e72199 Author: Mike Snitzer Date: Fri Jul 29 13:19:55 2016 -0400 dm flakey: error READ bios during the down_interval [ Upstream commit 99f3c90d0d85708e7401a81ce3314e50bf7f2819 ] When the corrupt_bio_byte feature was introduced it caused READ bios to no longer be errored with -EIO during the down_interval. This had to do with the complexity of needing to submit READs if the corrupt_bio_byte feature was used. Fix it so READ bios are properly errored with -EIO; doing so early in flakey_map() as long as there isn't a match for the corrupt_bio_byte feature. Fixes: a3998799fb4df ("dm flakey: add corrupt_bio_byte feature") Reported-by: Akira Hayakawa Signed-off-by: Mike Snitzer Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 0d88572753e332dedcb0d904b6033602326bd7c0 Author: Laura Abbott Date: Fri Jul 8 12:18:50 2016 -0700 ftrace/recordmcount: Work around for addition of metag magic but not relocations [ Upstream commit b2e1c26f0b62531636509fbcb6dab65617ed8331 ] glibc recently did a sync up (94e73c95d9b5 "elf.h: Sync with the gabi webpage") that added a #define for EM_METAG but did not add relocations This triggers build errors: scripts/recordmcount.c: In function 'do_file': scripts/recordmcount.c:466:28: error: 'R_METAG_ADDR32' undeclared (first use in this function) case EM_METAG: reltype = R_METAG_ADDR32; ^~~~~~~~~~~~~~ scripts/recordmcount.c:466:28: note: each undeclared identifier is reported only once for each function it appears in scripts/recordmcount.c:468:20: error: 'R_METAG_NONE' undeclared (first use in this function) rel_type_nop = R_METAG_NONE; ^~~~~~~~~~~~ Work around this change with some more #ifdefery for the relocations. Fedora Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1354034 Link: http://lkml.kernel.org/r/1468005530-14757-1-git-send-email-labbott@redhat.com Cc: stable@vger.kernel.org # v3.9+ Cc: James Hogan Fixes: 00512bdd4573 ("metag: ftrace support") Reported-by: Ross Burton Signed-off-by: Laura Abbott Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 2876b1b0b51d0153b95a377a8d13758b39ac0032 Author: Konstantin Neumoin Date: Mon Jul 11 15:28:59 2016 +0300 balloon: check the number of available pages in leak balloon [ Upstream commit 37cf99e08c6fb4dcea0f9ad2b13b6daa8c76a711 ] The balloon has a special mechanism that is subscribed to the oom notification which leads to deflation for a fixed number of pages. The number is always fixed even when the balloon is fully deflated. But leak_balloon did not expect that the pages to deflate will be more than taken, and raise a "BUG" in balloon_page_dequeue when page list will be empty. So, the simplest solution would be to check that the number of releases pages is less or equal to the number taken pages. Cc: stable@vger.kernel.org Signed-off-by: Konstantin Neumoin Signed-off-by: Denis V. Lunev CC: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit c6657f74f2c8c43b53afaabbf12b6bbf49874603 Author: Sasha Levin Date: Sun Aug 14 19:56:14 2016 -0400 x86/syscalls/64: Add compat_sys_keyctl for 32-bit userspace [ Upstream commit f7d665627e103e82d34306c7d3f6f46f387c0d8b ] x86_64 needs to use compat_sys_keyctl for 32-bit userspace rather than calling sys_keyctl(). The latter will work in a lot of cases, thereby hiding the issue. Reported-by: Stephan Mueller Tested-by: Stephan Mueller Signed-off-by: David Howells Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: keyrings@vger.kernel.org Cc: linux-security-module@vger.kernel.org Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/146961615805.14395.5581949237156769439.stgit@warthog.procyon.org.uk Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 10855c6411044f502f0bde816fd8f6ea5f6c7206 Author: Hui Wang Date: Mon Aug 1 10:20:32 2016 +0800 ALSA: hda/realtek - Can't adjust speaker's volume on a Dell AIO [ Upstream commit dd9aa335c88003d131ac874e7f6809902de0b847 ] We have a Dell AIO on which we can't adjust its speaker's volume. The problem is it is connected to a Audio Output node without Amp-out capability. To fix it, we change it to be connnected to a node with Amp-out capability. Cc: Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 6cdb1649f74423f61f7425d7447f3182a676d76b Author: Keith Packard Date: Wed Jul 15 12:14:39 2015 -0700 ALSA: hda/realtek: Enable HP amp and mute LED on HP Folio 9480m [v3] [ Upstream commit 98973f2f083a5ec580da8bbb685e6baa93613546 ] This laptop needs GPIO4 pulled high to enable the headphone amplifier, and has a mute LED on GPIO3. I modelled the patch on the existing GPIO4 code which pulls the line low for the same purpose; this time, the HP amp line is pulled high. v2: Disable the headphone amplifier when no headphone is connected. Don't disable power savings to preserve the LED state. v3: Remove headset-specific hooks and code; this is just a headphone. Signed-off-by: Keith Packard Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit baea0d65a4810802ee865d123c84436c52b416fd Author: Ilia Mirkin Date: Wed Jul 27 19:16:39 2016 -0400 drm/nouveau/gr/nv3x: fix instobj write offsets in gr setup [ Upstream commit d0e62ef6ed257715a88d0e5d7cd850a1695429e2 ] This should fix some unaligned access warnings. This is also likely to fix non-descript issues on nv30/nv34 as a result of incorrect channel setup. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96836 Signed-off-by: Ilia Mirkin Cc: stable@vger.kernel.org Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit c1b4d25bc66d0c5f1552daeb0cb72b0794bb1e62 Author: Mikulas Patocka Date: Thu Jul 28 18:56:13 2016 -0400 drm/nouveau/fbcon: fix font width not divisible by 8 [ Upstream commit 28668f43b8e421634e1623f72a879812288dd06b ] The patch f045f459d925 ("drm/nouveau/fbcon: fix out-of-bounds memory accesses") tries to fix some out of memory accesses. Unfortunatelly, the patch breaks the display when using fonts with width that is not divisiable by 8. The monochrome bitmap for each character is stored in memory by lines from top to bottom. Each line is padded to a full byte. For example, for 22x11 font, each line is padded to 16 bits, so each character is consuming 44 bytes total, that is 11 32-bit words. The patch f045f459d925 changed the logic to "dsize = ALIGN(image->width * image->height, 32) >> 5", that is just 8 words - this is incorrect and it causes display corruption. This patch adds the necesary padding of lines to 8 bytes. This patch should be backported to stable kernels where f045f459d925 was backported. Signed-off-by: Mikulas Patocka Fixes: f045f459d925 ("drm/nouveau/fbcon: fix out-of-bounds memory accesses") Cc: stable@vger.kernel.org Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit c027bc0ce936ce9446b6b9e1e994555722567b04 Author: Richard Weinberger Date: Thu Jun 23 19:30:38 2016 +0200 ubi: Make volume resize power cut aware [ Upstream commit 4946784bd3924b1374f05eebff2fd68660bae866 ] When the volume resize operation shrinks a volume, LEBs will be unmapped. Since unmapping will not erase these LEBs immediately we have to wait for that operation to finish. Otherwise in case of a power cut right after writing the new volume table the UBI attach process can find more LEBs than the volume table knows. This will render the UBI image unattachable. Fix this issue by waiting for erase to complete and write the new volume table afterward. Cc: Reported-by: Boris Brezillon Reviewed-by: Boris Brezillon Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 304e9158144a340e4ce63d51d1ac62d8a3bb2964 Author: Richard Weinberger Date: Mon Jul 4 22:06:51 2016 +0200 ubi: Fix early logging [ Upstream commit bc743f34dfa011e62edd0ea4ae8455be06c083b5 ] We cannot use ubi_* logging functions before the UBI object is initialized. Cc: Fixes: 3260870331 ("UBI: Extend UBI layer debug/messaging capabilities") Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit ae32d1b98ba29408df87c0ed47877ca0f248eae7 Author: Iosif Harutyunov Date: Fri Jul 22 23:22:42 2016 +0000 ubi: Fix race condition between ubi device creation and udev [ Upstream commit 714fb87e8bc05ff78255afc0dca981e8c5242785 ] Install the UBI device object before we arm sysfs. Otherwise udev tries to read sysfs attributes before UBI is ready and udev rules will not match. Cc: Signed-off-by: Iosif Harutyunov [rw: massaged commit message] Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit eb61bdda28b0fc1b7bea16919e0d34a9702d30e2 Author: Wei Fang Date: Mon Jul 25 21:17:04 2016 +0800 fuse: fix wrong assignment of ->flags in fuse_send_init() [ Upstream commit 9446385f05c9af25fed53dbed3cc75763730be52 ] FUSE_HAS_IOCTL_DIR should be assigned to ->flags, it may be a typo. Signed-off-by: Wei Fang Signed-off-by: Miklos Szeredi Fixes: 69fe05c90ed5 ("fuse: add missing INIT flags") Cc: Signed-off-by: Sasha Levin commit 614c3393382fc89c2fd42363b90594b9a666057b Author: Maxim Patlasov Date: Tue Jul 19 18:12:26 2016 -0700 fuse: fuse_flush must check mapping->flags for errors [ Upstream commit 9ebce595f63a407c5cec98f98f9da8459b73740a ] fuse_flush() calls write_inode_now() that triggers writeback, but actual writeback will happen later, on fuse_sync_writes(). If an error happens, fuse_writepage_end() will set error bit in mapping->flags. So, we have to check mapping->flags after fuse_sync_writes(). Signed-off-by: Maxim Patlasov Signed-off-by: Miklos Szeredi Fixes: 4d99ff8f12eb ("fuse: Turn writeback cache on") Cc: # v3.15+ Signed-off-by: Sasha Levin commit 3fc4a4a2c647ecd3348ca55dbdb56a3c990d2432 Author: Alexey Kuznetsov Date: Tue Jul 19 12:48:01 2016 -0700 fuse: fsync() did not return IO errors [ Upstream commit ac7f052b9e1534c8248f814b6f0068ad8d4a06d2 ] Due to implementation of fuse writeback filemap_write_and_wait_range() does not catch errors. We have to do this directly after fuse_sync_writes() Signed-off-by: Alexey Kuznetsov Signed-off-by: Maxim Patlasov Signed-off-by: Miklos Szeredi Fixes: 4d99ff8f12eb ("fuse: Turn writeback cache on") Cc: # v3.15+ Signed-off-by: Sasha Levin commit 93c0b008e79f11430ce07b6271b37671051d4298 Author: Vineet Gupta Date: Thu Jul 28 11:35:50 2016 -0700 ARC: mm: don't loose PTE_SPECIAL in pte_modify() [ Upstream commit 3925a16ae980c79d1a8fd182d7f9487da1edd4dc ] LTP madvise05 was generating mm splat | [ARCLinux]# /sd/ltp/testcases/bin/madvise05 | BUG: Bad page map in process madvise05 pte:80e08211 pmd:9f7d4000 | page:9fdcfc90 count:1 mapcount:-1 mapping: (null) index:0x0 flags: 0x404(referenced|reserved) | page dumped because: bad pte | addr:200b8000 vm_flags:00000070 anon_vma: (null) mapping: (null) index:1005c | file: (null) fault: (null) mmap: (null) readpage: (null) | CPU: 2 PID: 6707 Comm: madvise05 And for newer kernels, the system was rendered unusable afterwards. The problem was mprotect->pte_modify() clearing PTE_SPECIAL (which is set to identify the special zero page wired to the pte). When pte was finally unmapped, special casing for zero page was not done, and instead it was treated as a "normal" page, tripping on the map counts etc. This fixes ARC STAR 9001053308 Cc: Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit ae9c7f35df23c4d187e0e9c3f8e23f3ca7587e40 Author: Alex Deucher Date: Wed Jul 27 15:28:56 2016 -0400 drm/radeon: fix firmware info version checks [ Upstream commit 3edc38a0facef45ee22af8afdce3737f421f36ab ] Some of the checks didn't handle frev 2 tables properly. Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 7afd374e0c8db8e6306820fd95fb3838e0fdcae5 Author: David Howells Date: Wed Jul 27 11:43:37 2016 +0100 KEYS: 64-bit MIPS needs to use compat_sys_keyctl for 32-bit userspace [ Upstream commit 20f06ed9f61a185c6dabd662c310bed6189470df ] MIPS64 needs to use compat_sys_keyctl for 32-bit userspace rather than calling sys_keyctl. The latter will work in a lot of cases, thereby hiding the issue. Reported-by: Stephan Mueller Signed-off-by: David Howells cc: stable@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: linux-security-module@vger.kernel.org Cc: keyrings@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13832/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit bd89870c4447cbf622dd50d4d179e26234833600 Author: Paul Mackerras Date: Wed Jun 22 15:52:55 2016 +1000 KVM: PPC: Book3S HV: Save/restore TM state in H_CEDE [ Upstream commit 93d17397e4e2182fdaad503e2f9da46202c0f1c3 ] It turns out that if the guest does a H_CEDE while the CPU is in a transactional state, and the H_CEDE does a nap, and the nap loses the architected state of the CPU (which is is allowed to do), then we lose the checkpointed state of the virtual CPU. In addition, the transactional-memory state recorded in the MSR gets reset back to non-transactional, and when we try to return to the guest, we take a TM bad thing type of program interrupt because we are trying to transition from non-transactional to transactional with a hrfid instruction, which is not permitted. The result of the program interrupt occurring at that point is that the host CPU will hang in an infinite loop with interrupts disabled. Thus this is a denial of service vulnerability in the host which can be triggered by any guest (and depending on the guest kernel, it can potentially triggered by unprivileged userspace in the guest). This vulnerability has been assigned the ID CVE-2016-5412. To fix this, we save the TM state before napping and restore it on exit from the nap, when handling a H_CEDE in real mode. The case where H_CEDE exits to host virtual mode is already OK (as are other hcalls which exit to host virtual mode) because the exit path saves the TM state. Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Paul Mackerras Signed-off-by: Sasha Levin commit ae40dadbb81f553a053dcef39e5b0322f586c497 Author: Paul Mackerras Date: Wed Jun 22 14:21:59 2016 +1000 KVM: PPC: Book3S HV: Pull out TM state save/restore into separate procedures [ Upstream commit f024ee098476a3e620232e4a78cfac505f121245 ] This moves the transactional memory state save and restore sequences out of the guest entry/exit paths into separate procedures. This is so that these sequences can be used in going into and out of nap in a subsequent patch. The only code changes here are (a) saving and restore LR on the stack, since these new procedures get called with a bl instruction, (b) explicitly saving r1 into the PACA instead of assuming that HSTATE_HOST_R1(r13) is already set, and (c) removing an unnecessary and redundant setting of MSR[TM] that should have been removed by commit 9d4d0bdd9e0a ("KVM: PPC: Book3S HV: Add transactional memory support", 2013-09-24) but wasn't. Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Paul Mackerras Signed-off-by: Sasha Levin commit a3b180a9da61b9be52e1bcf8ff54b4cea3ce332c Author: Pavel Shilovsky Date: Sun Jul 24 10:37:38 2016 +0300 CIFS: Fix a possible invalid memory access in smb2_query_symlink() [ Upstream commit 7893242e2465aea6f2cbc2639da8fa5ce96e8cc2 ] During following a symbolic link we received err_buf from SMB2_open(). While the validity of SMB2 error response is checked previously in smb2_check_message() a symbolic link payload is not checked at all. Fix it by adding such checks. Cc: Dan Carpenter CC: Stable Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Sasha Levin commit b7e61a108f9fccd8d1b90ffe62704b929ba841eb Author: Aurelien Aptel Date: Wed May 25 19:59:09 2016 +0200 fs/cifs: make share unaccessible at root level mountable [ Upstream commit a6b5058fafdf508904bbf16c29b24042cef3c496 ] if, when mounting //HOST/share/sub/dir/foo we can query /sub/dir/foo but not any of the path components above: - store the /sub/dir/foo prefix in the cifs super_block info - in the superblock, set root dentry to the subpath dentry (instead of the share root) - set a flag in the superblock to remember it - use prefixpath when building path from a dentry fixes bso#8950 Signed-off-by: Aurelien Aptel CC: Stable Reviewed-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Sasha Levin commit b5e8e7f655d3d01430c357bdebe72a6ddc19e9a7 Author: Dmitry Torokhov Date: Mon Jul 25 11:36:54 2016 -0700 Input: i8042 - break load dependency between atkbd/psmouse and i8042 [ Upstream commit 4097461897df91041382ff6fcd2bfa7ee6b2448c ] As explained in 1407814240-4275-1-git-send-email-decui@microsoft.com we have a hard load dependency between i8042 and atkbd which prevents keyboard from working on Gen2 Hyper-V VMs. > hyperv_keyboard invokes serio_interrupt(), which needs a valid serio > driver like atkbd.c. atkbd.c depends on libps2.c because it invokes > ps2_command(). libps2.c depends on i8042.c because it invokes > i8042_check_port_owner(). As a result, hyperv_keyboard actually > depends on i8042.c. > > For a Generation 2 Hyper-V VM (meaning no i8042 device emulated), if a > Linux VM (like Arch Linux) happens to configure CONFIG_SERIO_I8042=m > rather than =y, atkbd.ko can't load because i8042.ko can't load(due to > no i8042 device emulated) and finally hyperv_keyboard can't work and > the user can't input: https://bugs.archlinux.org/task/39820 > (Ubuntu/RHEL/SUSE aren't affected since they use CONFIG_SERIO_I8042=y) To break the dependency we move away from using i8042_check_port_owner() and instead allow serio port owner specify a mutex that clients should use to serialize PS/2 command stream. Reported-by: Mark Laws Tested-by: Mark Laws Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit e9071d07878c865449c5afb062e6d305c62d1e85 Author: Ben Hutchings Date: Thu Apr 28 09:24:05 2016 +0930 Documentation/module-signing.txt: Note need for version info if reusing a key [ Upstream commit b8612e517c3c9809e1200b72c474dbfd969e5a83 ] Signing a module should only make it trusted by the specific kernel it was built for, not anything else. If a module signing key is used for multiple ABI-incompatible kernels, the modules need to include enough version information to distinguish them. Signed-off-by: Ben Hutchings Cc: stable@vger.kernel.org Signed-off-by: Rusty Russell Signed-off-by: Sasha Levin commit 6ac9857245bfb71d836f46db817b0c11e3e4bf69 Author: Ben Hutchings Date: Thu Apr 28 09:24:01 2016 +0930 module: Invalidate signatures on force-loaded modules [ Upstream commit bca014caaa6130e57f69b5bf527967aa8ee70fdd ] Signing a module should only make it trusted by the specific kernel it was built for, not anything else. Loading a signed module meant for a kernel with a different ABI could have interesting effects. Therefore, treat all signatures as invalid when a module is force-loaded. Signed-off-by: Ben Hutchings Cc: stable@vger.kernel.org Signed-off-by: Rusty Russell Signed-off-by: Sasha Levin commit 7e6f0e1e3091dc9aada9d067aac7adbb5a9d9b06 Author: Vegard Nossum Date: Sat Jul 23 07:43:50 2016 +0200 net/irda: fix NULL pointer dereference on memory allocation failure [ Upstream commit d3e6952cfb7ba5f4bfa29d4803ba91f96ce1204d ] I ran into this: kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] PREEMPT SMP KASAN CPU: 2 PID: 2012 Comm: trinity-c3 Not tainted 4.7.0-rc7+ #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 task: ffff8800b745f2c0 ti: ffff880111740000 task.ti: ffff880111740000 RIP: 0010:[] [] irttp_connect_request+0x36/0x710 RSP: 0018:ffff880111747bb8 EFLAGS: 00010286 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000069dd8358 RDX: 0000000000000009 RSI: 0000000000000027 RDI: 0000000000000048 RBP: ffff880111747c00 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000069dd8358 R11: 1ffffffff0759723 R12: 0000000000000000 R13: ffff88011a7e4780 R14: 0000000000000027 R15: 0000000000000000 FS: 00007fc738404700(0000) GS:ffff88011af00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc737fdfb10 CR3: 0000000118087000 CR4: 00000000000006e0 Stack: 0000000000000200 ffff880111747bd8 ffffffff810ee611 ffff880119f1f220 ffff880119f1f4f8 ffff880119f1f4f0 ffff88011a7e4780 ffff880119f1f232 ffff880119f1f220 ffff880111747d58 ffffffff82bca542 0000000000000000 Call Trace: [] irda_connect+0x562/0x1190 [] SYSC_connect+0x202/0x2a0 [] SyS_connect+0x9/0x10 [] do_syscall_64+0x19c/0x410 [] entry_SYSCALL64_slow_path+0x25/0x25 Code: 41 89 ca 48 89 e5 41 57 41 56 41 55 41 54 41 89 d7 53 48 89 fb 48 83 c7 48 48 89 fa 41 89 f6 48 c1 ea 03 48 83 ec 20 4c 8b 65 10 <0f> b6 04 02 84 c0 74 08 84 c0 0f 8e 4c 04 00 00 80 7b 48 00 74 RIP [] irttp_connect_request+0x36/0x710 RSP ---[ end trace 4cda2588bc055b30 ]--- The problem is that irda_open_tsap() can fail and leave self->tsap = NULL, and then irttp_connect_request() almost immediately dereferences it. Cc: stable@vger.kernel.org Signed-off-by: Vegard Nossum Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7d06f7f8963d8a705aeda1a5b60a69bfca75935e Author: Wei Fang Date: Wed Jul 6 11:32:20 2016 +0800 fs/dcache.c: avoid soft-lockup in dput() [ Upstream commit 47be61845c775643f1aa4d2a54343549f943c94c ] We triggered soft-lockup under stress test which open/access/write/close one file concurrently on more than five different CPUs: WARN: soft lockup - CPU#0 stuck for 11s! [who:30631] ... [] dput+0x100/0x298 [] terminate_walk+0x4c/0x60 [] path_lookupat+0x5cc/0x7a8 [] filename_lookup+0x38/0xf0 [] user_path_at_empty+0x78/0xd0 [] user_path_at+0x1c/0x28 [] SyS_faccessat+0xb4/0x230 ->d_lock trylock may failed many times because of concurrently operations, and dput() may execute a long time. Fix this by replacing cpu_relax() with cond_resched(). dput() used to be sleepable, so make it sleepable again should be safe. Cc: Signed-off-by: Wei Fang Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 49e3c9aeeaa4053af7aca53e76defe0f0908d4e3 Author: Huacai Chen Date: Fri Jul 22 11:46:31 2016 +0800 MIPS: Don't register r4k sched clock when CPUFREQ enabled [ Upstream commit 07d69579e7fec27e371296d8ca9d6076fc401b5c ] Don't register r4k sched clock when CPUFREQ enabled because sched clock need a constant frequency. Signed-off-by: Huacai Chen Cc: John Crispin Cc: Steven J . Hill Cc: Fuxin Zhang Cc: Zhangjin Wu Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13820/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 0e2cbad6d084a9c7370f25c991fcdc7bf811b197 Author: Benjamin Coddington Date: Mon Jul 18 10:41:57 2016 -0400 nfs: don't create zero-length requests [ Upstream commit 149a4fddd0a72d526abbeac0c8deaab03559836a ] NFS doesn't expect requests with wb_bytes set to zero and may make unexpected decisions about how to handle that request at the page IO layer. Skip request creation if we won't have any wb_bytes in the request. Signed-off-by: Benjamin Coddington Signed-off-by: Alexey Dobriyan Reviewed-by: Weston Andros Adamson Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit e1cc0756ae6a4ff0a28542c38258b7a26cf3effe Author: Andy Shevchenko Date: Wed Jul 6 12:50:12 2016 +0300 gpio: intel-mid: Remove potentially harmful code [ Upstream commit 3dbd3212f81b2b410a34a922055e2da792864829 ] The commit d56d6b3d7d69 ("gpio: langwell: add Intel Merrifield support") doesn't look at all as a proper support for Intel Merrifield and I dare to say that it distorts the behaviour of the hardware. The register map is different on Intel Merrifield, i.e. only 6 out of 8 register have the same purpose but none of them has same location in the address space. The current case potentially harmful to existing hardware since it's poking registers on wrong offsets and may set some pin to be GPIO output when connected hardware doesn't expect such. Besides the above GPIO and pinctrl on Intel Merrifield have been located in different IP blocks. The functionality has been extended as well, i.e. added support of level interrupts, special registers for wake capable sources and thus, in my opinion, requires a completele separate driver. If someone wondering the existing gpio-intel-mid.c would be converted to actual pinctrl (which by the fact it is now), though I wouldn't be a volunteer to do that. Fixes: d56d6b3d7d69 ("gpio: langwell: add Intel Merrifield support") Cc: stable@vger.kernel.org # v3.13+ Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 7f5a3c76f3d4fe9a0aa9c659249757a2b31db42f Author: Feng Li Date: Tue Jul 12 06:15:44 2016 +0800 iscsi-target: Fix panic when adding second TCP connection to iSCSI session [ Upstream commit 8abc718de6e9e52d8a6bfdb735060554aeae25e4 ] In MC/S scenario, the conn->sess has been set NULL in iscsi_login_non_zero_tsih_s1 when the second connection comes here, then kernel panic. The conn->sess will be assigned in iscsi_login_non_zero_tsih_s2. So we should check whether it's NULL before calling. Signed-off-by: Feng Li Tested-by: Sumit Rai Cc: stable@vger.kernel.org # 3.14+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 634a3fc5f16470e9b78ccd7ce643305122d5ebb2 Author: Paul Moore Date: Tue Jul 19 17:42:57 2016 -0400 audit: fix a double fetch in audit_log_single_execve_arg() [ Upstream commit 43761473c254b45883a64441dd0bc85a42f3645c ] There is a double fetch problem in audit_log_single_execve_arg() where we first check the execve(2) argumnets for any "bad" characters which would require hex encoding and then re-fetch the arguments for logging in the audit record[1]. Of course this leaves a window of opportunity for an unsavory application to munge with the data. This patch reworks things by only fetching the argument data once[2] into a buffer where it is scanned and logged into the audit records(s). In addition to fixing the double fetch, this patch improves on the original code in a few other ways: better handling of large arguments which require encoding, stricter record length checking, and some performance improvements (completely unverified, but we got rid of some strlen() calls, that's got to be a good thing). As part of the development of this patch, I've also created a basic regression test for the audit-testsuite, the test can be tracked on GitHub at the following link: * https://github.com/linux-audit/audit-testsuite/issues/25 [1] If you pay careful attention, there is actually a triple fetch problem due to a strnlen_user() call at the top of the function. [2] This is a tiny white lie, we do make a call to strnlen_user() prior to fetching the argument data. I don't like it, but due to the way the audit record is structured we really have no choice unless we copy the entire argument at once (which would require a rather wasteful allocation). The good news is that with this patch the kernel no longer relies on this strnlen_user() value for anything beyond recording it in the log, we also update it with a trustworthy value whenever possible. Reported-by: Pengfei Wang Cc: Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit a4664afa0dffd5340c61511d3da14e30bfd01517 Author: Linus Torvalds Date: Wed Jul 8 09:33:38 2015 -0700 Fix broken audit tests for exec arg len [ Upstream commit 45820c294fe1b1a9df495d57f40585ef2d069a39 ] The "fix" in commit 0b08c5e5944 ("audit: Fix check of return value of strnlen_user()") didn't fix anything, it broke things. As reported by Steven Rostedt: "Yes, strnlen_user() returns 0 on fault, but if you look at what len is set to, than you would notice that on fault len would be -1" because we just subtracted one from the return value. So testing against 0 doesn't test for a fault condition, it tests against a perfectly valid empty string. Also fix up the usual braindamage wrt using WARN_ON() inside a conditional - make it part of the conditional and remove the explicit unlikely() (which is already part of the WARN_ON*() logic, exactly so that you don't have to write unreadable code. Reported-and-tested-by: Steven Rostedt Cc: Jan Kara Cc: Paul Moore Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a49b282f08d96cd73838e4e1a5ace747d432ba7d Author: Jan Kara Date: Tue Jun 2 17:08:29 2015 +0200 audit: Fix check of return value of strnlen_user() [ Upstream commit 0b08c5e59441d08ab4b5e72afefd5cd98a4d83df ] strnlen_user() returns 0 when it hits fault, not -1. Fix the test in audit_log_single_execve_arg(). Luckily this shouldn't ever happen unless there's a kernel bug so it's mostly a cosmetic fix. CC: Paul Moore Signed-off-by: Jan Kara Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit dd265663a1a9a14d80ea34d9bde9b15d7b614bd2 Author: Rabin Vincent Date: Tue Jul 19 09:26:21 2016 +0200 cifs: fix crash due to race in hmac(md5) handling [ Upstream commit bd975d1eead2558b76e1079e861eacf1f678b73b ] The secmech hmac(md5) structures are present in the TCP_Server_Info struct and can be shared among multiple CIFS sessions. However, the server mutex is not currently held when these structures are allocated and used, which can lead to a kernel crashes, as in the scenario below: mount.cifs(8) #1 mount.cifs(8) #2 Is secmech.sdeschmaccmd5 allocated? // false Is secmech.sdeschmaccmd5 allocated? // false secmech.hmacmd = crypto_alloc_shash.. secmech.sdeschmaccmd5 = kzalloc.. sdeschmaccmd5->shash.tfm = &secmec.hmacmd; secmech.sdeschmaccmd5 = kzalloc // sdeschmaccmd5->shash.tfm // not yet assigned crypto_shash_update() deref NULL sdeschmaccmd5->shash.tfm Unable to handle kernel paging request at virtual address 00000030 epc : 8027ba34 crypto_shash_update+0x38/0x158 ra : 8020f2e8 setup_ntlmv2_rsp+0x4bc/0xa84 Call Trace: crypto_shash_update+0x38/0x158 setup_ntlmv2_rsp+0x4bc/0xa84 build_ntlmssp_auth_blob+0xbc/0x34c sess_auth_rawntlmssp_authenticate+0xac/0x248 CIFS_SessSetup+0xf0/0x178 cifs_setup_session+0x4c/0x84 cifs_get_smb_ses+0x2c8/0x314 cifs_mount+0x38c/0x76c cifs_do_mount+0x98/0x440 mount_fs+0x20/0xc0 vfs_kern_mount+0x58/0x138 do_mount+0x1e8/0xccc SyS_mount+0x88/0xd4 syscall_common+0x30/0x54 Fix this by locking the srv_mutex around the code which uses these hmac(md5) structures. All the other secmech algos already have similar locking. Fixes: 95dc8dd14e2e84cc ("Limit allocation of crypto mechanisms to dialect which requires") Signed-off-by: Rabin Vincent Acked-by: Sachin Prabhu CC: Stable Signed-off-by: Steve French Signed-off-by: Sasha Levin commit b9090fe48d172c2bb3d59d521fe6e9f317f39ad7 Author: Nicholas Bellinger Date: Thu Jun 2 14:56:45 2016 -0700 target: Fix race between iscsi-target connection shutdown + ABORT_TASK [ Upstream commit 064cdd2d91c2805d788876082f31cc63506f22c3 ] This patch fixes a race in iscsit_release_commands_from_conn() -> iscsit_free_cmd() -> transport_generic_free_cmd() + wait_for_tasks=1, where CMD_T_FABRIC_STOP could end up being set after the final kref_put() is called from core_tmr_abort_task() context. This results in transport_generic_free_cmd() blocking indefinately on se_cmd->cmd_wait_comp, because the target_release_cmd_kref() check for CMD_T_FABRIC_STOP returns false. To address this bug, make iscsit_release_commands_from_conn() do list_splice and set CMD_T_FABRIC_STOP early while holding iscsi_conn->cmd_lock. Also make iscsit_aborted_task() only remove iscsi_cmd_t if CMD_T_FABRIC_STOP has not already been set. Finally in target_release_cmd_kref(), only honor fabric_stop if CMD_T_ABORTED has been set. Cc: Mike Christie Cc: Quinn Tran Cc: Himanshu Madhani Cc: Christoph Hellwig Cc: Hannes Reinecke Cc: stable@vger.kernel.org # 3.14+ Tested-by: Nicholas Bellinger Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 6c631d3eb5c8b930911ca73ecf596eebd87a6be2 Author: Nicholas Bellinger Date: Wed May 25 12:25:04 2016 -0700 target: Fix missing complete during ABORT_TASK + CMD_T_FABRIC_STOP [ Upstream commit 5e2c956b8aa24d4f33ff7afef92d409eed164746 ] During transport_generic_free_cmd() with a concurrent TMR ABORT_TASK and shutdown CMD_T_FABRIC_STOP bit set, the caller will be blocked on se_cmd->cmd_wait_stop completion until the final kref_put() -> target_release_cmd_kref() has been invoked to call complete(). However, when ABORT_TASK is completed with FUNCTION_COMPLETE in core_tmr_abort_task(), the aborted se_cmd will have already been removed from se_sess->sess_cmd_list via list_del_init(). This results in target_release_cmd_kref() hitting the legacy list_empty() == true check, invoking ->release_cmd() but skipping complete() to wakeup se_cmd->cmd_wait_stop blocked earlier in transport_generic_free_cmd() code. To address this bug, it's safe to go ahead and drop the original list_empty() check so that fabric_stop invokes the complete() as expected, since list_del_init() can safely be used on a empty list. Cc: Mike Christie Cc: Quinn Tran Cc: Himanshu Madhani Cc: Christoph Hellwig Cc: Hannes Reinecke Cc: stable@vger.kernel.org # 3.14+ Tested-by: Nicholas Bellinger Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 80d341fee312c8c1c039dcb73c8309551446b21c Author: Hector Palacios Date: Mon Jul 18 10:39:18 2016 +0200 mtd: nand: fix bug writing 1 byte less than page size [ Upstream commit 144f4c98399e2c0ca60eb414c15a2c68125c18b8 ] nand_do_write_ops() determines if it is writing a partial page with the formula: part_pagewr = (column || writelen < (mtd->writesize - 1)) When 'writelen' is exactly 1 byte less than the NAND page size the formula equates to zero, so the code doesn't process it as a partial write, although it should. As a consequence the function remains in the while(1) loop with 'writelen' becoming 0xffffffff and iterating endlessly. The bug may not be easy to reproduce in Linux since user space tools usually force the padding or round-up the write size to a page-size multiple. This was discovered in U-Boot where the issue can be reproduced by writing any size that is 1 byte less than a page-size multiple. For example, on a NAND with 2K page (0x800): => nand erase.part => nand write $loadaddr 7ff [Editor's note: the bug was added in commit 29072b96078f, but moved around in commit 66507c7bc8895 ("mtd: nand: Add support to use nand_base poi databuf as bounce buffer")] Fixes: 29072b96078f ("[MTD] NAND: add subpage write support") Signed-off-by: Hector Palacios Acked-by: Boris Brezillon Cc: Signed-off-by: Brian Norris Signed-off-by: Sasha Levin commit 8ae0073fa1cb99a655eb674cac241e10a03b02fe Author: Will Deacon Date: Tue Jul 19 15:07:37 2016 +0100 arm64: debug: unmask PSTATE.D earlier [ Upstream commit 2ce39ad15182604beb6c8fa8bed5e46b59fd1082 ] Clearing PSTATE.D is one of the requirements for generating a debug exception. The arm64 booting protocol requires that PSTATE.D is set, since many of the debug registers (for example, the hw_breakpoint registers) are UNKNOWN out of reset and could potentially generate spurious, fatal debug exceptions in early boot code if PSTATE.D was clear. Once the debug registers have been safely initialised, PSTATE.D is cleared, however this is currently broken for two reasons: (1) The boot CPU clears PSTATE.D in a postcore_initcall and secondary CPUs clear PSTATE.D in secondary_start_kernel. Since the initcall runs after SMP (and the scheduler) have been initialised, there is no guarantee that it is actually running on the boot CPU. In this case, the boot CPU is left with PSTATE.D set and is not capable of generating debug exceptions. (2) In a preemptible kernel, we may explicitly schedule on the IRQ return path to EL1. If an IRQ occurs with PSTATE.D set in the idle thread, then we may schedule the kthread_init thread, run the postcore_initcall to clear PSTATE.D and then context switch back to the idle thread before returning from the IRQ. The exception return path will then restore PSTATE.D from the stack, and set it again. This patch fixes the problem by moving the clearing of PSTATE.D earlier to proc.S. This has the desirable effect of clearing it in one place for all CPUs, long before we have to worry about the scheduler or any exception handling. We ensure that the previous reset of MDSCR_EL1 has completed before unmasking the exception, so that any spurious exceptions resulting from UNKNOWN debug registers are not generated. Without this patch applied, the kprobes selftests have been seen to fail under KVM, where we end up attempting to step the OOL instruction buffer with PSTATE.D set and therefore fail to complete the step. Cc: Acked-by: Mark Rutland Reported-by: Catalin Marinas Tested-by: Marc Zyngier Signed-off-by: Will Deacon Reviewed-by: Catalin Marinas Tested-by: Catalin Marinas Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit f88ded2649b5d8345320e2ecdb24c4da64ff3f4f Author: Alim Akhtar Date: Tue Jul 5 15:28:53 2016 +0530 rtc: s3c: Add s3c_rtc_{enable/disable}_clk in s3c_rtc_setfreq() [ Upstream commit 70c96dfac0e231424e17743bd52f6cd2ff1f2439 ] As per code flow s3c_rtc_setfreq() will get called with rtc clock disabled and in set_freq we perform h/w registers read/write, which results in a kernel crash on exynos7 platform while probing rtc driver. Below is code flow: s3c_rtc_probe() clk_prepare_enable(info->rtc_clk) // rtc clock enabled s3c_rtc_gettime() // will enable clk if not done, and disable it upon exit s3c_rtc_setfreq() //then this will be called with clk disabled This patch take cares of such issue by adding s3c_rtc_{enable/disable}_clk in s3c_rtc_setfreq(). Fixes: 24e1455493da ("drivers/rtc/rtc-s3c.c: delete duplicate clock control") Cc: Signed-off-by: Alim Akhtar Reviewed-by: Krzysztof Kozlowski Reviewed-by: Pankaj Dubey Tested-by: Pankaj Dubey Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit abf9569225763ab83a538530454f7d280fd08e4a Author: Sasha Levin Date: Sun Aug 14 18:50:25 2016 -0400 dm: fix second blk_delay_queue() parameter to be in msec units not jiffies [ Upstream commit bd9f55ea1cf6e14eb054b06ea877d2d1fa339514 ] Commit d548b34b062 ("dm: reduce the queue delay used in dm_request_fn from 100ms to 10ms") always intended the value to be 10 msecs -- it just expressed it in jiffies because earlier commit 7eaceaccab ("block: remove per-queue plugging") did. Signed-off-by: Tahsin Erdogan Signed-off-by: Mike Snitzer Fixes: d548b34b062 ("dm: reduce the queue delay used in dm_request_fn from 100ms to 10ms") Cc: stable@vger.kernel.org # 4.1+ -- stable@ backports must be applied to drivers/md/dm.c Signed-off-by: Sasha Levin commit 812925986c9f0398f9a15228580cf4d38fdd1577 Author: Herbert Xu Date: Tue Jul 12 13:17:57 2016 +0800 crypto: scatterwalk - Fix test in scatterwalk_done [ Upstream commit 5f070e81bee35f1b7bd1477bb223a873ff657803 ] When there is more data to be processed, the current test in scatterwalk_done may prevent us from calling pagedone even when we should. In particular, if we're on an SG entry spanning multiple pages where the last page is not a full page, we will incorrectly skip calling pagedone on the second last page. This patch fixes this by adding a separate test for whether we've reached the end of a page. Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 98953c4c44a70f6cecc9cd2df86412bba34e37e6 Author: Amadeusz Sławiński Date: Thu Jul 14 10:50:23 2016 +0200 Bluetooth: Fix l2cap_sock_setsockopt() with optname BT_RCVMTU [ Upstream commit 23bc6ab0a0912146fd674a0becc758c3162baabc ] When we retrieve imtu value from userspace we should use 16 bit pointer cast instead of 32 as it's defined that way in headers. Fixes setsockopt calls on big-endian platforms. Signed-off-by: Amadeusz Sławiński Signed-off-by: Marcel Holtmann Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 5436aa6c963c736d49ff256ce51f632d2a65f6d0 Author: Cao, Lei Date: Fri Jul 15 13:54:04 2016 +0000 KVM: VMX: handle PML full VMEXIT that occurs during event delivery [ Upstream commit b244c9fc251e14a083a1cbf04bef10bd99303a76 ] With PML enabled, guest will shut down if a PML full VMEXIT occurs during event delivery. According to Intel SDM 27.2.3, PML full VMEXIT can occur when event is being delivered through IDT, so KVM should not exit to user space with error. Instead, it should let EXIT_REASON_PML_FULL go through and the event will be re-injected on the next VMENTRY. Signed-off-by: Lei Cao Cc: stable@vger.kernel.org Fixes: 843e4330573c ("KVM: VMX: Add PML support in VMX") [Shortened the summary and Cc'd stable.] Signed-off-by: Radim Krčmář Signed-off-by: Sasha Levin commit aef1e06da0d03039075d4b5ae8ff95b1a856c8ba Author: Daniele Palmas Date: Mon Jun 6 12:38:17 2016 +0200 USB: serial: option: add support for Telit LE910 PID 0x1206 [ Upstream commit 3c0415fa08548e3bc63ef741762664497ab187ed ] This patch adds support for 0x1206 PID of Telit LE910. Since the interfaces positions are the same than the ones for 0x1043 PID of Telit LE922, telit_le922_blacklist_usbcfg3 is used. Signed-off-by: Daniele Palmas Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 4af80d9fc8c6c671da4d578a871e08dea92da26f Author: Michael Neuling Date: Wed Jul 6 14:58:06 2016 +1000 powerpc/tm: Fix stack pointer corruption in __tm_recheckpoint() [ Upstream commit 6bcb80143e792becfd2b9cc6a339ce523e4e2219 ] At the start of __tm_recheckpoint() we save the kernel stack pointer (r1) in SPRG SCRATCH0 (SPRG2) so that we can restore it after the trecheckpoint. Unfortunately, the same SPRG is used in the SLB miss handler. If an SLB miss is taken between the save and restore of r1 to the SPRG, the SPRG is changed and hence r1 is also corrupted. We can end up with the following crash when we start using r1 again after the restore from the SPRG: Oops: Bad kernel stack pointer, sig: 6 [#1] SMP NR_CPUS=2048 NUMA pSeries CPU: 658 PID: 143777 Comm: htm_demo Tainted: G EL X 4.4.13-0-default #1 task: c0000b56993a7810 ti: c00000000cfec000 task.ti: c0000b56993bc000 NIP: c00000000004f188 LR: 00000000100040b8 CTR: 0000000010002570 REGS: c00000000cfefd40 TRAP: 0300 Tainted: G EL X (4.4.13-0-default) MSR: 8000000300001033 CR: 02000424 XER: 20000000 CFAR: c000000000008468 DAR: 00003ffd84e66880 DSISR: 40000000 SOFTE: 0 PACATMSCRATCH: 00003ffbc865e680 GPR00: fffffffcfabc4268 00003ffd84e667a0 00000000100d8c38 000000030544bb80 GPR04: 0000000000000002 00000000100cf200 0000000000000449 00000000100cf100 GPR08: 000000000000c350 0000000000002569 0000000000002569 00000000100d6c30 GPR12: 00000000100d6c28 c00000000e6a6b00 00003ffd84660000 0000000000000000 GPR16: 0000000000000003 0000000000000449 0000000010002570 0000010009684f20 GPR20: 0000000000800000 00003ffd84e5f110 00003ffd84e5f7a0 00000000100d0f40 GPR24: 0000000000000000 0000000000000000 0000000000000000 00003ffff0673f50 GPR28: 00003ffd84e5e960 00000000003d0f00 00003ffd84e667a0 00003ffd84e5e680 NIP [c00000000004f188] restore_gprs+0x110/0x17c LR [00000000100040b8] 0x100040b8 Call Trace: Instruction dump: f8a1fff0 e8e700a8 38a00000 7ca10164 e8a1fff8 e821fff0 7c0007dd 7c421378 7db142a6 7c3242a6 38800002 7c810164 e9e100e8 ea0100f0 ea2100f8 We hit this on large memory machines (> 2TB) but it can also be hit on smaller machines when 1TB segments are disabled. To hit this, you also need to be virtualised to ensure SLBs are periodically removed by the hypervisor. This patches moves the saving of r1 to the SPRG to the region where we are guaranteed not to take any further SLB misses. Fixes: 98ae22e15b43 ("powerpc: Add helper functions for transactional memory context switching") Cc: stable@vger.kernel.org # v3.9+ Signed-off-by: Michael Neuling Acked-by: Cyril Bur Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 572c8b69051d58586accd392fc2699b84a1ae326 Author: Michael Neuling Date: Tue Jun 28 13:01:04 2016 +1000 powerpc/tm: Avoid SLB faults in treclaim/trecheckpoint when RI=0 [ Upstream commit 190ce8693c23eae09ba5f303a83bf2fbeb6478b1 ] Currently we have 2 segments that are bolted for the kernel linear mapping (ie 0xc000... addresses). This is 0 to 1TB and also the kernel stacks. Anything accessed outside of these regions may need to be faulted in. (In practice machines with TM always have 1T segments) If a machine has < 2TB of memory we never fault on the kernel linear mapping as these two segments cover all physical memory. If a machine has > 2TB of memory, there may be structures outside of these two segments that need to be faulted in. This faulting can occur when running as a guest as the hypervisor may remove any SLB that's not bolted. When we treclaim and trecheckpoint we have a window where we need to run with the userspace GPRs. This means that we no longer have a valid stack pointer in r1. For this window we therefore clear MSR RI to indicate that any exceptions taken at this point won't be able to be handled. This means that we can't take segment misses in this RI=0 window. In this RI=0 region, we currently access the thread_struct for the process being context switched to or from. This thread_struct access may cause a segment fault since it's not guaranteed to be covered by the two bolted segment entries described above. We've seen this with a crash when running as a guest with > 2TB of memory on PowerVM: Unrecoverable exception 4100 at c00000000004f138 Oops: Unrecoverable exception, sig: 6 [#1] SMP NR_CPUS=2048 NUMA pSeries CPU: 1280 PID: 7755 Comm: kworker/1280:1 Tainted: G X 4.4.13-46-default #1 task: c000189001df4210 ti: c000189001d5c000 task.ti: c000189001d5c000 NIP: c00000000004f138 LR: 0000000010003a24 CTR: 0000000010001b20 REGS: c000189001d5f730 TRAP: 4100 Tainted: G X (4.4.13-46-default) MSR: 8000000100001031 CR: 24000048 XER: 00000000 CFAR: c00000000004ed18 SOFTE: 0 GPR00: ffffffffc58d7b60 c000189001d5f9b0 00000000100d7d00 000000003a738288 GPR04: 0000000000002781 0000000000000006 0000000000000000 c0000d1f4d889620 GPR08: 000000000000c350 00000000000008ab 00000000000008ab 00000000100d7af0 GPR12: 00000000100d7ae8 00003ffe787e67a0 0000000000000000 0000000000000211 GPR16: 0000000010001b20 0000000000000000 0000000000800000 00003ffe787df110 GPR20: 0000000000000001 00000000100d1e10 0000000000000000 00003ffe787df050 GPR24: 0000000000000003 0000000000010000 0000000000000000 00003fffe79e2e30 GPR28: 00003fffe79e2e68 00000000003d0f00 00003ffe787e67a0 00003ffe787de680 NIP [c00000000004f138] restore_gprs+0xd0/0x16c LR [0000000010003a24] 0x10003a24 Call Trace: [c000189001d5f9b0] [c000189001d5f9f0] 0xc000189001d5f9f0 (unreliable) [c000189001d5fb90] [c00000000001583c] tm_recheckpoint+0x6c/0xa0 [c000189001d5fbd0] [c000000000015c40] __switch_to+0x2c0/0x350 [c000189001d5fc30] [c0000000007e647c] __schedule+0x32c/0x9c0 [c000189001d5fcb0] [c0000000007e6b58] schedule+0x48/0xc0 [c000189001d5fce0] [c0000000000deabc] worker_thread+0x22c/0x5b0 [c000189001d5fd80] [c0000000000e7000] kthread+0x110/0x130 [c000189001d5fe30] [c000000000009538] ret_from_kernel_thread+0x5c/0xa4 Instruction dump: 7cb103a6 7cc0e3a6 7ca222a6 78a58402 38c00800 7cc62838 08860000 7cc000a6 38a00006 78c60022 7cc62838 0b060000 7ccff120 e8270078 e8a70098 ---[ end trace 602126d0a1dedd54 ]--- This fixes this by copying the required data from the thread_struct to the stack before we clear MSR RI. Then once we clear RI, we only access the stack, guaranteeing there's no segment miss. We also tighten the region over which we set RI=0 on the treclaim() path. This may have a slight performance impact since we're adding an mtmsr instruction. Fixes: 090b9284d725 ("powerpc/tm: Clear MSR RI in non-recoverable TM code") Signed-off-by: Michael Neuling Reviewed-by: Cyril Bur Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 881052c264a9a44481f1a29d4877478e54b4c690 Author: Vegard Nossum Date: Thu Jul 14 23:21:35 2016 -0400 ext4: short-cut orphan cleanup on error [ Upstream commit c65d5c6c81a1f27dec5f627f67840726fcd146de ] If we encounter a filesystem error during orphan cleanup, we should stop. Otherwise, we may end up in an infinite loop where the same inode is processed again and again. EXT4-fs (loop0): warning: checktime reached, running e2fsck is recommended EXT4-fs error (device loop0): ext4_mb_generate_buddy:758: group 2, block bitmap and bg descriptor inconsistent: 6117 vs 0 free clusters Aborting journal on device loop0-8. EXT4-fs (loop0): Remounting filesystem read-only EXT4-fs error (device loop0) in ext4_free_blocks:4895: Journal has aborted EXT4-fs error (device loop0) in ext4_do_update_inode:4893: Journal has aborted EXT4-fs error (device loop0) in ext4_do_update_inode:4893: Journal has aborted EXT4-fs error (device loop0) in ext4_ext_remove_space:3068: IO failure EXT4-fs error (device loop0) in ext4_ext_truncate:4667: Journal has aborted EXT4-fs error (device loop0) in ext4_orphan_del:2927: Journal has aborted EXT4-fs error (device loop0) in ext4_do_update_inode:4893: Journal has aborted EXT4-fs (loop0): Inode 16 (00000000618192a0): orphan list check failed! [...] EXT4-fs (loop0): Inode 16 (0000000061819748): orphan list check failed! [...] EXT4-fs (loop0): Inode 16 (0000000061819bf0): orphan list check failed! [...] See-also: c9eb13a9105 ("ext4: fix hang when processing corrupted orphaned inode list") Cc: Jan Kara Signed-off-by: Vegard Nossum Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 3f7ed29b1299823a4460c7cf4bdebfe13db23bf9 Author: Alex Deucher Date: Fri Jul 8 17:27:04 2016 -0400 drm/radeon: support backlight control for UNIPHY3 [ Upstream commit d3200be6c423afa1c34f7e39e9f6d04dd5b0af9d ] Same interface as other UNIPHY blocks Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 6c2ca21665b99ce2f76389c353b985d8195387cc Author: Jim Mattson Date: Fri Jul 8 15:36:06 2016 -0700 KVM: nVMX: Fix memory corruption when using VMCS shadowing [ Upstream commit 2f1fe81123f59271bddda673b60116bde9660385 ] When freeing the nested resources of a vcpu, there is an assumption that the vcpu's vmcs01 is the current VMCS on the CPU that executes nested_release_vmcs12(). If this assumption is violated, the vcpu's vmcs01 may be made active on multiple CPUs at the same time, in violation of Intel's specification. Moreover, since the vcpu's vmcs01 is not VMCLEARed on every CPU on which it is active, it can linger in a CPU's VMCS cache after it has been freed and potentially repurposed. Subsequent eviction from the CPU's VMCS cache on a capacity miss can result in memory corruption. It is not sufficient for vmx_free_vcpu() to call vmx_load_vmcs01(). If the vcpu in question was last loaded on a different CPU, it must be migrated to the current CPU before calling vmx_load_vmcs01(). Signed-off-by: Jim Mattson Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 53bb06cb222c5f03eacec544564e3751f7564fe9 Author: Joseph Salisbury Date: Wed Jul 6 21:18:51 2016 -0400 usb: quirks: Add no-lpm quirk for Elan [ Upstream commit 25b1f9acc452209ae0fcc8c1332be852b5c52f53 ] BugLink: http://bugs.launchpad.net/bugs/1498667 As reported in BugLink, this device has an issue with Linux Power Management so adding a quirk. This quirk was reccomended by Alan Stern: http://lkml.iu.edu/hypermail/linux/kernel/1606.2/05590.html Signed-off-by: Joseph Salisbury Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit bd0702ff1a33c5fd28844c57e5812e039ea168d6 Author: Adrien Vergé Date: Tue Nov 24 16:02:04 2015 +0100 USB: quirks: Fix another ELAN touchscreen [ Upstream commit df36c5bede207f734e4750beb2b14fb892050280 ] Like other buggy models that had their fixes [1], the touchscreen with id 04f3:21b8 from ELAN Microelectronics needs the device-qualifier quirk. Otherwise, it fails to respond, blocks the boot for a random amount of time and pollutes dmesg with: [ 2887.373196] usb 1-5: new full-speed USB device number 41 using xhci_hcd [ 2889.502000] usb 1-5: unable to read config index 0 descriptor/start: -71 [ 2889.502005] usb 1-5: can't read configurations, error -71 [ 2889.654571] usb 1-5: new full-speed USB device number 42 using xhci_hcd [ 2891.783438] usb 1-5: unable to read config index 0 descriptor/start: -71 [ 2891.783443] usb 1-5: can't read configurations, error -71 [1]: See commits c68929f, 876af5d, d749947, a32c99e and dc703ec. Tested-by: Adrien Vergé Signed-off-by: Adrien Vergé Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 256679c2a67b4ec06c207bb8bfa9e9f64f482ed8 Author: Sasha Levin Date: Sun Aug 14 18:23:56 2016 -0400 s390/mm: fix gmap tlb flush issues [ Upstream commit f045402984404ddc11016358411e445192919047 ] __tlb_flush_asce() should never be used if multiple asce belong to a mm. As this function changes mm logic determining if local or global tlb flushes will be neded, we might end up flushing only the gmap asce on all CPUs and a follow up mm asce flushes will only flush on the local CPU, although that asce ran on multiple CPUs. The missing tlb flushes will provoke strange faults in user space and even low address protections in user space, crashing the kernel. Fixes: 1b948d6caec4 ("s390/mm,tlb: optimize TLB flushing for zEC12") Cc: stable@vger.kernel.org # 3.15+ Reported-by: Sascha Silbe Acked-by: Martin Schwidefsky Signed-off-by: David Hildenbrand Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 9b01eafbc9514e71056e0a1a4714606385a431a4 Author: Sachin Prabhu Date: Thu Jul 7 21:28:27 2016 +0100 cifs: Check for existing directory when opening file with O_CREAT [ Upstream commit 8d9535b6efd86e6c07da59f97e68f44efb7fe080 ] When opening a file with O_CREAT flag, check to see if the file opened is an existing directory. This prevents the directory from being opened which subsequently causes a crash when the close function for directories cifs_closedir() is called which frees up the file->private_data memory while the file is still listed on the open file list for the tcon. Signed-off-by: Sachin Prabhu Signed-off-by: Steve French CC: Stable Reported-by: Xiaoli Feng Signed-off-by: Sasha Levin commit bdf3214616dd38384c9716ce96a18b779e233224 Author: Matthew Leach Date: Fri Jul 8 09:04:27 2016 -0300 [media] media: usbtv: prevent access to free'd resources [ Upstream commit 2a00932f082aff93c3a55426e0c7af6d0ec03997 ] When disconnecting the usbtv device, the sound card is unregistered from ALSA and the snd member of the usbtv struct is set to NULL. If the usbtv snd_trigger work is running, this can cause a race condition where the kernel will attempt to access free'd resources, shown in [1]. This patch fixes the disconnection code by cancelling any snd_trigger work before unregistering the sound card from ALSA and checking that the snd member still exists in the work function. [1]: usb 3-1.2: USB disconnect, device number 6 BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: [] process_one_work+0x30/0x480 PGD 405bbf067 PUD 405bbe067 PMD 0 Call Trace: [] worker_thread+0x48/0x4e0 [] ? process_one_work+0x480/0x480 [] ? process_one_work+0x480/0x480 [] kthread+0xd8/0xf0 [] ret_from_fork+0x22/0x40 [] ? kthread_worker_fn+0x170/0x170 ---[ end trace 0f3dac5c1a38e610 ]--- Signed-off-by: Matthew Leach Tested-by: Peter Sutton Cc: stable@vger.kernel.org Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 47c1628a3d5ea9803b4175ad8eb0b0f577f16e49 Author: Dmitry Tunin Date: Tue Jul 12 01:35:18 2016 +0300 Bluetooth: Add support of 13d3:3490 AR3012 device [ Upstream commit 12d868964f7352e8b18e755488f7265a93431de1 ] T: Bus=01 Lev=01 Prnt=01 Port=07 Cnt=05 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3490 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb BugLink: https://bugs.launchpad.net/bugs/1600623 Signed-off-by: Dmitry Tunin Signed-off-by: Marcel Holtmann Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 6e2c93c757ece77b43eb12f21c0ab2b985dbbfb4 Author: Lauro Costa Date: Mon May 9 17:36:11 2016 -0300 Bluetooth: Add USB ID 13D3:3487 to ath3k [ Upstream commit 72f9f8b58bc743e6b6abdc68f60db98486c3ffcf ] Add hw id to ath3k usb device list and btusb blacklist T: Bus=01 Lev=01 Prnt=01 Port=08 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3487 Rev=00.02 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Requires these firmwares: ar3k/AthrBT_0x11020100.dfu and ar3k/ramps_0x11020100_40.dfu Firmwares are available in linux-firmware. Device found in a laptop ASUS model N552VW. It's an Atheros AR9462 chip. Signed-off-by: Lauro Costa Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 434d638db34386cdf03fb808dbc15e7966ad0745 Author: Jonathan McDowell Date: Sat May 14 14:01:26 2016 -0300 [media] Fix RC5 decoding with Fintek CIR chipset [ Upstream commit bbdb34c90aeb8b2253eae88029788ebe1d7f2fd4 ] Fix RC5 decoding with Fintek CIR chipset Commit e87b540be2dd02552fb9244d50ae8b4e4619a34b tightened up the RC5 decoding by adding a check for trailing silence to ensure a valid RC5 command had been received. Unfortunately the trailer length checked was 10 units and the Fintek CIR device does not want to provide details of a space longer than 6350us. This meant that RC5 remotes working on a Fintek setup on 3.16 failed on 3.17 and later. Fix this by shortening the trailer check to 6 units (allowing for a previous space in the received remote command). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=117221 Signed-off-by: Jonathan McDowell Cc: stable@vger.kernel.org Signed-off-by: David Härdeman Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 2342f6e61999e3ae252b42b617829eaa2d217cf2 Author: Soeren Moch Date: Wed May 11 13:49:11 2016 -0300 [media] media: dvb_ringbuffer: Add memory barriers [ Upstream commit ca6e6126db5494f18c6c6615060d4d803b528bff ] Implement memory barriers according to Documentation/circular-buffers.txt: - use smp_store_release() to update ringbuffer read/write pointers - use smp_load_acquire() to load write pointer on reader side - use ACCESS_ONCE() to load read pointer on writer side This fixes data stream corruptions observed e.g. on an ARM Cortex-A9 quad core system with different types (PCI, USB) of DVB tuners. Signed-off-by: Soeren Moch Cc: stable@vger.kernel.org # 3.14+ Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 7235df953569546d2bab7c335635c13939ea6506 Author: Lyude Date: Fri Jun 24 17:54:31 2016 -0400 drm/radeon: Poll for both connect/disconnect on analog connectors [ Upstream commit 14ff8d48f2235295dfb3117693008e367b49cdb5 ] DRM_CONNECTOR_POLL_CONNECT only enables polling for connections, not disconnections. Because of this, we end up losing hotplug polling for analog connectors once they get connected. Easy way to reproduce: - Grab a machine with a radeon GPU and a VGA port - Plug a monitor into the VGA port, wait for it to update the connector from disconnected to connected - Disconnect the monitor on VGA, a hotplug event is never sent for the removal of the connector. Originally, only using DRM_CONNECTOR_POLL_CONNECT might have been a good idea since doing VGA polling can sometimes result in having to mess with the DAC voltages to figure out whether or not there's actually something there since VGA doesn't have HPD. Doing this would have the potential of showing visible artifacts on the screen every time we ran a poll while a VGA display was connected. Luckily, radeon_vga_detect() only resorts to this sort of polling if the poll is forced, and DRM's polling helper doesn't force it's polls. Additionally, this removes some assignments to connector->polled that weren't actually doing anything. Cc: stable@vger.kernel.org Signed-off-by: Lyude Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4613d5f66ff3b7914d7ae2e2e12ab097038772a6 Author: Alex Deucher Date: Wed Jun 1 12:58:36 2016 -0400 drm/radeon: add a delay after ATPX dGPU power off [ Upstream commit d814b24fb74cb9797d70cb8053961447c5879a5c ] ATPX dGPU power control requires a 200ms delay between power off and on. This should fix dGPU failures on resume from power off. Reviewed-by: Hawking Zhang Acked-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 073435ae84da04fa8e3d27f740095382a950458d Author: Andy Shevchenko Date: Wed Jul 6 12:08:11 2016 +0300 spi: pxa2xx: Clear all RFT bits in reset_sccr1() on Intel Quark [ Upstream commit 152bc19e2fc2b7fce7ffbc2a9cea94b147223702 ] It seems the commit e5262d0568dc ("spi: spi-pxa2xx: SPI support for Intel Quark X1000") misses one place to be adapted for Intel Quark, i.e. in reset_sccr1(). Clear all RFT bits when call reset_sccr1() on Intel Quark. Fixes: e5262d0568dc ("spi: spi-pxa2xx: SPI support for Intel Quark X1000") Signed-off-by: Andy Shevchenko Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit d4d783d829cd3ade06c6b39fd7d02f00026ba699 Author: Theodore Ts'o Date: Tue Jul 5 20:01:52 2016 -0400 ext4: validate s_reserved_gdt_blocks on mount [ Upstream commit 5b9554dc5bf008ae7f68a52e3d7e76c0920938a2 ] If s_reserved_gdt_blocks is extremely large, it's possible for ext4_init_block_bitmap(), which is called when ext4 sets up an uninitialized block bitmap, to corrupt random kernel memory. Add the same checks which e2fsck has --- it must never be larger than blocksize / sizeof(__u32) --- and then add a backup check in ext4_init_block_bitmap() in case the superblock gets modified after the file system is mounted. Reported-by: Vegard Nossum Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit d579705ef92535db645c8eeac510f26bbc9a7e9d Author: Sasha Levin Date: Sun Aug 14 18:08:43 2016 -0400 iwlwifi: add new 8260 PCI IDs [ Upstream commit 4b79deece5d45396422d469afa11f9d69ccb3d8b ] Add 3 new 8260 series PCI IDs: - (0x24F3, 0x10B0) - (0x24F3, 0xD0B0) - (0x24F3, 0xB0B0) CC: [4.1+] Signed-off-by: Oren Givon Signed-off-by: David Spinadel Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 2fc0cdf6e9a858c5bf3a1f23a7b673fbf9a3abf4 Author: Hans de Goede Date: Sat Jun 4 12:58:39 2016 +0200 ARM: dts: sunxi: Add a startup delay for fixed regulator enabled phys [ Upstream commit fc51b632c7b047c25807023b76f3877aed19c770 ] It seems that recent kernels have a shorter timeout when scanning for ethernet phys causing us to hit a timeout on boards where the phy's regulator gets enabled just before scanning, which leads to non working ethernet. A 10ms startup delay seems to be enough to fix it, this commit adds a 20ms startup delay just to be safe. This has been tested on a sun4i-a10-a1000 and sun5i-a10s-wobo-i5 board, both of which have non-working ethernet on recent kernels without this fix. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit e19f0ec5aeb659cb7dd2bf6e4f1e842f5ad71fcf Author: Vegard Nossum Date: Mon Jul 4 11:03:00 2016 -0400 ext4: don't call ext4_should_journal_data() on the journal inode [ Upstream commit 6a7fd522a7c94cdef0a3b08acf8e6702056e635c ] If ext4_fill_super() fails early, it's possible for ext4_evict_inode() to call ext4_should_journal_data() before superblock options and flags are fully set up. In that case, the iput() on the journal inode can end up causing a BUG(). Work around this problem by reordering the tests so we only call ext4_should_journal_data() after we know it's not the journal inode. Fixes: 2d859db3e4 ("ext4: fix data corruption in inodes with journalled data") Fixes: 2b405bfa84 ("ext4: fix data=journal fast mount/umount hang") Cc: Jan Kara Cc: stable@vger.kernel.org Signed-off-by: Vegard Nossum Signed-off-by: Theodore Ts'o Reviewed-by: Jan Kara Signed-off-by: Sasha Levin commit 906d6f4d9cdc8509c505f29f6146ec627fef2f06 Author: Jan Kara Date: Mon Jul 4 10:14:01 2016 -0400 ext4: fix deadlock during page writeback [ Upstream commit 646caa9c8e196880b41cd3e3d33a2ebc752bdb85 ] Commit 06bd3c36a733 (ext4: fix data exposure after a crash) uncovered a deadlock in ext4_writepages() which was previously much harder to hit. After this commit xfstest generic/130 reproduces the deadlock on small filesystems. The problem happens when ext4_do_update_inode() sets LARGE_FILE feature and marks current inode handle as synchronous. That subsequently results in ext4_journal_stop() called from ext4_writepages() to block waiting for transaction commit while still holding page locks, reference to io_end, and some prepared bio in mpd structure each of which can possibly block transaction commit from completing and thus results in deadlock. Fix the problem by releasing page locks, io_end reference, and submitting prepared bio before calling ext4_journal_stop(). [ Changed to defer the call to ext4_journal_stop() only if the handle is synchronous. --tytso ] Reported-and-tested-by: Eryu Guan Signed-off-by: Theodore Ts'o CC: stable@vger.kernel.org Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 547df96580692f69627c693cc1d1fe1ea99d652c Author: Trond Myklebust Date: Fri Jun 24 10:55:44 2016 -0400 SUNRPC: Don't allocate a full sockaddr_storage for tracing [ Upstream commit db1bb44c4c7e8d49ed674dc59e5222d99c698088 ] We're always tracing IPv4 or IPv6 addresses, so we can save a lot of space on the ringbuffer by allocating the correct sockaddr size. Signed-off-by: Trond Myklebust Cc: stable@vger.kernel.org Fixes: 83a712e0afef "sunrpc: add some tracepoints around ..." Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit c580d82e1d5532b785e339450d43f82e5a8b4e79 Author: Vegard Nossum Date: Thu Jun 30 11:53:46 2016 -0400 ext4: check for extents that wrap around [ Upstream commit f70749ca42943faa4d4dcce46dfdcaadb1d0c4b6 ] An extent with lblock = 4294967295 and len = 1 will pass the ext4_valid_extent() test: ext4_lblk_t last = lblock + len - 1; if (len == 0 || lblock > last) return 0; since last = 4294967295 + 1 - 1 = 4294967295. This would later trigger the BUG_ON(es->es_lblk + es->es_len < es->es_lblk) in ext4_es_end(). We can simplify it by removing the - 1 altogether and changing the test to use lblock + len <= lblock, since now if len = 0, then lblock + 0 == lblock and it fails, and if len > 0 then lblock + len > lblock in order to pass (i.e. it doesn't overflow). Fixes: 5946d0893 ("ext4: check for overlapping extents in ext4_valid_extent_entries()") Fixes: 2f974865f ("ext4: check for zero length extent explicitly") Cc: Eryu Guan Cc: stable@vger.kernel.org Signed-off-by: Phil Turnbull Signed-off-by: Vegard Nossum Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 988777b0ed921cbe607b1bf6d45434a39c07106e Author: Linus Walleij Date: Wed Jun 22 08:27:17 2016 +0200 mfd: qcom_rpm: Parametrize also ack selector size [ Upstream commit f37be01e6dc606f2fcc5e95c9933d948ce19bd35 ] The RPM has two sets of selectors (IPC bit fields): request and acknowledge. Apparently, some models use 4*32 bit words for select and some use 7*32 bit words for request, but all use 7*32 words for acknowledge bits. So apparently you can on the models with requests of 4*32 select bits send 4*32 messages and get 7*32 different replies, so on ACK interrupt, 7*32 bit words need to be read. This is how the vendor code apparently works. Cc: stable@vger.kernel.org Reported-by: Stephen Boyd Signed-off-by: Linus Walleij Reviewed-by: Bjorn Andersson Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit e6b04eb12d323bcea82654c90fbece3bf17dd2f1 Author: Linus Walleij Date: Wed Jun 15 01:02:26 2016 +0200 mfd: qcom_rpm: Fix offset error for msm8660 [ Upstream commit 9835f1b70bb3890d38308b9be4fb9d7451ba67f1 ] The RPM in MSM8660/APQ8060 has different offsets to the selector ACK and request context ACK registers. Make all these register offsets part of the per-SoC data and assign the right values. The bug was found by verifying backwards to the vendor tree in the out-of-tree files : all were using offsets 3,11,15,23 and a select size of 4, except the MSM8660/APQ8060 which was using offsets 3,11,19,27 and a select size of 7. All other platforms apart from msm8660 were affected by reading excess registers, since 7 was hardcoded as the number of select words, this patch makes also this part dynamic so we only write/read as many select words as the platform actually use. Symptoms of this bug when using msm8660: the first RPM transaction would work, but the next would stall or raise an error since the previous transaction was not properly ACKed as the ACK words were read at the wrong offset. Cc: stable@vger.kernel.org Fixes: 58e214382bdd ("mfd: qcom-rpm: Driver for the Qualcomm RPM") Signed-off-by: Linus Walleij Reviewed-by: Björn Andersson Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 6997496351500fd6fb92f11e89e5024d8bd3f55e Author: Yoshihiro Shimoda Date: Wed Jun 8 16:32:50 2016 +0900 usb: renesas_usbhs: protect the CFIFOSEL setting in usbhsg_ep_enable() [ Upstream commit 15e4292a2d21e9997fdb2b8c014cc461b3f268f0 ] This patch fixes an issue that the CFIFOSEL register value is possible to be changed by usbhsg_ep_enable() wrongly. And then, a data transfer using CFIFO may not work correctly. For example: # modprobe g_multi file=usb-storage.bin # ifconfig usb0 192.168.1.1 up (During the USB host is sending file to the mass storage) # ifconfig usb0 down In this case, since the u_ether.c may call usb_ep_enable() in eth_stop(), if the renesas_usbhs driver is also using CFIFO for mass storage, the mass storage may not work correctly. So, this patch adds usbhs_lock() and usbhs_unlock() calling in usbhsg_ep_enable() to protect CFIFOSEL register. This is because: - CFIFOSEL.CURPIPE = 0 is also needed for the pipe configuration - The CFIFOSEL (fifo->sel) is already protected by usbhs_lock() Fixes: 97664a207bc2 ("usb: renesas_usbhs: shrink spin lock area") Cc: # v3.1+ Signed-off-by: Yoshihiro Shimoda Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 83335cb773c6ee89b8517bf7c16e4c299a1c80f2 Author: Yoshihiro Shimoda Date: Wed Jun 8 16:32:49 2016 +0900 usb: renesas_usbhs: fix NULL pointer dereference in xfer_work() [ Upstream commit 4fdef698383db07d829da567e0e405fc41ff3a89 ] This patch fixes an issue that the xfer_work() is possible to cause NULL pointer dereference if the usb cable is disconnected while data transfer is running. In such case, a gadget driver may call usb_ep_disable()) before xfer_work() is actually called. In this case, the usbhs_pkt_pop() will call usbhsf_fifo_unselect(), and then usbhs_pipe_to_fifo() in xfer_work() will return NULL. Fixes: e73a989 ("usb: renesas_usbhs: add DMAEngine support") Cc: # v3.1+ Signed-off-by: Yoshihiro Shimoda Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 542330f7026d82c35314b59f52b0ec79eca2d822 Author: Alex Hung Date: Mon Jun 13 19:44:00 2016 +0800 hp-wmi: Fix wifi cannot be hard-unblocked [ Upstream commit fc8a601e1175ae351f662506030f9939cb7fdbfe ] Several users reported wifi cannot be unblocked as discussed in [1]. This patch removes the use of the 2009 flag by BIOS but uses the actual WMI function calls - it will be skipped if WMI reports unsupported. [1] https://bugzilla.kernel.org/show_bug.cgi?id=69131 Signed-off-by: Alex Hung Tested-by: Evgenii Shatokhin Cc: stable@vger.kernel.org Signed-off-by: Darren Hart Signed-off-by: Sasha Levin commit 230dc3e923b42c95a113a7bb72e8854e16256a54 Author: Krzysztof Kozlowski Date: Thu Jun 16 08:27:35 2016 +0200 serial: samsung: Fix ERR pointer dereference on deferred probe [ Upstream commit e51e4d8a185de90424b03f30181b35f29c46a25a ] When the clk_get() of "uart" clock returns EPROBE_DEFER, the next re-probe finishes with success but uses invalid (ERR_PTR) values. This leads to dereferencing of ERR_PTR stored under ourport->clk: 12c30000.serial: Controller clock not found (...) 12c30000.serial: ttySAC3 at MMIO 0x12c30000 (irq = 61, base_baud = 0) is a S3C6400/10 Unable to handle kernel paging request at virtual address fffffdfb (clk_prepare) from [] (s3c24xx_serial_pm+0x20/0x128) (s3c24xx_serial_pm) from [] (uart_change_pm+0x38/0x40) (uart_change_pm) from [] (uart_add_one_port+0x31c/0x44c) (uart_add_one_port) from [] (s3c24xx_serial_probe+0x2a8/0x418) (s3c24xx_serial_probe) from [] (platform_drv_probe+0x50/0xb0) (platform_drv_probe) from [] (driver_probe_device+0x1f4/0x2b0) (driver_probe_device) from [] (bus_for_each_drv+0x44/0x8c) (bus_for_each_drv) from [] (__device_attach+0x9c/0x100) (__device_attach) from [] (bus_probe_device+0x84/0x8c) (bus_probe_device) from [] (deferred_probe_work_func+0x60/0x8c) (deferred_probe_work_func) from [] (process_one_work+0x120/0x328) (process_one_work) from [] (worker_thread+0x2c/0x4ac) (worker_thread) from [] (kthread+0xd8/0xf4) (kthread) from [] (ret_from_fork+0x14/0x3c) The first unsuccessful clk_get() causes s3c24xx_serial_init_port() to exit with failure but the s3c24xx_uart_port is left half-configured (e.g. port->mapbase is set, clk contains ERR_PTR). On next re-probe, the function s3c24xx_serial_init_port() will exit early with success because of configured port->mapbase and driver will use old values, including the ERR_PTR as clock. Fix this by cleaning the port->mapbase on error path so each re-probe will initialize all of the port settings. Fixes: 60e93575476f ("serial: samsung: enable clock before clearing pending interrupts during init") Cc: Signed-off-by: Krzysztof Kozlowski Reviewed-by: Javier Martinez Canillas Tested-by: Javier Martinez Canillas Tested-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cf61375fb14bbd7734c42df8a03e4efae6419583 Author: Alexandre Belloni Date: Sat May 28 00:54:08 2016 +0200 tty/serial: atmel: fix RS485 half duplex with DMA [ Upstream commit 0058f0871efe7b01c6f2b3046c68196ab73e96da ] When using DMA, half duplex doesn't work properly because rx is not stopped before starting tx. Ensure we call atmel_stop_rx() in the DMA case. Signed-off-by: Alexandre Belloni Acked-by: Nicolas Ferre Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ebe139836e17beea5f6742f7c6e11a7cd9d053de Author: Cyrille Pitchen Date: Thu Jul 2 15:18:11 2015 +0200 tty/serial: at91: remove bunch of macros to access UART registers [ Upstream commit 4e7decdaaa67b287d6a13de8dedced68f1d7d716 ] This patch replaces the UART_PUT_*, resp. UART_GET_*, macros by atmel_uart_writel(), resp. atmel_uart_readl(), inline function calls. Signed-off-by: Cyrille Pitchen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 343c4efc3864c72b99669f6b214f145712202167 Author: Frank Rowand Date: Thu Jun 16 10:51:46 2016 -0700 of: fix memory leak related to safe_name() [ Upstream commit d9fc880723321dbf16b2981e3f3e916b73942210 ] Fix a memory leak resulting from memory allocation in safe_name(). This patch fixes all call sites of safe_name(). Mathieu Malaterre reported the memory leak on boot: On my PowerMac device-tree would generate a duplicate name: [ 0.023043] device-tree: Duplicate name in PowerPC,G4@0, renamed to "l2-cache#1" in this case a newly allocated name is generated by `safe_name`. However in this case it is never deallocated. The bug was found using kmemleak reported as: unreferenced object 0xdf532e60 (size 32): comm "swapper", pid 1, jiffies 4294892300 (age 1993.532s) hex dump (first 32 bytes): 6c 32 2d 63 61 63 68 65 23 31 00 dd e4 dd 1e c2 l2-cache#1...... ec d4 ba ce 04 ec cc de 8e 85 e9 ca c4 ec cc 9e ................ backtrace: [] kvasprintf+0x64/0xc8 [] kasprintf+0x4c/0x5c [] safe_name.isra.1+0x80/0xc4 [] __of_attach_node_sysfs+0x6c/0x11c [] of_core_init+0x8c/0xf8 [] kernel_init_freeable+0xd4/0x208 [] kernel_init+0x24/0x11c [] ret_from_kernel_thread+0x5c/0x64 Link: https://bugzilla.kernel.org/show_bug.cgi?id=120331 Signed-off-by: Frank Rowand Reported-by: mathieu.malaterre@gmail.com Tested-by: Mathieu Malaterre Cc: stable@vger.kernel.org Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit 843137840f140051965e0611fa95c831b5064737 Author: Herbert Xu Date: Wed Jun 15 22:27:05 2016 +0800 crypto: gcm - Filter out async ghash if necessary [ Upstream commit b30bdfa86431afbafe15284a3ad5ac19b49b88e3 ] As it is if you ask for a sync gcm you may actually end up with an async one because it does not filter out async implementations of ghash. This patch fixes this by adding the necessary filter when looking for ghash. Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit b42d3789eeabb4bdbe295645abc82d11b04db184 Author: Konrad Leszczynski Date: Mon Feb 8 16:13:12 2016 +0100 usb: dwc3: fix for the isoc transfer EP_BUSY flag [ Upstream commit 9cad39fe4e4a4fe95d8ea5a7b0692b0a6e89e38b ] commit f3af36511e60 ("usb: dwc3: gadget: always enable IOC on bulk/interrupt transfers") ended up regressing Isochronous endpoints by clearing DWC3_EP_BUSY flag too early, which resulted in choppy audio playback over USB. Fix that by partially reverting original commit and making sure that we check for isochronous endpoints. Fixes: f3af36511e60 ("usb: dwc3: gadget: always enable IOC on bulk/interrupt transfers") Cc: Signed-off-by: Konrad Leszczynski Signed-off-by: Rafal Redzimski Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 4426cc65a19c0009761e03d44828da0508ccbcac Author: Dan O'Donovan Date: Fri Jun 10 13:23:34 2016 +0100 pinctrl: cherryview: prevent concurrent access to GPIO controllers [ Upstream commit 0bd50d719b004110e791800450ad204399100a86 ] Due to a silicon issue on the Atom X5-Z8000 "Cherry Trail" processor series, a common lock must be used to prevent concurrent accesses across the 4 GPIO controllers managed by this driver. See Intel Atom Z8000 Processor Series Specification Update (Rev. 005), errata #CHT34, for further information. Cc: stable Signed-off-by: Dan O'Donovan Acked-by: Mika Westerberg Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 40357fd7f29e7449b6bde0ec3f9cfc1f25b51123 Author: Mika Westerberg Date: Mon Aug 17 16:13:30 2015 +0300 pinctrl: cherryview: Use raw_spinlock for locking [ Upstream commit 109fdf1572be86aaf681e69b30dc5ada90ce6f35 ] When running -rt kernel and an interrupt happens on a GPIO line controlled by Intel Cherryview/Braswell pinctrl driver we get: BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917 in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/0 Preemption disabled at:[] cpu_startup_entry+0x17f/0x480 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.5-rt5 #16 ... Call Trace: [] dump_stack+0x4a/0x61 [] ___might_sleep+0xe7/0x170 [] rt_spin_lock+0x1f/0x50 [] chv_gpio_irq_ack+0x3d/0xa0 [] handle_edge_irq+0x75/0x180 [] generic_handle_irq+0x27/0x40 [] chv_gpio_irq_handler+0x7e/0x110 [] handle_irq+0xaa/0x190 ... This is because desc->lock is raw_spinlock and is held when chv_gpio_irq_ack() is called by the genirq core. chv_gpio_irq_ack() in turn takes pctrl->lock which in -rt is an rt-mutex causing might_sleep() rightfully to complain about sleeping function called from invalid context. In order to keep -rt happy but at the same time make sure that register accesses get serialized, convert the driver to use raw_spinlock instead. Suggested-by: Linus Walleij Signed-off-by: Mika Westerberg Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit ba42156d9552903782ab2723e5dbf3fe7275ddc7 Author: Mika Westerberg Date: Mon Aug 3 12:46:38 2015 +0300 pinctrl: cherryview: Serialize all register access [ Upstream commit 4585b000ace6438d0b142746baab658056b223d9 ] There is a hardware issue in Intel Braswell/Cherryview where concurrent GPIO register access might results reads of 0xffffffff and writes might get dropped. Prevent this from happening by taking the serializing lock for all places where it is possible that more than one thread might be accessing the hardware concurrently. Signed-off-by: Mika Westerberg Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit e05777384e99ed3baef9459027e5318ed20f41f3 Author: Mauro Carvalho Chehab Date: Tue Jun 14 14:48:50 2016 -0300 Update my main e-mails at the Kernel tree [ Upstream commit dc19ed1571dd3882b35e12fdaf50acbcc9b69714 ] For the third time in three years, I'm changing my e-mail at Samsung. That's bad, as it may stop communications with me for a while. So, this time, I'll also the mchehab@kernel.org e-mail, as it remains stable since ever. Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 10dd8c104728611c5f58d7b19df323756d565443 Author: Vignesh R Date: Thu Jun 9 11:02:04 2016 +0530 gpio: pca953x: Fix NBANK calculation for PCA9536 [ Upstream commit a246b8198f776a16d1d3a3bbfc2d437bad766b29 ] NBANK() macro assumes that ngpios is a multiple of 8(BANK_SZ) and hence results in 0 banks for PCA9536 which has just 4 gpios. This is wrong as PCA9356 has 1 bank with 4 gpios. This results in uninitialized PCA953X_INVERT register. Fix this by using DIV_ROUND_UP macro in NBANK(). Cc: stable@vger.kernel.org Signed-off-by: Vignesh R Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 27b549050db577d3bef3eb3409237563a115f9dd Author: Chris Blake Date: Mon May 30 07:26:37 2016 -0500 PCI: Mark Atheros AR9485 and QCA9882 to avoid bus reset [ Upstream commit 9ac0108c2bac3f1d0255f64fb89fc27e71131b24 ] Similar to the AR93xx series, the AR94xx and the Qualcomm QCA988x also have the same quirk for the Bus Reset. Fixes: c3e59ee4e766 ("PCI: Mark Atheros AR93xx to avoid bus reset") Signed-off-by: Chris Blake Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org # v3.14+ Signed-off-by: Sasha Levin commit b3780073dea394fee44f14e36883528893ad6f7a Author: Daniel Vetter Date: Thu Jun 9 18:39:07 2016 +0200 Revert "drm/i915/ilk: Don't disable SSC source if it's in use" [ Upstream commit 8c07eb68330f3ed9a735023a0f0e7f4e873e0c63 ] This reverts commit f165d2834ceb3d5c29bebadadc27629bebf402ac. It breaks one of our CI systems. Quoting from Ville: [ 13.100979] [drm:ironlake_init_pch_refclk] has_panel 1 has_lvds 1 has_ck505 0 using_ssc_source 1 [ 13.101413] ------------[ cut here ]------------ [ 13.101429] kernel BUG at drivers/gpu/drm/i915/intel_display.c:8528! "which is the 'BUG_ON(val != final)' at the end of ironlake_init_pch_refclk()." Cc: stable@vger.kernel.org Cc: Ville Syrjälä Cc: Lyude Cc: marius.c.vlad@intel.com References: https://www.spinics.net/lists/dri-devel/msg109557.html Acked-by: Lyude Signed-off-by: Daniel Vetter Signed-off-by: Sasha Levin commit 7a85bf9e31a6449cc2a93fd8505a7523597ff266 Author: Paul Moore Date: Mon Jun 6 15:17:20 2016 -0400 netlabel: add address family checks to netlbl_{sock,req}_delattr() [ Upstream commit 0e0e36774081534783aa8eeb9f6fbddf98d3c061 ] It seems risky to always rely on the caller to ensure the socket's address family is correct before passing it to the NetLabel kAPI, especially since we see at least one LSM which didn't. Add address family checks to the *_delattr() functions to help prevent future problems. Cc: Reported-by: Maninder Singh Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit 85470a568a4ceed060d9539c70e29b0707e78feb Author: Javier Martinez Canillas Date: Tue May 3 16:27:17 2016 -0400 s5p-mfc: Add release callback for memory region devs [ Upstream commit 6311f1261f59ce5e51fbe5cc3b5e7737197316ac ] When s5p_mfc_remove() calls put_device() for the reserved memory region devs, the driver core warns that the dev doesn't have a release callback: WARNING: CPU: 0 PID: 591 at drivers/base/core.c:251 device_release+0x8c/0x90 Device 's5p-mfc-l' does not have a release() function, it is broken and must be fixed. Also, the declared DMA memory using dma_declare_coherent_memory() isn't relased so add a dev .release that calls dma_release_declared_memory(). Cc: Fixes: 6e83e6e25eb4 ("[media] s5p-mfc: Fix kernel warning on memory init") Signed-off-by: Javier Martinez Canillas Tested-by: Marek Szyprowski Signed-off-by: Sylwester Nawrocki Signed-off-by: Sasha Levin commit 1dd12c31c91bf3d505a8496f62805b042cb5fa83 Author: Javier Martinez Canillas Date: Tue May 3 16:27:16 2016 -0400 s5p-mfc: Set device name for reserved memory region devs [ Upstream commit 29debab0a94035a390801d1f177d171d014b7765 ] The devices don't have a name set, so makes dev_name() returns NULL which makes harder to identify the devices that are causing issues, for example: WARNING: CPU: 2 PID: 616 at drivers/base/core.c:251 device_release+0x8c/0x90 Device '(null)' does not have a release() function, it is broken and must be fixed. And after setting the device name: WARNING: CPU: 0 PID: 591 at drivers/base/core.c:251 device_release+0x8c/0x90 Device 's5p-mfc-l' does not have a release() function, it is broken and must be fixed. Cc: Fixes: 6e83e6e25eb4 ("[media] s5p-mfc: Fix kernel warning on memory init") Signed-off-by: Javier Martinez Canillas Tested-by: Marek Szyprowski Signed-off-by: Sylwester Nawrocki Signed-off-by: Sasha Levin commit fce671617558b1dceb3471fbf2c3d3f00ef83664 Author: Roderick Colenbrander Date: Wed May 18 13:11:09 2016 -0700 HID: uhid: fix timeout when probe races with IO [ Upstream commit 67f8ecc550b5bda03335f845dc869b8501d25fd0 ] Many devices use userspace bluetooth stacks like BlueZ or Bluedroid in combination with uhid. If any of these stacks is used with a HID device for which the driver performs a HID request as part .probe (or technically another HID operation), this results in a deadlock situation. The deadlock results in a 5 second timeout for I/O operations in HID drivers, so isn't fatal, but none of the I/O operations have a chance of succeeding. The root cause for the problem is that uhid only allows for one request to be processed at a time per uhid instance and locks out other operations. This means that if a user space is creating a new HID device through 'UHID_CREATE', which ultimately triggers '.probe' through the HID layer. Then any HID request e.g. a read for calibration data would trigger a HID operation on uhid again, but it won't go out to userspace, because it is still stuck in UHID_CREATE. In addition bluetooth stacks are typically single threaded, so they wouldn't be able to handle any requests while waiting on uhid. Lucikly the UHID spec is somewhat flexible and allows for fixing the issue, without breaking user space. The idea which the patch implements as discussed with David Herrmann is to decouple adding of a hid device (which triggers .probe) from UHID_CREATE. The work will kick off roughly once UHID_CREATE completed (or else will wait a tiny bit of time in .probe for a lock). A HID driver has to call HID to call 'hid_hw_start()' as part of .probe once it is ready for I/O, which triggers UHID_START to user space. Any HID operations should function now within .probe and won't deadlock because userspace is stuck on UHID_CREATE. We verified this patch on Bluedroid with Android 6.0 and on desktop Linux with BlueZ stacks. Prior to the patch they had the deadlock issue. [jkosina@suse.cz: reword subject] Signed-off-by: Roderick Colenbrander Cc: stable@vger.kernel.org Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 223b3917e224a83cf174ed3458804c9c35b5013e Author: James Morse Date: Fri Aug 12 14:11:19 2016 -0400 arm64: kernel: Save and restore addr_limit on exception entry commit e19a6ee2460bdd0d0055a6029383422773f9999a upstream. If we take an exception while at EL1, the exception handler inherits the original context's addr_limit value. To be consistent always reset addr_limit and PSTATE.UAO on (re-)entry to EL1. This prevents accidental re-use of the original context's addr_limit. Based on a similar patch for arm from Russell King. Acked-by: Will Deacon Reviewed-by: Mark Rutland Signed-off-by: James Morse Signed-off-by: Will Deacon [ backport to stop perf misusing inherited addr_limit. Removed code interacting with UAO and the irqstack ] Link: https://bugs.chromium.org/p/project-zero/issues/detail?id=822 Signed-off-by: James Morse Cc: #4.1 Signed-off-by: Sasha Levin commit 5c576457aca8fc07bdb800a4589357801133f81b Author: Kenny Keslar Date: Fri Aug 12 13:27:29 2016 -0400 fs/proc/task_mmu.c: fix mm_access() mode parameter in pagemap_read() Backport of caaee6234d05a58c5b4d05e7bf766131b810a657 ("ptrace: use fsuid, fsgid, effective creds for fs access checks") to v4.1 failed to update the mode parameter in the mm_access() call in pagemap_read() to have one of the new PTRACE_MODE_*CREDS flags. Attempting to read any other process' pagemap results in a WARN() WARNING: CPU: 0 PID: 883 at kernel/ptrace.c:229 __ptrace_may_access+0x14a/0x160() denying ptrace access check without PTRACE_MODE_*CREDS Modules linked in: loop sg e1000 i2c_piix4 ppdev virtio_balloon virtio_pci parport_pc i2c_core virtio_ring ata_generic serio_raw pata_acpi virtio parport pcspkr floppy acpi_cpufreq ip_tables ext3 mbcache jbd sd_mod ata_piix crc32c_intel libata CPU: 0 PID: 883 Comm: cat Tainted: G W 4.1.12-51.el7uek.x86_64 #2 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 0000000000000286 00000000619f225a ffff88003b6fbc18 ffffffff81717021 ffff88003b6fbc70 ffffffff819be870 ffff88003b6fbc58 ffffffff8108477a 000000003b6fbc58 0000000000000001 ffff88003d287000 0000000000000001 Call Trace: [] dump_stack+0x63/0x81 [] warn_slowpath_common+0x8a/0xc0 [] warn_slowpath_fmt+0x55/0x70 [] __ptrace_may_access+0x14a/0x160 [] ptrace_may_access+0x32/0x50 [] mm_access+0x6d/0xb0 [] pagemap_read+0xe1/0x360 [] ? lru_cache_add_active_or_unevictable+0x2b/0xa0 [] __vfs_read+0x37/0x100 [] ? security_file_permission+0x84/0xa0 [] ? rw_verify_area+0x56/0xe0 [] vfs_read+0x86/0x140 [] SyS_read+0x55/0xd0 [] system_call_fastpath+0x12/0x71 Fixes: ab88ce5feca4 (ptrace: use fsuid, fsgid, effective creds for fs access checks) Signed-off-by: Kenny Keslar Cc: Roland McGrath Cc: Oleg Nesterov Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 6a468737c8c00bd6cdb208ca0b7f841e8970d466 Author: Munehisa Kamata Date: Mon Oct 26 19:10:52 2015 -0700 netfilter: nf_nat_redirect: add missing NULL pointer check [ Upstream commit 94f9cd81436c85d8c3a318ba92e236ede73752fc ] Commit 8b13eddfdf04cbfa561725cfc42d6868fe896f56 ("netfilter: refactor NAT redirect IPv4 to use it from nf_tables") has introduced a trivial logic change which can result in the following crash. BUG: unable to handle kernel NULL pointer dereference at 0000000000000030 IP: [] nf_nat_redirect_ipv4+0x2d/0xa0 [nf_nat_redirect] PGD 3ba662067 PUD 3ba661067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: ipv6(E) xt_REDIRECT(E) nf_nat_redirect(E) xt_tcpudp(E) iptable_nat(E) nf_conntrack_ipv4(E) nf_defrag_ipv4(E) nf_nat_ipv4(E) nf_nat(E) nf_conntrack(E) ip_tables(E) x_tables(E) binfmt_misc(E) xfs(E) libcrc32c(E) evbug(E) evdev(E) psmouse(E) i2c_piix4(E) i2c_core(E) acpi_cpufreq(E) button(E) ext4(E) crc16(E) jbd2(E) mbcache(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E) CPU: 0 PID: 2536 Comm: ip Tainted: G E 4.1.7-15.23.amzn1.x86_64 #1 Hardware name: Xen HVM domU, BIOS 4.2.amazon 05/06/2015 task: ffff8800eb438000 ti: ffff8803ba664000 task.ti: ffff8803ba664000 [...] Call Trace: [] redirect_tg4+0x15/0x20 [xt_REDIRECT] [] ipt_do_table+0x2b9/0x5e1 [ip_tables] [] iptable_nat_do_chain+0x25/0x30 [iptable_nat] [] nf_nat_ipv4_fn+0x13d/0x1f0 [nf_nat_ipv4] [] ? iptable_nat_ipv4_fn+0x20/0x20 [iptable_nat] [] nf_nat_ipv4_in+0x2e/0x90 [nf_nat_ipv4] [] iptable_nat_ipv4_in+0x15/0x20 [iptable_nat] [] nf_iterate+0x57/0x80 [] nf_hook_slow+0x97/0x100 [] ip_rcv+0x314/0x400 unsigned int nf_nat_redirect_ipv4(struct sk_buff *skb, ... { ... rcu_read_lock(); indev = __in_dev_get_rcu(skb->dev); if (indev != NULL) { ifa = indev->ifa_list; newdst = ifa->ifa_local; <--- } rcu_read_unlock(); ... } Before the commit, 'ifa' had been always checked before access. After the commit, however, it could be accessed even if it's NULL. Interestingly, this was once fixed in 2003. http://marc.info/?l=netfilter-devel&m=106668497403047&w=2 In addition to the original one, we have seen the crash when packets that need to be redirected somehow arrive on an interface which hasn't been yet fully configured. This change just reverts the logic to the old behavior to avoid the crash. Fixes: 8b13eddfdf04 ("netfilter: refactor NAT redirect IPv4 to use it from nf_tables") Signed-off-by: Munehisa Kamata Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin