commit d420f00c7bfb405884dd71fb7f87974f0d1be455 Author: Sasha Levin Date: Thu Jun 23 00:02:29 2016 -0400 Linux 3.18.36 Signed-off-by: Sasha Levin commit dd536b607688315b3043ab5fd5243c3f530922a2 Author: Jann Horn Date: Wed Jun 1 11:55:06 2016 +0200 ecryptfs: forbid opening files without mmap handler [ Upstream commit 2f36db71009304b3f0b95afacd8eba1f9f046b87 ] This prevents users from triggering a stack overflow through a recursive invocation of pagefault handling that involves mapping procfs files into virtual memory. Signed-off-by: Jann Horn Acked-by: Tyler Hicks Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 70e21269e3ec8e4345e7fcd263f9a8f2a43f42df Author: Jann Horn Date: Wed Jun 1 11:55:05 2016 +0200 proc: prevent stacking filesystems on top [ Upstream commit e54ad7f1ee263ffa5a2de9c609d58dfa27b21cd9 ] This prevents stacking filesystems (ecryptfs and overlayfs) from using procfs as lower filesystem. There is too much magic going on inside procfs, and there is no good reason to stack stuff on top of procfs. (For example, procfs does access checks in VFS open handlers, and ecryptfs by design calls open handlers from a kernel thread that doesn't drop privileges or so.) Signed-off-by: Jann Horn Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 8cb589e0d094c522e1103563c17881c31d5e9a69 Author: Prasun Maiti Date: Mon Jun 6 20:04:19 2016 +0530 wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel [ Upstream commit 3d5fdff46c4b2b9534fa2f9fc78e90a48e0ff724 ] iwpriv app uses iw_point structure to send data to Kernel. The iw_point structure holds a pointer. For compatibility Kernel converts the pointer as required for WEXT IOCTLs (SIOCIWFIRST to SIOCIWLAST). Some drivers may use iw_handler_def.private_args to populate iwpriv commands instead of iw_handler_def.private. For those case, the IOCTLs from SIOCIWFIRSTPRIV to SIOCIWLASTPRIV will follow the path ndo_do_ioctl(). Accordingly when the filled up iw_point structure comes from 32 bit iwpriv to 64 bit Kernel, Kernel will not convert the pointer and sends it to driver. So, the driver may get the invalid data. The pointer conversion for the IOCTLs (SIOCIWFIRSTPRIV to SIOCIWLASTPRIV), which follow the path ndo_do_ioctl(), is mandatory. This patch adds pointer conversion from 32 bit to 64 bit and vice versa, if the ioctl comes from 32 bit iwpriv to 64 bit Kernel. Cc: stable@vger.kernel.org Signed-off-by: Prasun Maiti Signed-off-by: Ujjal Roy Tested-by: Dibyajyoti Ghosh Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 1f9737df6d4e31106df4dd929cb3f936d2ce955d Author: Ben Dooks Date: Tue Jun 7 17:22:17 2016 +0100 gpio: bcm-kona: fix bcm_kona_gpio_reset() warnings [ Upstream commit b66b2a0adf0e48973b582e055758b9907a7eee7c ] The bcm_kona_gpio_reset() calls bcm_kona_gpio_write_lock_regs() with what looks like the wrong parameter. The write_lock_regs function takes a pointer to the registers, not the bcm_kona_gpio structure. Fix the warning, and probably bug by changing the function to pass reg_base instead of kona_gpio, fixing the following warning: drivers/gpio/gpio-bcm-kona.c:550:47: warning: incorrect type in argument 1 (different address spaces) expected void [noderef] *reg_base got struct bcm_kona_gpio *kona_gpio warning: incorrect type in argument 1 (different address spaces) expected void [noderef] *reg_base got struct bcm_kona_gpio *kona_gpio Cc: stable@vger.kernel.org Signed-off-by: Ben Dooks Acked-by: Ray Jui Reviewed-by: Markus Mayer Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 869ffbd57257ffbc14bc21618b29dc16d4e7952d Author: Ricardo Ribalda Delgado Date: Fri Jun 3 19:10:01 2016 +0200 gpiolib: Fix NULL pointer deference [ Upstream commit 11f33a6d15bfa397867ac0d7f3481b6dd683286f ] Under some circumstances, a gpiochip might be half cleaned from the gpio_device list. This patch makes sure that the chip pointer is still valid, before calling the match function. [ 104.088296] BUG: unable to handle kernel NULL pointer dereference at 0000000000000090 [ 104.089772] IP: [] of_gpiochip_find_and_xlate+0x15/0x80 [ 104.128273] Call Trace: [ 104.129802] [] ? of_parse_own_gpio+0x1f0/0x1f0 [ 104.131353] [] gpiochip_find+0x60/0x90 [ 104.132868] [] of_get_named_gpiod_flags+0x9a/0x120 ... [ 104.141586] [] gpio_led_probe+0x11b/0x360 Cc: stable@vger.kernel.org Signed-off-by: Ricardo Ribalda Delgado Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 34558d3f213b5d95253aba97b529d46f20b757cb Author: Al Viro Date: Tue Jun 7 21:26:55 2016 -0400 fix d_walk()/non-delayed __d_free() race [ Upstream commit 3d56c25e3bb0726a5c5e16fc2d9e38f8ed763085 ] Ascend-to-parent logics in d_walk() depends on all encountered child dentries not getting freed without an RCU delay. Unfortunately, in quite a few cases it is not true, with hard-to-hit oopsable race as the result. Fortunately, the fix is simiple; right now the rule is "if it ever been hashed, freeing must be delayed" and changing it to "if it ever had a parent, freeing must be delayed" closes that hole and covers all cases the old rule used to cover. Moreover, pipes and sockets remain _not_ covered, so we do not introduce RCU delay in the cases which are the reason for having that delay conditional in the first place. Cc: stable@vger.kernel.org # v3.2+ (and watch out for __d_materialise_dentry()) Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit d05438b3ba85517631b5ea2e1c88172f84dffe8b Author: Srinivas Pandruvada Date: Tue Jun 7 17:38:53 2016 -0700 cpufreq: intel_pstate: Fix ->set_policy() interface for no_turbo [ Upstream commit 983e600e88835f0321d1a0ea06f52d48b7b5a544 ] When turbo is disabled, the ->set_policy() interface is broken. For example, when turbo is disabled and cpuinfo.max = 2900000 (full max turbo frequency), setting the limits results in frequency less than the requested one: Set 1000000 KHz results in 0700000 KHz Set 1500000 KHz results in 1100000 KHz Set 2000000 KHz results in 1500000 KHz This is because the limits->max_perf fraction is calculated using the max turbo frequency as the reference, but when the max P-State is capped in intel_pstate_get_min_max(), the reference is not the max turbo P-State. This results in reducing max P-State. One option is to always use max turbo as reference for calculating limits. But this will not be correct. By definition the intel_pstate sysfs limits, shows percentage of available performance. So when BIOS has disabled turbo, the available performance is max non turbo. So the max_perf_pct should still show 100%. Signed-off-by: Srinivas Pandruvada [ rjw : Subject & changelog, rewrite in fewer lines of code ] Cc: All applicable Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 69bc46495e9c64bbf49ed7460c536add7b714d88 Author: Sasha Levin Date: Fri Jun 17 17:30:50 2016 -0400 of: fix autoloading due to broken modalias with no 'compatible' [ Upstream commit b3c0a4dab7e35a9b6d69c0415641d2280fdefb2b ] Because of an improper dereference, a stray 'C' character was output to the modalias when no 'compatible' was specified. This is the case for some old PowerMac drivers which only set the 'name' property. Fix it to let them match again. Reported-by: Mathieu Malaterre Signed-off-by: Wolfram Sang Tested-by: Mathieu Malaterre Cc: Philipp Zabel Cc: Andreas Schwab Fixes: 6543becf26fff6 ("mod/file2alias: make modalias generation safe for cross compiling") Cc: stable@vger.kernel.org # v3.9+ Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 2c34097fbfbcfdafca183139cc3524c4e29e27eb Author: H. Peter Anvin Date: Tue Apr 5 17:01:33 2016 -0700 x86, build: copy ldlinux.c32 to image.iso [ Upstream commit 9c77679cadb118c0aa99e6f88533d91765a131ba ] For newer versions of Syslinux, we need ldlinux.c32 in addition to isolinux.bin to reside on the boot disk, so if the latter is found, copy it, too, to the isoimage tree. Signed-off-by: H. Peter Anvin Cc: Linux Stable Tree Signed-off-by: Sasha Levin commit 68924d2d32edadfbf9c2819ff3635248a192a90a Author: Eric W. Biederman Date: Fri May 27 14:50:05 2016 -0500 mnt: fs_fully_visible test the proper mount for MNT_LOCKED [ Upstream commit d71ed6c930ac7d8f88f3cef6624a7e826392d61f ] MNT_LOCKED implies on a child mount implies the child is locked to the parent. So while looping through the children the children should be tested (not their parent). Typically an unshare of a mount namespace locks all mounts together making both the parent and the slave as locked but there are a few corner cases where other things work. Cc: stable@vger.kernel.org Fixes: ceeb0e5d39fc ("vfs: Ignore unlocked mounts in fs_fully_visible") Reported-by: Seth Forshee Signed-off-by: "Eric W. Biederman" Signed-off-by: Sasha Levin commit 7fca87231b6a08e5fe86b02b191527a673f50e71 Author: Eric W. Biederman Date: Mon Jun 6 15:36:07 2016 -0500 mnt: If fs_fully_visible fails call put_filesystem. [ Upstream commit 97c1df3e54e811aed484a036a798b4b25d002ecf ] Add this trivial missing error handling. Cc: stable@vger.kernel.org Fixes: 1b852bceb0d1 ("mnt: Refactor the logic for mounting sysfs and proc in a user namespace") Signed-off-by: "Eric W. Biederman" Signed-off-by: Sasha Levin commit ec5ef4f89be8c7b14deb23a684b6adc3e4c3c220 Author: Helge Deller Date: Sat Jun 4 17:21:33 2016 +0200 parisc: Fix pagefault crash in unaligned __get_user() call [ Upstream commit 8b78f260887df532da529f225c49195d18fef36b ] One of the debian buildd servers had this crash in the syslog without any other information: Unaligned handler failed, ret = -2 clock_adjtime (pid 22578): Unaligned data reference (code 28) CPU: 1 PID: 22578 Comm: clock_adjtime Tainted: G E 4.5.0-2-parisc64-smp #1 Debian 4.5.4-1 task: 000000007d9960f8 ti: 00000001bde7c000 task.ti: 00000001bde7c000 YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 00001000000001001111100000001111 Tainted: G E r00-03 000000ff0804f80f 00000001bde7c2b0 00000000402d2be8 00000001bde7c2b0 r04-07 00000000409e1fd0 00000000fa6f7fff 00000001bde7c148 00000000fa6f7fff r08-11 0000000000000000 00000000ffffffff 00000000fac9bb7b 000000000002b4d4 r12-15 000000000015241c 000000000015242c 000000000000002d 00000000fac9bb7b r16-19 0000000000028800 0000000000000001 0000000000000070 00000001bde7c218 r20-23 0000000000000000 00000001bde7c210 0000000000000002 0000000000000000 r24-27 0000000000000000 0000000000000000 00000001bde7c148 00000000409e1fd0 r28-31 0000000000000001 00000001bde7c320 00000001bde7c350 00000001bde7c218 sr00-03 0000000001200000 0000000001200000 0000000000000000 0000000001200000 sr04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000402d2e84 00000000402d2e88 IIR: 0ca0d089 ISR: 0000000001200000 IOR: 00000000fa6f7fff CPU: 1 CR30: 00000001bde7c000 CR31: ffffffffffffffff ORIG_R28: 00000002369fe628 IAOQ[0]: compat_get_timex+0x2dc/0x3c0 IAOQ[1]: compat_get_timex+0x2e0/0x3c0 RP(r2): compat_get_timex+0x40/0x3c0 Backtrace: [<00000000402d4608>] compat_SyS_clock_adjtime+0x40/0xc0 [<0000000040205024>] syscall_exit+0x0/0x14 This means the userspace program clock_adjtime called the clock_adjtime() syscall and then crashed inside the compat_get_timex() function. Syscalls should never crash programs, but instead return EFAULT. The IIR register contains the executed instruction, which disassebles into "ldw 0(sr3,r5),r9". This load-word instruction is part of __get_user() which tried to read the word at %r5/IOR (0xfa6f7fff). This means the unaligned handler jumped in. The unaligned handler is able to emulate all ldw instructions, but it fails if it fails to read the source e.g. because of page fault. The following program reproduces the problem: #define _GNU_SOURCE #include #include #include int main(void) { /* allocate 8k */ char *ptr = mmap(NULL, 2*4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); /* free second half (upper 4k) and make it invalid. */ munmap(ptr+4096, 4096); /* syscall where first int is unaligned and clobbers into invalid memory region */ /* syscall should return EFAULT */ return syscall(__NR_clock_adjtime, 0, ptr+4095); } To fix this issue we simply need to check if the faulting instruction address is in the exception fixup table when the unaligned handler failed. If it is, call the fixup routine instead of crashing. While looking at the unaligned handler I found another issue as well: The target register should not be modified if the handler was unsuccessful. Signed-off-by: Helge Deller Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 014694d9879ab5a571f72477fb84cffee9deb968 Author: Sergei Shtylyov Date: Sat May 28 23:02:50 2016 +0300 of: irq: fix of_irq_get[_byname]() kernel-doc [ Upstream commit 3993546646baf1dab5f5c4f7d9bb58f2046fd1c1 ] The kernel-doc for the of_irq_get[_byname]() is clearly inadequate in describing the return values -- of_irq_get_byname() is documented better than of_irq_get() but it still doesn't mention that 0 is returned iff irq_create_of_mapping() fails (it doesn't return an error code in this case). Document all possible return value variants, making the writing of the word "IRQ" consistent, while at it... Fixes: 9ec36cafe43b ("of/irq: do irq resolution in platform_get_irq") Fixes: ad69674e73a1 ("of/irq: do irq resolution in platform_get_irq_byname()") Signed-off-by: Sergei Shtylyov CC: stable@vger.kernel.org Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit 1155365dd825753302246654dc988c1a31462b04 Author: AceLan Kao Date: Fri Jun 3 14:45:25 2016 +0800 ALSA: hda - Fix headset mic detection problem for Dell machine [ Upstream commit f90d83b301701026b2e4c437a3613f377f63290e ] Add the pin configuration value of this machine into the pin_quirk table to make DELL1_MIC_NO_PRESENCE apply to this machine. Signed-off-by: AceLan Kao Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 33fae4cc30d0451479f620af8846c5d717f08b7b Author: Chris Wilson Date: Thu May 26 21:08:17 2016 +0100 locking/ww_mutex: Report recursive ww_mutex locking early [ Upstream commit 0422e83d84ae24b933e4b0d4c1e0f0b4ae8a0a3b ] Recursive locking for ww_mutexes was originally conceived as an exception. However, it is heavily used by the DRM atomic modesetting code. Currently, the recursive deadlock is checked after we have queued up for a busy-spin and as we never release the lock, we spin until kicked, whereupon the deadlock is discovered and reported. A simple solution for the now common problem is to move the recursive deadlock discovery to the first action when taking the ww_mutex. Suggested-by: Maarten Lankhorst Signed-off-by: Chris Wilson Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Maarten Lankhorst Cc: Andrew Morton Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/1464293297-19777-1-git-send-email-chris@chris-wilson.co.uk Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit d822ea89aa219e61c91afbe4136e42502d08f85b Author: Marc Zyngier Date: Thu Jun 2 09:00:28 2016 +0100 irqchip/gic-v3: Fix ICC_SGI1R_EL1.INTID decoding mask [ Upstream commit dd5f1b049dc139876801db3cdd0f20d21fd428cc ] The INTID mask is wrong, and is made a signed value, which has nteresting effects in the KVM emulation. Let's sanitize it. Cc: stable@vger.kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 045f08909af86b12a5030c5ce34bb15f9a201bed Author: Andre Przywara Date: Wed Nov 12 13:46:06 2014 +0000 arm64: GICv3: introduce symbolic names for GICv3 ICC_SGI1R_EL1 fields [ Upstream commit 7e5802781c3e109558ddfd8b02155ad24d872ee7 ] The gic_send_sgi() function used hardcoded bit shift values to generate the ICC_SGI1R_EL1 register value. Replace this with symbolic names to allow reusing them later. Signed-off-by: Andre Przywara Reviewed-by: Christoffer Dall Signed-off-by: Christoffer Dall Signed-off-by: Sasha Levin commit 26c6a77797c961c345b3d9c2be96f2cbde6276a1 Author: Paolo Bonzini Date: Wed Jun 1 14:09:23 2016 +0200 KVM: x86: fix OOPS after invalid KVM_SET_DEBUGREGS [ Upstream commit d14bdb553f9196169f003058ae1cdabe514470e6 ] MOV to DR6 or DR7 causes a #GP if an attempt is made to write a 1 to any of bits 63:32. However, this is not detected at KVM_SET_DEBUGREGS time, and the next KVM_RUN oopses: general protection fault: 0000 [#1] SMP CPU: 2 PID: 14987 Comm: a.out Not tainted 4.4.9-300.fc23.x86_64 #1 Hardware name: LENOVO 2325F51/2325F51, BIOS G2ET32WW (1.12 ) 05/30/2012 [...] Call Trace: [] kvm_arch_vcpu_ioctl_run+0x141d/0x14e0 [kvm] [] kvm_vcpu_ioctl+0x33d/0x620 [kvm] [] do_vfs_ioctl+0x298/0x480 [] SyS_ioctl+0x79/0x90 [] entry_SYSCALL_64_fastpath+0x12/0x71 Code: 55 83 ff 07 48 89 e5 77 27 89 ff ff 24 fd 90 87 80 81 0f 23 fe 5d c3 0f 23 c6 5d c3 0f 23 ce 5d c3 0f 23 d6 5d c3 0f 23 de 5d c3 <0f> 23 f6 5d c3 0f 0b 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 RIP [] native_set_debugreg+0x2b/0x40 RSP Testcase (beautified/reduced from syzkaller output): #include #include #include #include #include #include #include long r[8]; int main() { struct kvm_debugregs dr = { 0 }; r[2] = open("/dev/kvm", O_RDONLY); r[3] = ioctl(r[2], KVM_CREATE_VM, 0); r[4] = ioctl(r[3], KVM_CREATE_VCPU, 7); memcpy(&dr, "\x5d\x6a\x6b\xe8\x57\x3b\x4b\x7e\xcf\x0d\xa1\x72" "\xa3\x4a\x29\x0c\xfc\x6d\x44\x00\xa7\x52\xc7\xd8" "\x00\xdb\x89\x9d\x78\xb5\x54\x6b\x6b\x13\x1c\xe9" "\x5e\xd3\x0e\x40\x6f\xb4\x66\xf7\x5b\xe3\x36\xcb", 48); r[7] = ioctl(r[4], KVM_SET_DEBUGREGS, &dr); r[6] = ioctl(r[4], KVM_RUN, 0); } Reported-by: Dmitry Vyukov Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Radim Krčmář Signed-off-by: Sasha Levin commit 9a579331430c2cebb99488f664a736654988532d Author: Paolo Bonzini Date: Wed Jun 1 14:09:21 2016 +0200 KVM: irqfd: fix NULL pointer dereference in kvm_irq_map_gsi [ Upstream commit c622a3c21ede892e370b56e1ceb9eb28f8bbda6b ] Found by syzkaller: BUG: unable to handle kernel NULL pointer dereference at 0000000000000120 IP: [] kvm_irq_map_gsi+0x12/0x90 [kvm] PGD 6f80b067 PUD b6535067 PMD 0 Oops: 0000 [#1] SMP CPU: 3 PID: 4988 Comm: a.out Not tainted 4.4.9-300.fc23.x86_64 #1 [...] Call Trace: [] irqfd_update+0x32/0xc0 [kvm] [] kvm_irqfd+0x3dc/0x5b0 [kvm] [] kvm_vm_ioctl+0x164/0x6f0 [kvm] [] do_vfs_ioctl+0x298/0x480 [] SyS_ioctl+0x79/0x90 [] tracesys_phase2+0x84/0x89 Code: b5 71 a7 e0 5b 41 5c 41 5d 5d f3 c3 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 8b 8f 10 2e 00 00 31 c0 48 89 e5 <39> 91 20 01 00 00 76 6a 48 63 d2 48 8b 94 d1 28 01 00 00 48 85 RIP [] kvm_irq_map_gsi+0x12/0x90 [kvm] RSP CR2: 0000000000000120 Testcase: #include #include #include #include #include #include #include long r[26]; int main() { memset(r, -1, sizeof(r)); r[2] = open("/dev/kvm", 0); r[3] = ioctl(r[2], KVM_CREATE_VM, 0); struct kvm_irqfd ifd; ifd.fd = syscall(SYS_eventfd2, 5, 0); ifd.gsi = 3; ifd.flags = 2; ifd.resamplefd = ifd.fd; r[25] = ioctl(r[3], KVM_IRQFD, &ifd); return 0; } Reported-by: Dmitry Vyukov Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Radim Krčmář Signed-off-by: Sasha Levin commit b0f8d64a5f8aa3dceff51bf83b58378627bf27d9 Author: Russell King Date: Mon May 30 23:14:56 2016 +0100 ARM: fix PTRACE_SETVFPREGS on SMP systems [ Upstream commit e2dfb4b880146bfd4b6aa8e138c0205407cebbaf ] PTRACE_SETVFPREGS fails to properly mark the VFP register set to be reloaded, because it undoes one of the effects of vfp_flush_hwstate(). Specifically vfp_flush_hwstate() sets thread->vfpstate.hard.cpu to an invalid CPU number, but vfp_set() overwrites this with the original CPU number, thereby rendering the hardware state as apparently "valid", even though the software state is more recent. Fix this by reverting the previous change. Cc: Fixes: 8130b9d7b9d8 ("ARM: 7308/1: vfp: flush thread hwstate before copying ptrace registers") Acked-by: Will Deacon Tested-by: Simon Marchi Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 6a962d0ab004eaedf8d67353dcee2591995a2c81 Author: Ben Skeggs Date: Thu Jun 2 12:23:31 2016 +1000 drm/nouveau/fbcon: fix out-of-bounds memory accesses [ Upstream commit f045f459d925138fe7d6193a8c86406bda7e49da ] Reported by KASAN. Signed-off-by: Ben Skeggs Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit ee20274fabe1b30b86f45d913a15f5cf0defdd80 Author: Thierry Reding Date: Fri Dec 19 11:21:32 2014 +0100 drm/fb-helper: Propagate errors from initial config failure [ Upstream commit 01934c2a691882185b3021d437df13bcba07711d ] Make drm_fb_helper_initial_config() return an int rather than a bool so that the error can be properly propagated. While at it, update drivers to propagate errors further rather than just ignore them. v2: - cirrus: No cleanup is required, the top-level cirrus_driver_load() will do it as part of cirrus_driver_unload() in its cleanup path. Reported-by: Fengguang Wu Cc: David Airlie Cc: Daniel Vetter Cc: Patrik Jakobsson Cc: Rob Clark Cc: Tomi Valkeinen Cc: Alex Deucher Cc: Christian König Cc: Ben Skeggs Signed-off-by: Thierry Reding Reviewed-by: Alex Deucher Reviewed-by: Patrik Jakobsson Reviewed-by: Christian König [danvet: Squash in simplification patch from kbuild.] Signed-off-by: Daniel Vetter Signed-off-by: Sasha Levin commit 403b95353325aec56672bb9b4f01750eada5751f Author: Ewan D. Milne Date: Tue May 31 09:42:29 2016 -0400 scsi: Add QEMU CD-ROM to VPD Inquiry Blacklist [ Upstream commit fbd83006e3e536fcb103228d2422ea63129ccb03 ] Linux fails to boot as a guest with a QEMU CD-ROM: [ 4.439488] ata2.00: ATAPI: QEMU CD-ROM, 0.8.2, max UDMA/100 [ 4.443649] ata2.00: configured for MWDMA2 [ 4.450267] scsi 1:0:0:0: CD-ROM QEMU QEMU CD-ROM 0.8. PQ: 0 ANSI: 5 [ 4.464317] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [ 4.464319] ata2.00: BMDMA stat 0x5 [ 4.464339] ata2.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 0 dma 16640 in [ 4.464339] Inquiry 12 01 00 00 ff 00res 48/20:02:00:24:00/00:00:00:00:00/a0 Emask 0x2 (HSM violation) [ 4.464341] ata2.00: status: { DRDY DRQ } [ 4.465864] ata2: soft resetting link [ 4.625971] ata2.00: configured for MWDMA2 [ 4.628290] ata2: EH complete [ 4.646670] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [ 4.646671] ata2.00: BMDMA stat 0x5 [ 4.646683] ata2.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 0 dma 16640 in [ 4.646683] Inquiry 12 01 00 00 ff 00res 48/20:02:00:24:00/00:00:00:00:00/a0 Emask 0x2 (HSM violation) [ 4.646685] ata2.00: status: { DRDY DRQ } [ 4.648193] ata2: soft resetting link ... Fix this by suppressing VPD inquiry for this device. Signed-off-by: Ewan D. Milne Reported-by: Jan Stancek Tested-by: Jan Stancek Cc: Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 9cac3aff4cbcfd50449aff4a6b5c96f16b4a4a5d Author: Bob Copeland Date: Sun May 15 13:19:16 2016 -0400 mac80211: mesh: flush mesh paths unconditionally [ Upstream commit fe7a7c57629e8dcbc0e297363a9b2366d67a6dc5 ] Currently, the mesh paths associated with a nexthop station are cleaned up in the following code path: __sta_info_destroy_part1 synchronize_net() __sta_info_destroy_part2 -> cleanup_single_sta -> mesh_sta_cleanup -> mesh_plink_deactivate -> mesh_path_flush_by_nexthop However, there are a couple of problems here: 1) the paths aren't flushed at all if the MPM is running in userspace (e.g. when using wpa_supplicant or authsae) 2) there is no synchronize_rcu between removing the path and readers accessing the nexthop, which means the following race is possible: CPU0 CPU1 ~~~~ ~~~~ sta_info_destroy_part1() synchronize_net() rcu_read_lock() mesh_nexthop_resolve() mpath = mesh_path_lookup() [...] -> mesh_path_flush_by_nexthop() sta = rcu_dereference( mpath->next_hop) kfree(sta) access sta <-- CRASH Fix both of these by unconditionally flushing paths before destroying the sta, and by adding a synchronize_net() after path flush to ensure no active readers can still dereference the sta. Fixes this crash: [ 348.529295] BUG: unable to handle kernel paging request at 00020040 [ 348.530014] IP: [] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211] [ 348.530014] *pde = 00000000 [ 348.530014] Oops: 0000 [#1] PREEMPT [ 348.530014] Modules linked in: drbg ansi_cprng ctr ccm ppp_generic slhc ipt_MASQUERADE nf_nat_masquerade_ipv4 8021q ] [ 348.530014] CPU: 0 PID: 20597 Comm: wget Tainted: G O 4.6.0-rc5-wt=V1 #1 [ 348.530014] Hardware name: To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080016 11/07/2014 [ 348.530014] task: f64fa280 ti: f4f9c000 task.ti: f4f9c000 [ 348.530014] EIP: 0060:[] EFLAGS: 00010246 CPU: 0 [ 348.530014] EIP is at ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211] [ 348.530014] EAX: f4ce63e0 EBX: 00000088 ECX: f3788416 EDX: 00020008 [ 348.530014] ESI: 00000000 EDI: 00000088 EBP: f6409a4c ESP: f6409a40 [ 348.530014] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 [ 348.530014] CR0: 80050033 CR2: 00020040 CR3: 33190000 CR4: 00000690 [ 348.530014] Stack: [ 348.530014] 00000000 f4ce63e0 f5f9bd80 f6409a64 f9291d80 0000ce67 f5d51e00 f4ce63e0 [ 348.530014] f3788416 f6409a80 f9291dc1 f4ce8320 f4ce63e0 f5d51e00 f4ce63e0 f4ce8320 [ 348.530014] f6409a98 f9277f6f 00000000 00000000 0000007c 00000000 f6409b2c f9278dd1 [ 348.530014] Call Trace: [ 348.530014] [] mesh_nexthop_lookup+0xbb/0xc8 [mac80211] [ 348.530014] [] mesh_nexthop_resolve+0x34/0xd8 [mac80211] [ 348.530014] [] ieee80211_xmit+0x92/0xc1 [mac80211] [ 348.530014] [] __ieee80211_subif_start_xmit+0x807/0x83c [mac80211] [ 348.530014] [] ? sch_direct_xmit+0xd7/0x1b3 [ 348.530014] [] ? __local_bh_enable_ip+0x5d/0x7b [ 348.530014] [] ? nf_nat_ipv4_out+0x4c/0xd0 [nf_nat_ipv4] [ 348.530014] [] ? iptable_nat_ipv4_fn+0xf/0xf [iptable_nat] [ 348.530014] [] ? netif_skb_features+0x14d/0x30a [ 348.530014] [] ieee80211_subif_start_xmit+0xa/0xe [mac80211] [ 348.530014] [] dev_hard_start_xmit+0x1f8/0x267 [ 348.530014] [] ? validate_xmit_skb.isra.120.part.121+0x10/0x253 [ 348.530014] [] sch_direct_xmit+0x8b/0x1b3 [ 348.530014] [] __dev_queue_xmit+0x2c8/0x513 [ 348.530014] [] dev_queue_xmit+0xa/0xc [ 348.530014] [] batadv_send_skb_packet+0xd6/0xec [batman_adv] [ 348.530014] [] batadv_send_unicast_skb+0x15/0x4a [batman_adv] [ 348.530014] [] batadv_dat_send_data+0x27e/0x310 [batman_adv] [ 348.530014] [] ? batadv_tt_global_hash_find.isra.11+0x8/0xa [batman_adv] [ 348.530014] [] batadv_dat_snoop_outgoing_arp_request+0x208/0x23d [batman_adv] [ 348.530014] [] batadv_interface_tx+0x206/0x385 [batman_adv] [ 348.530014] [] dev_hard_start_xmit+0x1f8/0x267 [ 348.530014] [] ? validate_xmit_skb.isra.120.part.121+0x10/0x253 [ 348.530014] [] sch_direct_xmit+0x8b/0x1b3 [ 348.530014] [] __dev_queue_xmit+0x2c8/0x513 [ 348.530014] [] ? igb_xmit_frame+0x57/0x72 [igb] [ 348.530014] [] dev_queue_xmit+0xa/0xc [ 348.530014] [] br_dev_queue_push_xmit+0xeb/0xfb [bridge] [ 348.530014] [] br_forward_finish+0x29/0x74 [bridge] [ 348.530014] [] ? deliver_clone+0x3b/0x3b [bridge] [ 348.530014] [] __br_forward+0x89/0xe7 [bridge] [ 348.530014] [] ? br_dev_queue_push_xmit+0xfb/0xfb [bridge] [ 348.530014] [] deliver_clone+0x34/0x3b [bridge] [ 348.530014] [] ? br_flood+0x95/0x95 [bridge] [ 348.530014] [] br_flood+0x77/0x95 [bridge] [ 348.530014] [] br_flood_forward+0x13/0x1a [bridge] [ 348.530014] [] ? br_flood+0x95/0x95 [bridge] [ 348.530014] [] br_handle_frame_finish+0x392/0x3db [bridge] [ 348.530014] [] ? nf_iterate+0x2b/0x6b [ 348.530014] [] br_handle_frame+0x1e6/0x240 [bridge] [ 348.530014] [] ? br_handle_local_finish+0x6a/0x6a [bridge] [ 348.530014] [] __netif_receive_skb_core+0x43a/0x66b [ 348.530014] [] ? br_handle_frame_finish+0x3db/0x3db [bridge] [ 348.530014] [] ? resched_curr+0x19/0x37 [ 348.530014] [] ? check_preempt_wakeup+0xbf/0xfe [ 348.530014] [] ? ktime_get_with_offset+0x5c/0xfc [ 348.530014] [] __netif_receive_skb+0x47/0x55 [ 348.530014] [] netif_receive_skb_internal+0x40/0x5a [ 348.530014] [] napi_gro_receive+0x3a/0x94 [ 348.530014] [] igb_poll+0x6fd/0x9ad [igb] [ 348.530014] [] ? swake_up_locked+0x14/0x26 [ 348.530014] [] net_rx_action+0xde/0x250 [ 348.530014] [] __do_softirq+0x8a/0x163 [ 348.530014] [] ? __hrtimer_tasklet_trampoline+0x19/0x19 [ 348.530014] [] do_softirq_own_stack+0x26/0x2c [ 348.530014] [ 348.530014] [] irq_exit+0x31/0x6f [ 348.530014] [] do_IRQ+0x8d/0xa0 [ 348.530014] [] common_interrupt+0x2c/0x40 [ 348.530014] Code: e7 8c 00 66 81 ff 88 00 75 12 85 d2 75 0e b2 c3 b8 83 e9 29 f9 e8 a7 5f f9 c6 eb 74 66 81 e3 8c 005 [ 348.530014] EIP: [] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211] SS:ESP 0068:f6409a40 [ 348.530014] CR2: 0000000000020040 [ 348.530014] ---[ end trace 48556ac26779732e ]--- [ 348.530014] Kernel panic - not syncing: Fatal exception in interrupt [ 348.530014] Kernel Offset: disabled Cc: stable@vger.kernel.org Reported-by: Fred Veldini Tested-by: Fred Veldini Signed-off-by: Bob Copeland Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 46c57e776799e952d01bf9b25c7630ec18647202 Author: Martin Willi Date: Fri May 13 12:41:48 2016 +0200 mac80211_hwsim: Add missing check for HWSIM_ATTR_SIGNAL [ Upstream commit 62397da50bb20a6b812c949ef465d7e69fe54bb6 ] A wmediumd that does not send this attribute causes a NULL pointer dereference, as the attribute is accessed even if it does not exist. The attribute was required but never checked ever since userspace frame forwarding has been introduced. The issue gets more problematic once we allow wmediumd registration from user namespaces. Cc: stable@vger.kernel.org Fixes: 7882513bacb1 ("mac80211_hwsim driver support userspace frame tx/rx") Signed-off-by: Martin Willi Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit de31d25a3bc1c37d7d30d5a1b9cee67bf1fe9aa7 Author: Thomas Huth Date: Thu May 12 13:29:11 2016 +0200 powerpc: Use privileged SPR number for MMCR2 [ Upstream commit 8dd75ccb571f3c92c48014b3dabd3d51a115ab41 ] We are already using the privileged versions of MMCR0, MMCR1 and MMCRA in the kernel, so for MMCR2, we should better use the privileged versions, too, to be consistent. Fixes: 240686c13687 ("powerpc: Initialise PMU related regs on Power8") Cc: stable@vger.kernel.org # v3.10+ Suggested-by: Paul Mackerras Signed-off-by: Thomas Huth Acked-by: Paul Mackerras Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit e342ed8fc0fb4b090f42e09db46649193c4b81d7 Author: Thomas Huth Date: Thu May 12 13:26:44 2016 +0200 powerpc: Fix definition of SIAR and SDAR registers [ Upstream commit d23fac2b27d94aeb7b65536a50d32bfdc21fe01e ] The SIAR and SDAR registers are available twice, one time as SPRs 780 / 781 (unprivileged, but read-only), and one time as the SPRs 796 / 797 (privileged, but read and write). The Linux kernel code currently uses the unprivileged SPRs - while this is OK for reading, writing to that register of course does not work. Since the KVM code tries to write to this register, too (see the mtspr in book3s_hv_rmhandlers.S), the contents of this register sometimes get lost for the guests, e.g. during migration of a VM. To fix this issue, simply switch to the privileged SPR numbers instead. Cc: stable@vger.kernel.org Signed-off-by: Thomas Huth Acked-by: Paul Mackerras Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 267e997cd36392954a8c210523ef027b78b58b32 Author: Russell Currey Date: Thu Apr 7 16:28:26 2016 +1000 powerpc/pseries/eeh: Handle RTAS delay requests in configure_bridge [ Upstream commit 871e178e0f2c4fa788f694721a10b4758d494ce1 ] In the "ibm,configure-pe" and "ibm,configure-bridge" RTAS calls, the spec states that values of 9900-9905 can be returned, indicating that software should delay for 10^x (where x is the last digit, i.e. 990x) milliseconds and attempt the call again. Currently, the kernel doesn't know about this, and respecting it fixes some PCI failures when the hypervisor is busy. The delay is capped at 0.2 seconds. Cc: # 3.10+ Signed-off-by: Russell Currey Acked-by: Gavin Shan Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit ce0cad42490c559fc3ca204bb6f5a581f6ef5573 Author: Tom Lendacky Date: Fri May 20 17:33:03 2016 -0500 crypto: ccp - Fix AES XTS error for request sizes above 4096 [ Upstream commit ab6a11a7c8ef47f996974dd3c648c2c0b1a36ab1 ] The ccp-crypto module for AES XTS support has a bug that can allow requests greater than 4096 bytes in size to be passed to the CCP hardware. The CCP hardware does not support request sizes larger than 4096, resulting in incorrect output. The request should actually be handled by the fallback mechanism instantiated by the ccp-crypto module. Add a check to insure the request size is less than or equal to the maximum supported size and use the fallback mechanism if it is not. Cc: # 3.14.x- Signed-off-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit b57a1706c76a352712c06be9348ee2ffcd50b47c Author: James Bottomley Date: Fri May 13 12:04:06 2016 -0700 scsi_lib: correctly retry failed zero length REQ_TYPE_FS commands [ Upstream commit a621bac3044ed6f7ec5fa0326491b2d4838bfa93 ] When SCSI was written, all commands coming from the filesystem (REQ_TYPE_FS commands) had data. This meant that our signal for needing to complete the command was the number of bytes completed being equal to the number of bytes in the request. Unfortunately, with the advent of flush barriers, we can now get zero length REQ_TYPE_FS commands, which confuse this logic because they satisfy the condition every time. This means they never get retried even for retryable conditions, like UNIT ATTENTION because we complete them early assuming they're done. Fix this by special casing the early completion condition to recognise zero length commands with errors and let them drop through to the retry code. Cc: stable@vger.kernel.org Reported-by: Sebastian Parschauer Signed-off-by: James E.J. Bottomley Tested-by: Jack Wang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 008656835a1bfafe37771d2ba2249a8eaeb4eab6 Author: Arnd Bergmann Date: Wed May 18 16:55:56 2016 +0200 crypto: public_key: select CRYPTO_AKCIPHER [ Upstream commit bad6a185b4d6f81d0ed2b6e4c16307969f160b95 ] In some rare randconfig builds, we can end up with ASYMMETRIC_PUBLIC_KEY_SUBTYPE enabled but CRYPTO_AKCIPHER disabled, which fails to link because of the reference to crypto_alloc_akcipher: crypto/built-in.o: In function `public_key_verify_signature': :(.text+0x110e4): undefined reference to `crypto_alloc_akcipher' This adds a Kconfig 'select' statement to ensure the dependency is always there. Cc: Signed-off-by: Arnd Bergmann Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin