user/sven/linux.git, branch v4.1.29

Linux 4.1.29

2016-07-30T01:39:46Z

Signed-off-by: Sasha Levin

4.1.28 Fix bad backport of 8f182270dfec "mm/swap.c: flush lru pvecs on compound page arrival"

2016-07-19T19:49:46Z

When I pulled in 4.1.28 into my stable 4.1-rt tree and ran the tests, it crashed with a severe OOM killing everything. I then tested 4.1.28 without -rt and it had the same issue. I did a bisect between 4.1.27 and 4.1.28 and found that the bug started at: commit 8f182270dfec "mm/swap.c: flush lru pvecs on compound page arrival" Looking at that patch and what's in mainline, I see that there's a mismatch in one of the hunks: Mainline: @@ -391,9 +391,8 @@ static void __lru_cache_add(struct page *page) struct pagevec *pvec = &get_cpu_var(lru_add_pvec); get_page(page); - if (!pagevec_space(pvec)) + if (!pagevec_add(pvec, page) || PageCompound(page)) __pagevec_lru_add(pvec); - pagevec_add(pvec, page); put_cpu_var(lru_add_pvec); } Stable 4.1.28: @@ -631,9 +631,8 @@ static void __lru_cache_add(struct page *page) struct pagevec *pvec = &get_cpu_var(lru_add_pvec); page_cache_get(page); - if (!pagevec_space(pvec)) + if (!pagevec_space(pvec) || PageCompound(page)) __pagevec_lru_add(pvec); - pagevec_add(pvec, page); put_cpu_var(lru_add_pvec); } Where mainline replace pagevec_space() with pagevec_add, and stable did not. Fixing this makes the OOM go away. Note, 3.18 has the same bug. Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin

powerpc: Fix build break due to missing PPC_FEATURE2_HTM_NOSC

2016-07-19T19:49:46Z

The backport of 4705e02498d6 ("powerpc: Update TM user feature bits in scan_features()") (f49eb503f0f9), missed the fact that 4.1 doesn't include the commit that added PPC_FEATURE2_HTM_NOSC. The correct fix is simply to omit PPC_FEATURE2_HTM_NOSC. Fixes: f49eb503f0f9 ("powerpc: Update TM user feature bits in scan_features()") Reported-by: Christian Zigotzky Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin

ecryptfs: don't allow mmap when the lower fs doesn't support it

2016-07-19T19:49:46Z

[ Upstream commit f0fe970df3838c202ef6c07a4c2b36838ef0a88b ] There are legitimate reasons to disallow mmap on certain files, notably in sysfs or procfs. We shouldn't emulate mmap support on file systems that don't offer support natively. CVE-2016-1583 Signed-off-by: Jeff Mahoney Cc: stable@vger.kernel.org [tyhicks: clean up f_op check by using ecryptfs_file_to_lower()] Signed-off-by: Tyler Hicks Signed-off-by: Sasha Levin

xen/acpi: allow xen-acpi-processor driver to load on Xen 4.7

2016-07-19T19:49:45Z

[ Upstream commit 6f2d9d99213514360034c6d52d2c3919290b3504 ] As of Xen 4.7 PV CPUID doesn't expose either of CPUID[1].ECX[7] and CPUID[0x80000007].EDX[7] anymore, causing the driver to fail to load on both Intel and AMD systems. Doing any kind of hardware capability checks in the driver as a prerequisite was wrong anyway: With the hypervisor being in charge, all such checking should be done by it. If ACPI data gets uploaded despite some missing capability, the hypervisor is free to ignore part or all of that data. Ditch the entire check_prereq() function, and do the only valid check (xen_initial_domain()) in the caller in its place. Signed-off-by: Jan Beulich Cc: Signed-off-by: David Vrabel Signed-off-by: Sasha Levin

xenbus: don't bail early from xenbus_dev_request_and_reply()

2016-07-19T19:49:45Z

[ Upstream commit 7469be95a487319514adce2304ad2af3553d2fc9 ] xenbus_dev_request_and_reply() needs to track whether a transaction is open. For XS_TRANSACTION_START messages it calls transaction_start() and for XS_TRANSACTION_END messages it calls transaction_end(). If sending an XS_TRANSACTION_START message fails or responds with an an error, the transaction is not open and transaction_end() must be called. If sending an XS_TRANSACTION_END message fails, the transaction is still open, but if an error response is returned the transaction is closed. Commit 027bd7e89906 ("xen/xenbus: Avoid synchronous wait on XenBus stalling shutdown/restart") introduced a regression where failed XS_TRANSACTION_START messages were leaving the transaction open. This can cause problems with suspend (and migration) as all transactions must be closed before suspending. It appears that the problematic change was added accidentally, so just remove it. Signed-off-by: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Signed-off-by: David Vrabel Signed-off-by: Sasha Levin

Revert "ecryptfs: forbid opening files without mmap handler"

2016-07-19T19:49:44Z

[ Upstream commit 78c4e172412de5d0456dc00d2b34050aa0b683b5 ] This reverts commit 2f36db71009304b3f0b95afacd8eba1f9f046b87. It fixed a local root exploit but also introduced a dependency on the lower file system implementing an mmap operation just to open a file, which is a bit of a heavy hammer. The right fix is to have mmap depend on the existence of the mmap handler instead. Signed-off-by: Jeff Mahoney Cc: stable@vger.kernel.org Signed-off-by: Tyler Hicks Signed-off-by: Sasha Levin

xenbus: don't BUG() on user mode induced condition

2016-07-19T19:49:44Z

[ Upstream commit 0beef634b86a1350c31da5fcc2992f0d7c8a622b ] Inability to locate a user mode specified transaction ID should not lead to a kernel crash. For other than XS_TRANSACTION_START also don't issue anything to xenbus if the specified ID doesn't match that of any active transaction. Signed-off-by: Jan Beulich Cc: Signed-off-by: David Vrabel Signed-off-by: Sasha Levin

MIPS: Fix page table corruption on THP permission changes.

2016-07-19T19:49:44Z

[ Upstream commit 88d02a2ba6c52350f9a73ff1b01a5be839c3ca17 ] When the core THP code is modifying the permissions of a huge page it calls pmd_modify(), which unfortunately was clearing the _PAGE_HUGE bit of the page table entry. The result can be kernel messages like: mm/memory.c:397: bad pmd 000000040080004d. mm/memory.c:397: bad pmd 00000003ff00004d. mm/memory.c:397: bad pmd 000000040100004d. or: ------------[ cut here ]------------ WARNING: at mm/mmap.c:3200 exit_mmap+0x150/0x158() Modules linked in: ipv6 at24 octeon3_ethernet octeon_srio_nexus m25p80 CPU: 12 PID: 1295 Comm: pmderr Not tainted 3.10.87-rt80-Cavium-Octeon #4 Stack : 0000000040808000 0000000014009ce1 0000000000400004 ffffffff81076ba0 0000000000000000 0000000000000000 ffffffff85110000 0000000000000119 0000000000000004 0000000000000000 0000000000000119 43617669756d2d4f 0000000000000000 ffffffff850fda40 ffffffff85110000 0000000000000000 0000000000000000 0000000000000009 ffffffff809207a0 0000000000000c80 ffffffff80f1bf20 0000000000000001 000000ffeca36828 0000000000000001 0000000000000000 0000000000000001 000000ffeca7e700 ffffffff80886924 80000003fd7a0000 80000003fd7a39b0 80000003fdea8000 ffffffff80885780 80000003fdea8000 ffffffff80f12218 000000000000000c 000000000000050f 0000000000000000 ffffffff80865c4c 0000000000000000 0000000000000000 ... Call Trace: [] show_stack+0x6c/0xf8 [] warn_slowpath_common+0x78/0xa8 [] exit_mmap+0x150/0x158 [] mmput+0x5c/0x110 [] do_exit+0x230/0xa68 [] do_group_exit+0x54/0x1d0 [] __wake_up_parent+0x0/0x18 ---[ end trace c7b38293191c57dc ]--- BUG: Bad rss-counter state mm:80000003fa168000 idx:1 val:1536 Fix by not clearing _PAGE_HUGE bit. Signed-off-by: David Daney Tested-by: Aaro Koskinen Cc: stable@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13687/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin

ALSA: hda/realtek: Add Lenovo L460 to docking unit fixup

2016-07-19T19:49:43Z

[ Upstream commit 9cd25743765cfe851aed8d655a62d60156aed293 ] This solves the issue that a headphone is not working on the docking unit. Signed-off-by: Torsten Hilbrich Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin