user/sven/linux.git, branch v3.14.15

Linux 3.14.15

2014-07-31T21:51:43Z

platform_get_irq: Revert to platform_get_resource if of_irq_get fails

2014-07-31T19:52:57Z

commit aff008ad813c7cf3cfe7b532e7ba2c526c136f22 upstream. Commits 9ec36ca (of/irq: do irq resolution in platform_get_irq) and ad69674 (of/irq: do irq resolution in platform_get_irq_byname) change the semantics of platform_get_irq and platform_get_irq_byname to always rely on devicetree information if devicetree is enabled and if a devicetree node is attached to the device. The functions now return an error if the devicetree data does not include interrupt information, even if the information is available as platform resource data. This causes mfd client drivers to fail if the interrupt number is passed via platform resources. Therefore, if of_irq_get fails, try platform_get_resource as method of last resort. This restores the original functionality for drivers depending on platform resources to get irq information. Cc: Russell King Cc: Tony Lindgren Cc: Grant Likely Cc: Grygorii Strashko Signed-off-by: Guenter Roeck Acked-by: Rob Herring [ Guenter Roeck: backported to 3.15 ] Signed-off-by: Guenter Roeck

nl80211: move set_qos_map command into split state

2014-07-31T19:52:57Z

commit 02df00eb0019e7d15a1fcddebe4d020226c1ccda upstream. The non-split wiphy state shouldn't be increased in size so move the new set_qos_map command into the split if statement. Fixes: fa9ffc745610 ("cfg80211: Add support for QoS mapping") Reviewed-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

x86/efi: Include a .bss section within the PE/COFF headers

2014-07-31T19:52:57Z

commit c7fb93ec51d462ec3540a729ba446663c26a0505 upstream. The PE/COFF headers currently describe only the initialised-data portions of the image, and result in no space being allocated for the uninitialised-data portions. Consequently, the EFI boot stub will end up overwriting unexpected areas of memory, with unpredictable results. Fix by including a .bss section in the PE/COFF headers (functionally equivalent to the init_size field in the bzImage header). Signed-off-by: Michael Brown Cc: Thomas Bächler Cc: Josh Boyer Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman

Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

2014-07-31T19:52:57Z

commit 2062afb4f804afef61cbe62a30cac9a46e58e067 upstream. Michel Dänzer and a couple of other people reported inexplicable random oopses in the scheduler, and the cause turns out to be gcc mis-compiling the load_balance() function when debugging is enabled. The gcc bug apparently goes back to gcc-4.5, but slight optimization changes means that it now showed up as a problem in 4.9.0 and 4.9.1. The instruction scheduling problem causes gcc to schedule a spill operation to before the stack frame has been created, which in turn can corrupt the spilled value if an interrupt comes in. There may be other effects of this bug too, but that's the code generation problem seen in Michel's case. This is fixed in current gcc HEAD, but the workaround as suggested by Markus Trippelsdorf is pretty simple: use -fno-var-tracking-assignments when compiling the kernel, which disables the gcc code that causes the problem. This can result in slightly worse debug information for variable accesses, but that is infinitely preferable to actual code generation problems. Doing this unconditionally (not just for CONFIG_DEBUG_INFO) also allows non-debug builds to verify that the debug build would be identical: we can do export GCC_COMPARE_DEBUG=1 to make gcc internally verify that the result of the build is independent of the "-g" flag (it will make the compiler build everything twice, toggling the debug flag, and compare the results). Without the "-fno-var-tracking-assignments" option, the build would fail (even with 4.8.3 that didn't show the actual stack frame bug) with a gcc compare failure. See also gcc bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801 Reported-by: Michel Dänzer Suggested-by: Markus Trippelsdorf Cc: Jakub Jelinek Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

mm: hugetlb: fix copy_hugetlb_page_range()

2014-07-31T19:52:57Z

commit 0253d634e0803a8376a0d88efee0bf523d8673f9 upstream. Commit 4a705fef9862 ("hugetlb: fix copy_hugetlb_page_range() to handle migration/hwpoisoned entry") changed the order of huge_ptep_set_wrprotect() and huge_ptep_get(), which leads to breakage in some workloads like hugepage-backed heap allocation via libhugetlbfs. This patch fixes it. The test program for the problem is shown below: $ cat heap.c #include #include #include #define HPS 0x200000 int main() { int i; char *p = malloc(HPS); memset(p, '1', HPS); for (i = 0; i < 5; i++) { if (!fork()) { memset(p, '2', HPS); p = malloc(HPS); memset(p, '3', HPS); free(p); return 0; } } sleep(1); free(p); return 0; } $ export HUGETLB_MORECORE=yes ; export HUGETLB_NO_PREFAULT= ; hugectl --heap ./heap Fixes 4a705fef9862 ("hugetlb: fix copy_hugetlb_page_range() to handle migration/hwpoisoned entry"), so is applicable to -stable kernels which include it. Signed-off-by: Naoya Horiguchi Reported-by: Guillaume Morin Suggested-by: Guillaume Morin Acked-by: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

drm/radeon: fix cut and paste issue for hawaii.

2014-07-31T19:52:57Z

commit 1b2c4869d8247f9e202fa8a73777c34adc62d409 upstream. This is a halfway fix for hawaii acceleration. More fixes to come but hopefully isolated to userspace. Signed-off-by: Jérôme Glisse Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/radeon: fix irq ring buffer overflow handling

2014-07-31T19:52:57Z

commit e8c214d22e76dd0ead38f97f8d2dc09aac70d651 upstream. We must mask out the overflow bit as well, otherwise the wptr will never match the rptr again and the interrupt handler will loop forever. Signed-off-by: Christian König Signed-off-by: Alex Deucher Reviewed-by: Michel Dänzer Signed-off-by: Greg Kroah-Hartman

x86_32, entry: Store badsys error code in %eax

2014-07-31T19:52:56Z

commit 8142b215501f8b291a108a202b3a053a265b03dd upstream. Commit 554086d ("x86_32, entry: Do syscall exit work on badsys (CVE-2014-4508)") introduced a regression in the x86_32 syscall entry code, resulting in syscall() not returning proper errors for undefined syscalls on CPUs supporting the sysenter feature. The following code: > int result = syscall(666); > printf("result=%d errno=%d error=%s\n", result, errno, strerror(errno)); results in: > result=666 errno=0 error=Success Obviously, the syscall return value is the called syscall number, but it should have been an ENOSYS error. When run under ptrace it behaves correctly, which makes it hard to debug in the wild: > result=-1 errno=38 error=Function not implemented The %eax register is the return value register. For debugging via ptrace the syscall entry code stores the complete register context on the stack. The badsys handlers only store the ENOSYS error code in the ptrace register set and do not set %eax like a regular syscall handler would. The old resume_userspace call chain contains code that clobbers %eax and it restores %eax from the ptrace registers afterwards. The same goes for the ptrace-enabled call chain. When ptrace is not used, the syscall return value is the passed-in syscall number from the untouched %eax register. Use %eax as the return value register in syscall_badsys and sysenter_badsys, like a real syscall handler does, and have the caller push the value onto the stack for ptrace access. Signed-off-by: Sven Wegener Link: http://lkml.kernel.org/r/alpine.LNX.2.11.1407221022380.31021@titan.int.lan.stealer.net Reviewed-and-tested-by: Andy Lutomirski Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

fs: umount on symlink leaks mnt count

2014-07-31T19:52:56Z

commit 295dc39d941dc2ae53d5c170365af4c9d5c16212 upstream. Currently umount on symlink blocks following umount: /vz is separate mount # ls /vz/ -al | grep test drwxr-xr-x. 2 root root 4096 Jul 19 01:14 testdir lrwxrwxrwx. 1 root root 11 Jul 19 01:16 testlink -> /vz/testdir # umount -l /vz/testlink umount: /vz/testlink: not mounted (expected) # lsof /vz # umount /vz umount: /vz: device is busy. (unexpected) In this case mountpoint_last() gets an extra refcount on path->mnt Signed-off-by: Vasily Averin Acked-by: Ian Kent Acked-by: Jeff Layton Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman