commit 190bd21bba09ed476d9359d3e8be20e8d9dcd8a4 Author: Greg Kroah-Hartman Date: Thu Oct 22 14:49:51 2015 -0700 Linux 4.2.4 commit 945f4ef0193ed39d83f2adc9bb4e0e045584416f Author: Konstantin Khlebnikov Date: Wed Jul 15 12:52:03 2015 +0300 sched/preempt, powerpc, kvm: Use need_resched() instead of should_resched() commit c56dadf39761a6157239cac39e3988998c994f98 upstream. Function should_resched() is equal to (!preempt_count() && need_resched()). In preemptive kernel preempt_count here is non-zero because of vc->lock. Signed-off-by: Konstantin Khlebnikov Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Graf Cc: Boris Ostrovsky Cc: David Vrabel Cc: Linus Torvalds Cc: Mike Galbraith Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20150715095203.12246.72922.stgit@buzz Signed-off-by: Ingo Molnar Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit e284a7823780bcf84203c45046ea9195b7a126de Author: Konstantin Khlebnikov Date: Wed Jul 15 12:52:01 2015 +0300 sched/preempt, xen: Use need_resched() instead of should_resched() commit 0fa2f5cb2b0ecd8d56baa51f35f09aab234eb0bf upstream. This code is used only when CONFIG_PREEMPT=n and only in non-atomic context: xen_in_preemptible_hcall is set only in privcmd_ioctl_hypercall(). Thus preempt_count is zero and should_resched() is equal to need_resched(). Signed-off-by: Konstantin Khlebnikov Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Graf Cc: Boris Ostrovsky Cc: David Vrabel Cc: Linus Torvalds Cc: Mike Galbraith Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20150715095201.12246.49283.stgit@buzz Signed-off-by: Ingo Molnar Cc: Andre Tomt Signed-off-by: Greg Kroah-Hartman commit 02d45c5a79f90e8ddc046cc3a735e25dff45b08c Author: Christoph Hellwig Date: Sat Oct 3 19:16:07 2015 +0200 3w-9xxx: don't unmap bounce buffered commands commit 15e3d5a285ab9283136dba34bbf72886d9146706 upstream. 3w controller don't dma map small single SGL entry commands but instead bounce buffer them. Add a helper to identify these commands and don't call scsi_dma_unmap for them. Based on an earlier patch from James Bottomley. Fixes: 118c85 ("3w-9xxx: fix command completion race") Reported-by: Tóth Attila Tested-by: Tóth Attila Signed-off-by: Christoph Hellwig Acked-by: Adam Radford Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 29b8eaffcba906afc07374022f43351903b94cee Author: Konstantin Khlebnikov Date: Wed Jul 15 12:52:04 2015 +0300 sched/preempt: Fix cond_resched_lock() and cond_resched_softirq() commit fe32d3cd5e8eb0f82e459763374aa80797023403 upstream. These functions check should_resched() before unlocking spinlock/bh-enable: preempt_count always non-zero => should_resched() always returns false. cond_resched_lock() worked iff spin_needbreak is set. This patch adds argument "preempt_offset" to should_resched(). preempt_count offset constants for that: PREEMPT_DISABLE_OFFSET - offset after preempt_disable() PREEMPT_LOCK_OFFSET - offset after spin_lock() SOFTIRQ_DISABLE_OFFSET - offset after local_bh_distable() SOFTIRQ_LOCK_OFFSET - offset after spin_lock_bh() Signed-off-by: Konstantin Khlebnikov Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Graf Cc: Boris Ostrovsky Cc: David Vrabel Cc: Linus Torvalds Cc: Mike Galbraith Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Thomas Gleixner Fixes: bdb438065890 ("sched: Extract the basic add/sub preempt_count modifiers") Link: http://lkml.kernel.org/r/20150715095204.12246.98268.stgit@buzz Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 5781175fab1a2c8b0339644fb27d64bf24c9fda4 Author: Akinobu Mita Date: Sun Sep 27 02:09:19 2015 +0900 blk-mq: avoid setting hctx->tags->cpumask before allocation commit 1356aae08338f1c19ce1c67bf8c543a267688fc3 upstream. When unmapped hw queue is remapped after CPU topology is changed, hctx->tags->cpumask has to be set after hctx->tags is setup in blk_mq_map_swqueue(), otherwise it causes null pointer dereference. Fixes: f26cdc8536 ("blk-mq: Shared tag enhancements") Signed-off-by: Akinobu Mita Cc: Keith Busch Cc: Ming Lei Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4e9415aadba0f966ac40b071695149b5e1a7aaa9 Author: Joonsoo Kim Date: Thu Oct 1 15:36:54 2015 -0700 mm/slab: fix unexpected index mapping result of kmalloc_size(INDEX_NODE+1) commit 03a2d2a3eafe4015412cf4e9675ca0e2d9204074 upstream. Commit description is copied from the original post of this bug: http://comments.gmane.org/gmane.linux.kernel.mm/135349 Kernels after v3.9 use kmalloc_size(INDEX_NODE + 1) to get the next larger cache size than the size index INDEX_NODE mapping. In kernels 3.9 and earlier we used malloc_sizes[INDEX_L3 + 1].cs_size. However, sometimes we can't get the right output we expected via kmalloc_size(INDEX_NODE + 1), causing a BUG(). The mapping table in the latest kernel is like: index = {0, 1, 2 , 3, 4, 5, 6, n} size = {0, 96, 192, 8, 16, 32, 64, 2^n} The mapping table before 3.10 is like this: index = {0 , 1 , 2, 3, 4 , 5 , 6, n} size = {32, 64, 96, 128, 192, 256, 512, 2^(n+3)} The problem on my mips64 machine is as follows: (1) When configured DEBUG_SLAB && DEBUG_PAGEALLOC && DEBUG_LOCK_ALLOC && DEBUG_SPINLOCK, the sizeof(struct kmem_cache_node) will be "150", and the macro INDEX_NODE turns out to be "2": #define INDEX_NODE kmalloc_index(sizeof(struct kmem_cache_node)) (2) Then the result of kmalloc_size(INDEX_NODE + 1) is 8. (3) Then "if(size >= kmalloc_size(INDEX_NODE + 1)" will lead to "size = PAGE_SIZE". (4) Then "if ((size >= (PAGE_SIZE >> 3))" test will be satisfied and "flags |= CFLGS_OFF_SLAB" will be covered. (5) if (flags & CFLGS_OFF_SLAB)" test will be satisfied and will go to "cachep->slabp_cache = kmalloc_slab(slab_size, 0u)", and the result here may be NULL while kernel bootup. (6) Finally,"BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache));" causes the BUG info as the following shows (may be only mips64 has this problem): This patch fixes the problem of kmalloc_size(INDEX_NODE + 1) and removes the BUG by adding 'size >= 256' check to guarantee that all necessary small sized slabs are initialized regardless sequence of slab size in mapping table. Fixes: e33660165c90 ("slab: Use common kmalloc_index/kmalloc_size...") Signed-off-by: Joonsoo Kim Reported-by: Liuhailong Acked-by: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 018027b2916d32b2636623378da79016eaf08151 Author: Raanan Avargil Date: Sun Jul 19 16:33:20 2015 +0300 e1000e: Fix tight loop implementation of systime read algorithm commit 37b12910dd11d9ab969f2c310dc9160b7f3e3405 upstream. Change the algorithm. Read systimel twice and check for overflow. If there was no overflow, use the first value. If there was an overflow, read systimeh again and use the second systimel value. Signed-off-by: Raanan Avargil Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Cc: "Jason A. Donenfeld" Signed-off-by: Greg Kroah-Hartman commit 14eebe6be1101084897590d0093144e3f0ec41ea Author: Uwe Kleine-König Date: Wed Sep 23 08:57:40 2015 +0200 serial: atmel: fix error path of probe function commit 8f1bd8f2ad2358d6a88c115481ff3e69817d1bde upstream. If atmel_init_gpios fails the port has already been marked as busy (in line 2629), so this must be undone in the error path. This bug was introduced because I created the patch that finally became 722ccf416ac2 ("serial: atmel: fix error handling when mctrl_gpio_init fails") on top of 3.19 which didn't have commit 6fbb9bdf0f3f ("tty/serial: at91: fix error handling in atmel_serial_probe()") yet. Signed-off-by: Uwe Kleine-König Fixes: 722ccf416ac2 ("serial: atmel: fix error handling when mctrl_gpio_init fails") Acked-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman commit 9b3902ec193200411a6467aa7b873f23b6444382 Author: Mans Rullgard Date: Fri Oct 2 17:50:31 2015 +0100 serial: 8250: add uart_config entry for PORT_RT2880 commit 3c5a0357fdb3a9116a48dbdb0abb91fd23fbff80 upstream. This adds an entry to the uart_config table for PORT_RT2880 enabling rx/tx FIFOs. The UART is actually a Palmchip BK-3103 which is found in several devices from Alchemy/RMI, Ralink, and Sigma Designs. Signed-off-by: Mans Rullgard Signed-off-by: Greg Kroah-Hartman commit dbec4a259e2ed9d80f943e5ee363c0828884d34a Author: Jann Horn Date: Sun Oct 4 19:29:12 2015 +0200 drivers/tty: require read access for controlling terminal commit 0c55627167870255158db1cde0d28366f91c8872 upstream. This is mostly a hardening fix, given that write-only access to other users' ttys is usually only given through setgid tty executables. Signed-off-by: Jann Horn Signed-off-by: Greg Kroah-Hartman commit 82d8846c84a25a1607f6dd0b5782b76c77ab89bf Author: Kosuke Tatsukawa Date: Fri Oct 2 08:27:05 2015 +0000 tty: fix stall caused by missing memory barrier in drivers/tty/n_tty.c commit e81107d4c6bd098878af9796b24edc8d4a9524fd upstream. My colleague ran into a program stall on a x86_64 server, where n_tty_read() was waiting for data even if there was data in the buffer in the pty. kernel stack for the stuck process looks like below. #0 [ffff88303d107b58] __schedule at ffffffff815c4b20 #1 [ffff88303d107bd0] schedule at ffffffff815c513e #2 [ffff88303d107bf0] schedule_timeout at ffffffff815c7818 #3 [ffff88303d107ca0] wait_woken at ffffffff81096bd2 #4 [ffff88303d107ce0] n_tty_read at ffffffff8136fa23 #5 [ffff88303d107dd0] tty_read at ffffffff81368013 #6 [ffff88303d107e20] __vfs_read at ffffffff811a3704 #7 [ffff88303d107ec0] vfs_read at ffffffff811a3a57 #8 [ffff88303d107f00] sys_read at ffffffff811a4306 #9 [ffff88303d107f50] entry_SYSCALL_64_fastpath at ffffffff815c86d7 There seems to be two problems causing this issue. First, in drivers/tty/n_tty.c, __receive_buf() stores the data and updates ldata->commit_head using smp_store_release() and then checks the wait queue using waitqueue_active(). However, since there is no memory barrier, __receive_buf() could return without calling wake_up_interactive_poll(), and at the same time, n_tty_read() could start to wait in wait_woken() as in the following chart. __receive_buf() n_tty_read() ------------------------------------------------------------------------ if (waitqueue_active(&tty->read_wait)) /* Memory operations issued after the RELEASE may be completed before the RELEASE operation has completed */ add_wait_queue(&tty->read_wait, &wait); ... if (!input_available_p(tty, 0)) { smp_store_release(&ldata->commit_head, ldata->read_head); ... timeout = wait_woken(&wait, TASK_INTERRUPTIBLE, timeout); ------------------------------------------------------------------------ The second problem is that n_tty_read() also lacks a memory barrier call and could also cause __receive_buf() to return without calling wake_up_interactive_poll(), and n_tty_read() to wait in wait_woken() as in the chart below. __receive_buf() n_tty_read() ------------------------------------------------------------------------ spin_lock_irqsave(&q->lock, flags); /* from add_wait_queue() */ ... if (!input_available_p(tty, 0)) { /* Memory operations issued after the RELEASE may be completed before the RELEASE operation has completed */ smp_store_release(&ldata->commit_head, ldata->read_head); if (waitqueue_active(&tty->read_wait)) __add_wait_queue(q, wait); spin_unlock_irqrestore(&q->lock,flags); /* from add_wait_queue() */ ... timeout = wait_woken(&wait, TASK_INTERRUPTIBLE, timeout); ------------------------------------------------------------------------ There are also other places in drivers/tty/n_tty.c which have similar calls to waitqueue_active(), so instead of adding many memory barrier calls, this patch simply removes the call to waitqueue_active(), leaving just wake_up*() behind. This fixes both problems because, even though the memory access before or after the spinlocks in both wake_up*() and add_wait_queue() can sneak into the critical section, it cannot go past it and the critical section assures that they will be serialized (please see "INTER-CPU ACQUIRING BARRIER EFFECTS" in Documentation/memory-barriers.txt for a better explanation). Moreover, the resulting code is much simpler. Latency measurement using a ping-pong test over a pty doesn't show any visible performance drop. Signed-off-by: Kosuke Tatsukawa Signed-off-by: Greg Kroah-Hartman commit 3581e7a97c66e512f91aaeaa75a1ce34dc0c39cf Author: covici@ccs.covici.com Date: Wed May 20 05:44:11 2015 -0400 staging: speakup: fix speakup-r regression commit b1d562acc78f0af46de0dfe447410bc40bdb7ece upstream. Here is a patch to make speakup-r work again. It broke in 3.6 due to commit 4369c64c79a22b98d3b7eff9d089196cd878a10a "Input: Send events one packet at a time) The problem was that the fakekey.c routine to fake a down arrow no longer functioned properly and putting the input_sync fixed it. Fixes: 4369c64c79a22b98d3b7eff9d089196cd878a10a Acked-by: Samuel Thibault Signed-off-by: John Covici Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 66deec7a96c8d27eacb6c2f71e3323abd484574b Author: Joe Thornber Date: Fri Oct 9 14:03:38 2015 +0100 dm cache: fix NULL pointer when switching from cleaner policy commit 2bffa1503c5c06192eb1459180fac4416575a966 upstream. The cleaner policy doesn't make use of the per cache block hint space in the metadata (unlike the other policies). When switching from the cleaner policy to mq or smq a NULL pointer crash (in dm_tm_new_block) was observed. The crash was caused by bugs in dm-cache-metadata.c when trying to skip creation of the hint btree. The minimal fix is to change hint size for the cleaner policy to 4 bytes (only hint size supported). Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 6bb0388828eff3ae34ee0034b34f0d8cf89945bc Author: Junichi Nomura Date: Thu Oct 1 08:31:51 2015 +0000 dm: fix AB-BA deadlock in __dm_destroy() commit 2a708cff93f1845b9239bc7d6310aef54e716c6a upstream. __dm_destroy() takes io_barrier SRCU lock (dm_get_live_table) and suspend_lock in reverse order. Doing so can cause AB-BA deadlock: __dm_destroy dm_swap_table --------------------------------------------------- mutex_lock(suspend_lock) dm_get_live_table() srcu_read_lock(io_barrier) dm_sync_table() synchronize_srcu(io_barrier) .. waiting for dm_put_live_table() mutex_lock(suspend_lock) .. waiting for suspend_lock Fix this by taking the locks in proper order. Signed-off-by: Jun'ichi Nomura Fixes: ab7c7bb6f4ab ("dm: hold suspend_lock while suspending device during device deletion") Acked-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit f03b7a659257a1e1c578ca36ebfd9d65bb3e2594 Author: Trond Myklebust Date: Fri Oct 9 13:44:34 2015 -0400 namei: results of d_is_negative() should be checked after dentry revalidation commit daf3761c9fcde0f4ca64321cbed6c1c86d304193 upstream. Leandro Awa writes: "After switching to version 4.1.6, our parallelized and distributed workflows now fail consistently with errors of the form: T34: ./regex.c:39:22: error: config.h: No such file or directory From our 'git bisect' testing, the following commit appears to be the possible cause of the behavior we've been seeing: commit 766c4cbfacd8" Al Viro says: "What happens is that 766c4cbfacd8 got the things subtly wrong. We used to treat d_is_negative() after lookup_fast() as "fall with ENOENT". That was wrong - checking ->d_flags outside of ->d_seq protection is unreliable and failing with hard error on what should've fallen back to non-RCU pathname resolution is a bug. Unfortunately, we'd pulled the test too far up and ran afoul of another kind of staleness. The dentry might have been absolutely stable from the RCU point of view (and we might be on UP, etc), but stale from the remote fs point of view. If ->d_revalidate() returns "it's actually stale", dentry gets thrown away and the original code wouldn't even have looked at its ->d_flags. What we need is to check ->d_flags where 766c4cbfacd8 does (prior to ->d_seq validation) but only use the result in cases where we do not discard this dentry outright" Reported-by: Leandro Awa Link: https://bugzilla.kernel.org/show_bug.cgi?id=104911 Fixes: 766c4cbfacd8 ("namei: d_is_negative() should be checked...") Tested-by: Leandro Awa Signed-off-by: Trond Myklebust Acked-by: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5003d645d60e5dbc8c1cc7f8c787d10ec9ac68ee Author: Bartlomiej Zolnierkiewicz Date: Fri Aug 28 13:49:35 2015 +0200 clk: samsung: fix cpu clock's flags checking commit 9e294bf88a583825a413df408b9fe9e658fb93ac upstream. CLK_CPU_HAS_DIV1 and CLK_CPU_NEEDS_DEBUG_ALT_DIV masks were incorrectly used as a bit numbers. Fix it. Tested on Exynos4210 based Origen board and on Exynos5250 based Arndale board. Cc: Tomasz Figa Cc: Michael Turquette Cc: Thomas Abraham Fixes: ddeac8d96 ("clk: samsung: add infrastructure to register cpu clocks") Reported-by: Dan Carpenter Reviewed-by: Krzysztof Kozlowski Reviewed-by: Javier Martinez Canillas Acked-by: Sylwester Nawrocki Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit a45c32718880bde9329a6182949ed92c6c698096 Author: Peter Ujfalusi Date: Mon Aug 24 10:35:02 2015 +0300 clk: ti: clk-7xx: Remove hardwired ABE clock configuration commit 4b3061b39132cba0c31b0eb767a9faeedf9437fc upstream. The ABE related clocks should be configured via DT and not have it wired inside of the kernel. Fixes: a74c52def9ab ("clk: ti: clk-7xx: Correct ABE DPLL configuration") Signed-off-by: Peter Ujfalusi Signed-off-by: Tero Kristo Signed-off-by: Greg Kroah-Hartman commit 08f496bbdedd00c3850a36174d4c00c47355225a Author: Ben Dooks Date: Tue Sep 29 15:01:08 2015 +0100 clk: ti: fix dual-registration of uart4_ick commit 19e79687de22f23bcfb5e79cce3daba20af228d1 upstream. On the OMAP AM3517 platform the uart4_ick gets registered twice, causing any power management to /dev/ttyO3 to fail when trying to wake the device up. This solves the following oops: [] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09e008 [] PC is at serial_omap_pm+0x48/0x15c [] LR is at _raw_spin_unlock_irqrestore+0x30/0x5c Fixes: aafd900cab87 ("CLK: TI: add omap3 clock init file") Cc: mturquette@baylibre.com Cc: sboyd@codeaurora.org Cc: linux-clk@vger.kernel.org Cc: linux-omap@vger.kernel.org Cc: linux-kernel@lists.codethink.co.uk Signed-off-by: Ben Dooks Signed-off-by: Tero Kristo Signed-off-by: Greg Kroah-Hartman commit d1d5bed4a28ed09ddb731a7767fa111f856888cd Author: Srinivas Pandruvada Date: Wed Oct 7 13:50:43 2015 -0700 cpufreq: acpi_cpufreq: prevent crash on reading freqdomain_cpus commit e25303676e18a7947185a34e26dd08cf0c0ea573 upstream. When freqdomain_cpus attribute is read from an offlined cpu, it will cause crash. This change prevents calling cpufreq_show_cpus when policy driver_data is NULL. Crash info: [ 170.814949] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 [ 170.814990] IP: [] _find_next_bit.part.0+0x10/0x70 [ 170.815021] PGD 227d30067 PUD 229e56067 PMD 0 [ 170.815043] Oops: 0000 [#2] SMP [ 170.816022] CPU: 3 PID: 3121 Comm: cat Tainted: G D OE 4.3.0-rc3+ #33 ... ... [ 170.816657] Call Trace: [ 170.816672] [] ? find_next_bit+0x15/0x20 [ 170.816696] [] cpufreq_show_cpus+0x5c/0xd0 [ 170.816722] [] show_freqdomain_cpus+0x19/0x20 [acpi_cpufreq] [ 170.816749] [] show+0x3b/0x60 [ 170.816769] [] sysfs_kf_seq_show+0xbc/0x130 [ 170.816793] [] kernfs_seq_show+0x23/0x30 [ 170.816816] [] seq_read+0xec/0x390 [ 170.816837] [] kernfs_fop_read+0x10a/0x160 [ 170.816861] [] __vfs_read+0x37/0x100 [ 170.816883] [] ? security_file_permission+0xa0/0xc0 [ 170.816909] [] vfs_read+0x83/0x130 [ 170.816930] [] SyS_read+0x55/0xc0 ... ... [ 170.817185] ---[ end trace bc6eadf82b2b965a ]--- Signed-off-by: Srinivas Pandruvada Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 75c4f487e1373d07c1e820d798faba0bddbace5c Author: Marcin Wojtas Date: Tue Oct 6 03:22:37 2015 +0200 mmc: sdhci-pxav3: fix error handling of armada_38x_quirks commit 2162d9f41e7c4778b96b8e3b97adcedbadc861f1 upstream. In case of armada_38x_quirks error, all clocks should be cleaned-up, same as after mv_conf_mbus_windows failure. Signed-off-by: Marcin Wojtas Reviewed-by: Gregory CLEMENT Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 7c8e140b689ddcefc7d2eb9f26300683cc729c94 Author: Nadav Haklai Date: Tue Oct 6 03:22:36 2015 +0200 mmc: sdhci-pxav3: disable clock inversion for HS MMC cards commit fa7964147da57b2d40c2db2b6ed98fb7dc934bff upstream. According to 'FE-2946959' erratum the clock inversion option is needed to support slow frequencies when the card input hold time requirement is high. This setting is not required for high speed MMC and might cause timing violation. Signed-off-by: Nadav Haklai Reviewed-by: Gregory CLEMENT Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 273c203a06f67b1bf947f76d79bd9f6f0c121b77 Author: Nadav Haklai Date: Tue Oct 6 03:22:35 2015 +0200 mmc: sdhci-pxav3: remove broken clock base quirk for Armada 38x sdhci driver commit 5de76bfcb1e5ac66c57b99e8e193dacac7416f0e upstream. shci-pxav3 driver is enabling by default the SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN quirk. However this quirk is not required for Armada 38x and leads to wrong clock setting in the divider. Signed-off-by: Nadav Haklai Signed-off-by: Marcin Wojtas Reviewed-by: Gregory CLEMENT Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 52402501ca51e4c13ad2025c21fd808201004b0b Author: Kinglong Mee Date: Mon Sep 14 20:12:21 2015 +0800 nfs/filelayout: Fix NULL reference caused by double freeing of fh_array commit 3ec0c97959abff33a42db9081c22132bcff5b4f2 upstream. If filelayout_decode_layout fail, _filelayout_free_lseg will causes a double freeing of fh_array. [ 1179.279800] BUG: unable to handle kernel NULL pointer dereference at (null) [ 1179.280198] IP: [] filelayout_free_fh_array.isra.11+0x1d/0x70 [nfs_layout_nfsv41_files] [ 1179.281010] PGD 0 [ 1179.281443] Oops: 0000 [#1] [ 1179.281831] Modules linked in: nfs_layout_nfsv41_files(OE) nfsv4(OE) nfs(OE) fscache(E) xfs libcrc32c coretemp nfsd crct10dif_pclmul ppdev crc32_pclmul crc32c_intel auth_rpcgss ghash_clmulni_intel nfs_acl lockd vmw_balloon grace sunrpc parport_pc vmw_vmci parport shpchp i2c_piix4 vmwgfx drm_kms_helper ttm drm serio_raw mptspi scsi_transport_spi mptscsih e1000 mptbase ata_generic pata_acpi [last unloaded: fscache] [ 1179.283891] CPU: 0 PID: 13336 Comm: cat Tainted: G OE 4.3.0-rc1-pnfs+ #244 [ 1179.284323] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014 [ 1179.285206] task: ffff8800501d48c0 ti: ffff88003e3c4000 task.ti: ffff88003e3c4000 [ 1179.285668] RIP: 0010:[] [] filelayout_free_fh_array.isra.11+0x1d/0x70 [nfs_layout_nfsv41_files] [ 1179.286612] RSP: 0018:ffff88003e3c77f8 EFLAGS: 00010202 [ 1179.287092] RAX: 0000000000000000 RBX: ffff88001fe78900 RCX: 0000000000000000 [ 1179.287731] RDX: ffffea0000f40760 RSI: ffff88001fe789c8 RDI: ffff88001fe789c0 [ 1179.288383] RBP: ffff88003e3c7810 R08: ffffea0000f40760 R09: 0000000000000000 [ 1179.289170] R10: 0000000000000000 R11: 0000000000000001 R12: ffff88001fe789c8 [ 1179.289959] R13: ffff88001fe789c0 R14: ffff88004ec05a80 R15: ffff88004f935b88 [ 1179.290791] FS: 00007f4e66bb5700(0000) GS:ffffffff81c29000(0000) knlGS:0000000000000000 [ 1179.291580] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1179.292209] CR2: 0000000000000000 CR3: 00000000203f8000 CR4: 00000000001406f0 [ 1179.292731] Stack: [ 1179.293195] ffff88001fe78900 00000000000000d0 ffff88001fe78178 ffff88003e3c7868 [ 1179.293676] ffffffffa0272737 0000000000000001 0000000000000001 ffff88001fe78800 [ 1179.294151] 00000000614fffce ffffffff81727671 ffff88001fe78100 ffff88001fe78100 [ 1179.294623] Call Trace: [ 1179.295092] [] filelayout_alloc_lseg+0xa7/0x2d0 [nfs_layout_nfsv41_files] [ 1179.295625] [] ? out_of_line_wait_on_bit+0x81/0xb0 [ 1179.296133] [] pnfs_layout_process+0xae/0x320 [nfsv4] [ 1179.296632] [] nfs4_proc_layoutget+0x2b1/0x360 [nfsv4] [ 1179.297134] [] pnfs_update_layout+0x853/0xb30 [nfsv4] [ 1179.297632] [] ? nfs_get_lock_context+0x74/0x170 [nfs] [ 1179.298158] [] filelayout_pg_init_read+0x37/0x50 [nfs_layout_nfsv41_files] [ 1179.298834] [] __nfs_pageio_add_request+0x119/0x460 [nfs] [ 1179.299385] [] ? nfs_create_request.part.9+0x37/0x2e0 [nfs] [ 1179.299872] [] nfs_pageio_add_request+0xa3/0x1b0 [nfs] [ 1179.300362] [] readpage_async_filler+0x85/0x260 [nfs] [ 1179.300907] [] read_cache_pages+0x91/0xd0 [ 1179.301391] [] ? nfs_read_completion+0x220/0x220 [nfs] [ 1179.301867] [] nfs_readpages+0x128/0x200 [nfs] [ 1179.302330] [] __do_page_cache_readahead+0x203/0x280 [ 1179.302784] [] ? __do_page_cache_readahead+0xd8/0x280 [ 1179.303413] [] ondemand_readahead+0x1a6/0x2f0 [ 1179.303855] [] page_cache_sync_readahead+0x31/0x50 [ 1179.304286] [] generic_file_read_iter+0x4a6/0x5c0 [ 1179.304711] [] ? __nfs_revalidate_mapping+0x1f6/0x240 [nfs] [ 1179.305132] [] nfs_file_read+0x52/0xa0 [nfs] [ 1179.305540] [] __vfs_read+0xcc/0x100 [ 1179.305936] [] vfs_read+0x85/0x130 [ 1179.306326] [] SyS_read+0x58/0xd0 [ 1179.306708] [] entry_SYSCALL_64_fastpath+0x12/0x76 [ 1179.307094] Code: c4 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 53 8b 07 49 89 f4 85 c0 74 47 48 8b 06 49 89 fd <48> 8b 38 48 85 ff 74 22 31 db eb 0c 48 63 d3 48 8b 3c d0 48 85 [ 1179.308357] RIP [] filelayout_free_fh_array.isra.11+0x1d/0x70 [nfs_layout_nfsv41_files] [ 1179.309177] RSP [ 1179.309582] CR2: 0000000000000000 Signed-off-by: Kinglong Mee Signed-off-by: Trond Myklebust Cc: William Dauchy Signed-off-by: Greg Kroah-Hartman commit 458c21f8fda545e6a1a4019fba1b010726f108c0 Author: NeilBrown Date: Thu Oct 1 16:03:38 2015 +1000 md/bitmap: don't pass -1 to bitmap_storage_alloc. commit da6fb7a9e5bd6f04f7e15070f630bdf1ea502841 upstream. Passing -1 to bitmap_storage_alloc() causes page->index to be set to -1, which is quite problematic. So only pass ->cluster_slot if mddev_is_clustered(). Fixes: b97e92574c0b ("Use separate bitmaps for each nodes in the cluster") Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 11195a5e5b0665b1cde0c6e629342592240e8ec2 Author: John Stultz Date: Mon Sep 14 18:05:20 2015 -0700 clocksource: Fix abs() usage w/ 64bit values commit 67dfae0cd72fec5cd158b6e5fb1647b7dbe0834c upstream. This patch fixes one cases where abs() was being used with 64-bit nanosecond values, where the result may be capped at 32-bits. This potentially could cause watchdog false negatives on 32-bit systems, so this patch addresses the issue by using abs64(). Signed-off-by: John Stultz Cc: Prarit Bhargava Cc: Richard Cochran Cc: Ingo Molnar Link: http://lkml.kernel.org/r/1442279124-7309-2-git-send-email-john.stultz@linaro.org Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit d643719cc5bd8dedb2049f446889ebf7620fcdf7 Author: Ben Hutchings Date: Sat Sep 26 12:23:56 2015 +0100 genirq: Fix race in register_irq_proc() commit 95c2b17534654829db428f11bcf4297c059a2a7e upstream. Per-IRQ directories in procfs are created only when a handler is first added to the irqdesc, not when the irqdesc is created. In the case of a shared IRQ, multiple tasks can race to create a directory. This race condition seems to have been present forever, but is easier to hit with async probing. Signed-off-by: Ben Hutchings Link: http://lkml.kernel.org/r/1443266636.2004.2.camel@decadent.org.uk Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 7207c3aea646f21bd7763641f98883a555e97147 Author: Stefan Assmann Date: Fri Jul 10 15:01:12 2015 +0200 igb: do not re-init SR-IOV during probe commit 6423fc34160939142d72ffeaa2db6408317f54df upstream. During driver probing the following code path is triggered. igb_probe ->igb_sw_init ->igb_probe_vfs ->igb_pci_enable_sriov ->igb_sriov_reinit Doing the SR-IOV re-init is not necessary during probing since we're starting from scratch. Here we can call igb_enable_sriov() right away. Running igb_sriov_reinit() during igb_probe() also seems to cause occasional packet loss on some onboard 82576 NICs. Reproduced on Dell and HP servers with onboard 82576 NICs. Example: Intel Corporation 82576 Gigabit Network Connection [8086:10c9] (rev 01) Subsystem: Dell Device [1028:0481] Signed-off-by: Stefan Assmann Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Cc: Daniel J Blueman Signed-off-by: Greg Kroah-Hartman commit 75215f092c4ceba9533c23e3c82b7b1c080aad69 Author: Chas Williams <3chas3@gmail.com> Date: Thu Aug 27 12:28:46 2015 -0400 net/xen-netfront: only napi_synchronize() if running commit 274b045509175db0405c784be85e8cce116e6f7d upstream. If an interface isn't running napi_synchronize() will hang forever. [ 392.248403] rmmod R running task 0 359 343 0x00000000 [ 392.257671] ffff88003760fc88 ffff880037193b40 ffff880037193160 ffff88003760fc88 [ 392.267644] ffff880037610000 ffff88003760fcd8 0000000100014c22 ffffffff81f75c40 [ 392.277524] 0000000000bc7010 ffff88003760fca8 ffffffff81796927 ffffffff81f75c40 [ 392.287323] Call Trace: [ 392.291599] [] schedule+0x37/0x90 [ 392.298553] [] schedule_timeout+0x14b/0x280 [ 392.306421] [] ? irq_free_descs+0x69/0x80 [ 392.314006] [] ? internal_add_timer+0xb0/0xb0 [ 392.322125] [] msleep+0x37/0x50 [ 392.329037] [] xennet_disconnect_backend.isra.24+0xda/0x390 [xen_netfront] [ 392.339658] [] xennet_remove+0x2c/0x80 [xen_netfront] [ 392.348516] [] xenbus_dev_remove+0x59/0xc0 [ 392.356257] [] __device_release_driver+0x87/0x120 [ 392.364645] [] driver_detach+0xb8/0xc0 [ 392.371989] [] bus_remove_driver+0x59/0xe0 [ 392.379883] [] driver_unregister+0x30/0x70 [ 392.387495] [] xenbus_unregister_driver+0x12/0x20 [ 392.395908] [] netif_exit+0x10/0x775 [xen_netfront] [ 392.404877] [] SyS_delete_module+0x1d8/0x230 [ 392.412804] [] system_call_fastpath+0x12/0x71 Signed-off-by: Chas Williams <3chas3@gmail.com> Signed-off-by: David S. Miller Cc: "Kamata, Munehisa" Signed-off-by: Greg Kroah-Hartman commit a0c5f82fb5ee7df8ebd4352c5522a061051b2223 Author: Roger Pau Monne Date: Fri Sep 4 12:08:07 2015 +0200 xen/blkback: free requests on disconnection commit f929d42ceb18a8acfd47e0e7b7d90b5d49bd9258 upstream. This is due to commit 86839c56dee28c315a4c19b7bfee450ccd84cd25 "xen/block: add multi-page ring support" When using an guest under UEFI - after the domain is destroyed the following warning comes from blkback. ------------[ cut here ]------------ WARNING: CPU: 2 PID: 95 at /home/julien/works/linux/drivers/block/xen-blkback/xenbus.c:274 xen_blkif_deferred_free+0x1f4/0x1f8() Modules linked in: CPU: 2 PID: 95 Comm: kworker/2:1 Tainted: G W 4.2.0 #85 Hardware name: APM X-Gene Mustang board (DT) Workqueue: events xen_blkif_deferred_free Call trace: [] dump_backtrace+0x0/0x124 [] show_stack+0x10/0x1c [] dump_stack+0x78/0x98 [] warn_slowpath_common+0x9c/0xd4 [] warn_slowpath_null+0x14/0x20 [] xen_blkif_deferred_free+0x1f0/0x1f8 [] process_one_work+0x160/0x3b4 [] worker_thread+0x140/0x494 [] kthread+0xd8/0xf0 ---[ end trace 6f859b7883c88cdd ]--- Request allocation has been moved to connect_ring, which is called every time blkback connects to the frontend (this can happen multiple times during a blkback instance life cycle). On the other hand, request freeing has not been moved, so it's only called when destroying the backend instance. Due to this mismatch, blkback can allocate the request pool multiple times, without freeing it. In order to fix it, move the freeing of requests to xen_blkif_disconnect to restore the symmetry between request allocation and freeing. Reported-by: Julien Grall Signed-off-by: Roger Pau Monné Tested-by: Julien Grall Cc: Konrad Rzeszutek Wilk Cc: Boris Ostrovsky Cc: David Vrabel Cc: xen-devel@lists.xenproject.org Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 4f1735d1ae66618ff3424d392751c45620f143b1 Author: Andreas Schwab Date: Wed Sep 23 23:12:09 2015 +0200 m68k: Define asmlinkage_protect commit 8474ba74193d302e8340dddd1e16c85cc4b98caf upstream. Make sure the compiler does not modify arguments of syscall functions. This can happen if the compiler generates a tailcall to another function. For example, without asmlinkage_protect sys_openat is compiled into this function: sys_openat: clr.l %d0 move.w 18(%sp),%d0 move.l %d0,16(%sp) jbra do_sys_open Note how the fourth argument is modified in place, modifying the register %d4 that gets restored from this stack slot when the function returns to user-space. The caller may expect the register to be unmodified across system calls. Signed-off-by: Andreas Schwab Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman commit a1fe674993148530b6e01ff45d7f0265532be3e4 Author: Mark Salyzyn Date: Mon Sep 21 21:39:50 2015 +0100 arm64: readahead: fault retry breaks mmap file read random detection commit 569ba74a7ba69f46ce2950bf085b37fea2408385 upstream. This is the arm64 portion of commit 45cac65b0fcd ("readahead: fault retry breaks mmap file read random detection"), which was absent from the initial port and has since gone unnoticed. The original commit says: > .fault now can retry. The retry can break state machine of .fault. In > filemap_fault, if page is miss, ra->mmap_miss is increased. In the second > try, since the page is in page cache now, ra->mmap_miss is decreased. And > these are done in one fault, so we can't detect random mmap file access. > > Add a new flag to indicate .fault is tried once. In the second try, skip > ra->mmap_miss decreasing. The filemap_fault state machine is ok with it. With this change, Mark reports that: > Random read improves by 250%, sequential read improves by 40%, and > random write by 400% to an eMMC device with dm crypto wrapped around it. Cc: Shaohua Li Cc: Rik van Riel Cc: Wu Fengguang Signed-off-by: Mark Salyzyn Signed-off-by: Riley Andrews Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit ec4aa911a03efd5a3e23c72b9c86ffc25b04f046 Author: Li Bin Date: Wed Sep 30 10:49:55 2015 +0800 arm64: ftrace: fix function_graph tracer panic commit ee556d00cf20012e889344a0adbbf809ab5015a3 upstream. When function graph tracer is enabled, the following operation will trigger panic: mount -t debugfs nodev /sys/kernel echo next_tgid > /sys/kernel/tracing/set_ftrace_filter echo function_graph > /sys/kernel/tracing/current_tracer ls /proc/ ------------[ cut here ]------------ [ 198.501417] Unable to handle kernel paging request at virtual address cb88537fdc8ba316 [ 198.506126] pgd = ffffffc008f79000 [ 198.509363] [cb88537fdc8ba316] *pgd=00000000488c6003, *pud=00000000488c6003, *pmd=0000000000000000 [ 198.517726] Internal error: Oops: 94000005 [#1] SMP [ 198.518798] Modules linked in: [ 198.520582] CPU: 1 PID: 1388 Comm: ls Tainted: G [ 198.521800] Hardware name: linux,dummy-virt (DT) [ 198.522852] task: ffffffc0fa9e8000 ti: ffffffc0f9ab0000 task.ti: ffffffc0f9ab0000 [ 198.524306] PC is at next_tgid+0x30/0x100 [ 198.525205] LR is at return_to_handler+0x0/0x20 [ 198.526090] pc : [] lr : [] pstate: 60000145 [ 198.527392] sp : ffffffc0f9ab3d40 [ 198.528084] x29: ffffffc0f9ab3d40 x28: ffffffc0f9ab0000 [ 198.529406] x27: ffffffc000d6a000 x26: ffffffc000b786e8 [ 198.530659] x25: ffffffc0002a1900 x24: ffffffc0faf16c00 [ 198.531942] x23: ffffffc0f9ab3ea0 x22: 0000000000000002 [ 198.533202] x21: ffffffc000d85050 x20: 0000000000000002 [ 198.534446] x19: 0000000000000002 x18: 0000000000000000 [ 198.535719] x17: 000000000049fa08 x16: ffffffc000242efc [ 198.537030] x15: 0000007fa472b54c x14: ffffffffff000000 [ 198.538347] x13: ffffffc0fada84a0 x12: 0000000000000001 [ 198.539634] x11: ffffffc0f9ab3d70 x10: ffffffc0f9ab3d70 [ 198.540915] x9 : ffffffc0000907c0 x8 : ffffffc0f9ab3d40 [ 198.542215] x7 : 0000002e330f08f0 x6 : 0000000000000015 [ 198.543508] x5 : 0000000000000f08 x4 : ffffffc0f9835ec0 [ 198.544792] x3 : cb88537fdc8ba316 x2 : cb88537fdc8ba306 [ 198.546108] x1 : 0000000000000002 x0 : ffffffc000d85050 [ 198.547432] [ 198.547920] Process ls (pid: 1388, stack limit = 0xffffffc0f9ab0020) [ 198.549170] Stack: (0xffffffc0f9ab3d40 to 0xffffffc0f9ab4000) [ 198.582568] Call trace: [ 198.583313] [] next_tgid+0x30/0x100 [ 198.584359] [] ftrace_graph_caller+0x6c/0x70 [ 198.585503] [] ftrace_graph_caller+0x6c/0x70 [ 198.586574] [] ftrace_graph_caller+0x6c/0x70 [ 198.587660] [] ftrace_graph_caller+0x6c/0x70 [ 198.588896] Code: aa0003f5 2a0103f4 b4000102 91004043 (885f7c60) [ 198.591092] ---[ end trace 6a346f8f20949ac8 ]--- This is because when using function graph tracer, if the traced function return value is in multi regs ([x0-x7]), return_to_handler may corrupt them. So in return_to_handler, the parameter regs should be protected properly. Signed-off-by: Li Bin Acked-by: AKASHI Takahiro Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 83b7575b3f8e0fd3ec19c28886523efbac4fa779 Author: Ard Biesheuvel Date: Fri Sep 25 23:02:19 2015 +0100 arm64/efi: Fix boot crash by not padding between EFI_MEMORY_RUNTIME regions commit 0ce3cc008ec04258b6a6314b09f1a6012810881a upstream. The new Properties Table feature introduced in UEFIv2.5 may split memory regions that cover PE/COFF memory images into separate code and data regions. Since these regions only differ in the type (runtime code vs runtime data) and the permission bits, but not in the memory type attributes (UC/WC/WT/WB), the spec does not require them to be aligned to 64 KB. Since the relative offset of PE/COFF .text and .data segments cannot be changed on the fly, this means that we can no longer pad out those regions to be mappable using 64 KB pages. Unfortunately, there is no annotation in the UEFI memory map that identifies data regions that were split off from a code region, so we must apply this logic to all adjacent runtime regions whose attributes only differ in the permission bits. So instead of rounding each memory region to 64 KB alignment at both ends, only round down regions that are not directly preceded by another runtime region with the same type attributes. Since the UEFI spec does not mandate that the memory map be sorted, this means we also need to sort it first. Note that this change will result in all EFI_MEMORY_RUNTIME regions whose start addresses are not aligned to the OS page size to be mapped with executable permissions (i.e., on kernels compiled with 64 KB pages). However, since these mappings are only active during the time that UEFI Runtime Services are being invoked, the window for abuse is rather small. Tested-by: Mark Salter Tested-by: Mark Rutland [UEFI 2.4 only] Signed-off-by: Ard Biesheuvel Signed-off-by: Matt Fleming Reviewed-by: Mark Salter Reviewed-by: Mark Rutland Cc: Catalin Marinas Cc: Leif Lindholm Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Cc: linux-kernel@vger.kernel.org Link: http://lkml.kernel.org/r/1443218539-7610-3-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 6522d3d55687efc94e9e276ed657daf3a7a7543a Author: Eric W. Biederman Date: Sat Aug 15 20:27:13 2015 -0500 vfs: Test for and handle paths that are unreachable from their mnt_root commit 397d425dc26da728396e66d392d5dcb8dac30c37 upstream. In rare cases a directory can be renamed out from under a bind mount. In those cases without special handling it becomes possible to walk up the directory tree to the root dentry of the filesystem and down from the root dentry to every other file or directory on the filesystem. Like division by zero .. from an unconnected path can not be given a useful semantic as there is no predicting at which path component the code will realize it is unconnected. We certainly can not match the current behavior as the current behavior is a security hole. Therefore when encounting .. when following an unconnected path return -ENOENT. - Add a function path_connected to verify path->dentry is reachable from path->mnt.mnt_root. AKA to validate that rename did not do something nasty to the bind mount. To avoid races path_connected must be called after following a path component to it's next path component. Signed-off-by: "Eric W. Biederman" Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit e47bf8170acc88ad29627d8e42757d7d6ae56611 Author: Eric W. Biederman Date: Sat Aug 15 13:36:12 2015 -0500 dcache: Handle escaped paths in prepend_path commit cde93be45a8a90d8c264c776fab63487b5038a65 upstream. A rename can result in a dentry that by walking up d_parent will never reach it's mnt_root. For lack of a better term I call this an escaped path. prepend_path is called by four different functions __d_path, d_absolute_path, d_path, and getcwd. __d_path only wants to see paths are connected to the root it passes in. So __d_path needs prepend_path to return an error. d_absolute_path similarly wants to see paths that are connected to some root. Escaped paths are not connected to any mnt_root so d_absolute_path needs prepend_path to return an error greater than 1. So escaped paths will be treated like paths on lazily unmounted mounts. getcwd needs to prepend "(unreachable)" so getcwd also needs prepend_path to return an error. d_path is the interesting hold out. d_path just wants to print something, and does not care about the weird cases. Which raises the question what should be printed? Given that / should result in -ENOENT I believe it is desirable for escaped paths to be printed as empty paths. As there are not really any meaninful path components when considered from the perspective of a mount tree. So tweak prepend_path to return an empty path with an new error code of 3 when it encounters an escaped path. Signed-off-by: "Eric W. Biederman" Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit a95e67a71e135bbbfaac89941f351843971927bc Author: Chaotian Jing Date: Wed Sep 30 17:37:18 2015 +0800 mmc: core: fix dead loop of mmc_retune commit 031277d4d33d33f0174fbb569ca8f68238175617 upstream. When get a CRC error, start the mmc_retune, it will issue CMD19/CMD21 to do tune, assume there were 10 clock phase need to try, phase 0 to phase 6 is ok, phase 7 to phase 9 is NG, we try it from 0 to 9, so the last CMD19/CMD21 will get CRC error, host->need_retune was set and cause mmc_retune was called, then dead loop of mmc_retune Signed-off-by: Chaotian Jing Acked-by: Adrian Hunter Fixes: bd11e8bd03ca ("mmc: core: Flag re-tuning is needed on CRC errors") Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 31eea56030431c1b160f103cb69033ba94489cb2 Author: Ulf Hansson Date: Mon Sep 14 12:18:55 2015 +0200 mmc: core: Don't return an error for CD/WP GPIOs when GPIOLIB is unset commit 43934ece2ea72c1dd279c0b0478c1a036d5d77ee upstream. When CONFIG_GPIOLIB is unset, its stubs will return -ENOSYS. That means when the mmc core parses DT for CD/WP GPIOs via mmc_of_parse(), -ENOSYS becomes propagated to the caller. Typically this means that the mmc host driver fails to probe. As the CD/WP GPIOs are already treated as optional, let's extend that to cover the case when CONFIG_GPIOLIB is unset. Reported-by: Michal Simek Fixes: 16b23787fc70 ("mmc: sdhci-of-arasan: Call OF parsing for MMC") Signed-off-by: Ulf Hansson Tested-by: Michal Simek Acked-by: Venu Byravarasu Signed-off-by: Greg Kroah-Hartman commit 145ba5987d5f093a4a0d1d94cd2923501cf05307 Author: Nicholas Bellinger Date: Tue Sep 22 22:32:14 2015 -0700 iscsi-target: Avoid OFMarker + IFMarker negotiation commit 673681cafa99776e334c3e61cafa2cf115950c32 upstream. This patch fixes a v4.2+ regression introduced by commit c04a6091 that removed support for obsolete sync-and-steering markers usage as originally defined in RFC-3720. The regression would involve attempting to send OFMarker=No + IFMarker=No keys during opertional negotiation login phase, including when initiators did not actually propose these keys. The result for MSFT iSCSI initiators would be random junk in TCP stream after the last successful login request was been sent signaling the move to full feature phase (FFP) operation. To address this bug, go ahead and avoid negotiating these keys by default unless the initiator explicitly proposes them, but still respond to them with 'No' if they are proposed. Reported-by: Dragan Milivojević Bisected-by: Christophe Vu-Brugier Tested-by: Christophe Vu-Brugier Signed-off-by: Nicholas Bellinger Cc: Andy Grover Signed-off-by: Greg Kroah-Hartman commit a885e8bb14fd6de92c98ff27a254c1270d977508 Author: Sudip Mukherjee Date: Thu Sep 24 15:46:53 2015 +0530 net: via/Kconfig: GENERIC_PCI_IOMAP required if PCI not selected commit 21343ac21ec7d871e94e98e288f3398a4207d9c0 upstream. The builds of allmodconfig of avr32 is failing with: drivers/net/ethernet/via/via-rhine.c:1098:2: error: implicit declaration of function 'pci_iomap' [-Werror=implicit-function-declaration] drivers/net/ethernet/via/via-rhine.c:1119:2: error: implicit declaration of function 'pci_iounmap' [-Werror=implicit-function-declaration] The generic empty pci_iomap and pci_iounmap is used only if CONFIG_PCI is not defined and CONFIG_GENERIC_PCI_IOMAP is defined. Add GENERIC_PCI_IOMAP in the dependency list for VIA_RHINE as we are getting build failure when CONFIG_PCI and CONFIG_GENERIC_PCI_IOMAP both are not defined. Signed-off-by: Sudip Mukherjee Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 40396228e70d47f7024ec005eec87fffe8e8633e Author: shengyong Date: Mon Sep 28 17:57:19 2015 +0000 UBI: return ENOSPC if no enough space available commit 7c7feb2ebfc9c0552c51f0c050db1d1a004faac5 upstream. UBI: attaching mtd1 to ubi0 UBI: scanning is finished UBI error: init_volumes: not enough PEBs, required 706, available 686 UBI error: ubi_wl_init: no enough physical eraseblocks (-20, need 1) UBI error: ubi_attach_mtd_dev: failed to attach mtd1, error -12 <= NOT ENOMEM UBI error: ubi_init: cannot attach mtd1 If available PEBs are not enough when initializing volumes, return -ENOSPC directly. If available PEBs are not enough when initializing WL, return -ENOSPC instead of -ENOMEM. Signed-off-by: Sheng Yong Signed-off-by: Richard Weinberger Reviewed-by: David Gstir Signed-off-by: Greg Kroah-Hartman commit fc4337962e4d27410acc27a77d962d823a24aff6 Author: Richard Weinberger Date: Tue Sep 22 23:58:07 2015 +0200 UBI: Validate data_size commit 281fda27673f833a01d516658a64d22a32c8e072 upstream. Make sure that data_size is less than LEB size. Otherwise a handcrafted UBI image is able to trigger an out of bounds memory access in ubi_compare_lebs(). Signed-off-by: Richard Weinberger Reviewed-by: David Gstir Signed-off-by: Greg Kroah-Hartman commit b8e759b6839ac3595d958fdb61828f7fb9066f49 Author: Richard Weinberger Date: Wed Jul 8 11:46:36 2015 +0200 UBIFS: Kill unneeded locking in ubifs_init_security commit cf6f54e3f133229f02a90c04fe0ff9dd9d3264b4 upstream. Fixes the following lockdep splat: [ 1.244527] ============================================= [ 1.245193] [ INFO: possible recursive locking detected ] [ 1.245193] 4.2.0-rc1+ #37 Not tainted [ 1.245193] --------------------------------------------- [ 1.245193] cp/742 is trying to acquire lock: [ 1.245193] (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [] ubifs_init_security+0x29/0xb0 [ 1.245193] [ 1.245193] but task is already holding lock: [ 1.245193] (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [] path_openat+0x3af/0x1280 [ 1.245193] [ 1.245193] other info that might help us debug this: [ 1.245193] Possible unsafe locking scenario: [ 1.245193] [ 1.245193] CPU0 [ 1.245193] ---- [ 1.245193] lock(&sb->s_type->i_mutex_key#9); [ 1.245193] lock(&sb->s_type->i_mutex_key#9); [ 1.245193] [ 1.245193] *** DEADLOCK *** [ 1.245193] [ 1.245193] May be due to missing lock nesting notation [ 1.245193] [ 1.245193] 2 locks held by cp/742: [ 1.245193] #0: (sb_writers#5){.+.+.+}, at: [] mnt_want_write+0x1f/0x50 [ 1.245193] #1: (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [] path_openat+0x3af/0x1280 [ 1.245193] [ 1.245193] stack backtrace: [ 1.245193] CPU: 2 PID: 742 Comm: cp Not tainted 4.2.0-rc1+ #37 [ 1.245193] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140816_022509-build35 04/01/2014 [ 1.245193] ffffffff8252d530 ffff88007b023a38 ffffffff814f6f49 ffffffff810b56c5 [ 1.245193] ffff88007c30cc80 ffff88007b023af8 ffffffff810a150d ffff88007b023a68 [ 1.245193] 000000008101302a ffff880000000000 00000008f447e23f ffffffff8252d500 [ 1.245193] Call Trace: [ 1.245193] [] dump_stack+0x4c/0x65 [ 1.245193] [] ? console_unlock+0x1c5/0x510 [ 1.245193] [] __lock_acquire+0x1a6d/0x1ea0 [ 1.245193] [] ? __lock_is_held+0x58/0x80 [ 1.245193] [] lock_acquire+0xd3/0x270 [ 1.245193] [] ? ubifs_init_security+0x29/0xb0 [ 1.245193] [] mutex_lock_nested+0x6b/0x3a0 [ 1.245193] [] ? ubifs_init_security+0x29/0xb0 [ 1.245193] [] ? ubifs_init_security+0x29/0xb0 [ 1.245193] [] ubifs_init_security+0x29/0xb0 [ 1.245193] [] ubifs_create+0xa6/0x1f0 [ 1.245193] [] ? path_openat+0x3af/0x1280 [ 1.245193] [] vfs_create+0x95/0xc0 [ 1.245193] [] path_openat+0x7cc/0x1280 [ 1.245193] [] ? __lock_acquire+0x543/0x1ea0 [ 1.245193] [] ? sched_clock_cpu+0x90/0xc0 [ 1.245193] [] ? calc_global_load_tick+0x60/0x90 [ 1.245193] [] ? sched_clock_cpu+0x90/0xc0 [ 1.245193] [] ? __alloc_fd+0xaf/0x180 [ 1.245193] [] do_filp_open+0x75/0xd0 [ 1.245193] [] ? _raw_spin_unlock+0x26/0x40 [ 1.245193] [] ? __alloc_fd+0xaf/0x180 [ 1.245193] [] do_sys_open+0x129/0x200 [ 1.245193] [] SyS_open+0x19/0x20 [ 1.245193] [] entry_SYSCALL_64_fastpath+0x12/0x6f While the lockdep splat is a false positive, becuase path_openat holds i_mutex of the parent directory and ubifs_init_security() tries to acquire i_mutex of a new inode, it reveals that taking i_mutex in ubifs_init_security() is in vain because it is only being called in the inode allocation path and therefore nobody else can see the inode yet. Reported-and-tested-by: Boris Brezillon Reviewed-and-tested-by: Dongsheng Yang Signed-off-by: Richard Weinberger Signed-off-by: dedekind1@gmail.com Signed-off-by: Greg Kroah-Hartman commit f7e8cdc50bc95200a1bc643c3bb5358bf1d923f5 Author: Christian Engelmayer Date: Fri Aug 21 23:14:26 2015 +0200 rsi: Fix possible leak when loading firmware commit a8b9774571d46506a0774b1ced3493b1245cf893 upstream. Commit 5d5cd85ff441 ("rsi: Fix failure to load firmware after memory leak fix and fix the leak") also added a check on the allocation of DMA-accessible memory that may directly return. In that case the already allocated firmware data is leaked. Make sure the data is always freed correctly. Detected by Coverity CID 1316519. Fixes: 5d5cd85ff441 ("rsi: Fix failure to load firmware after memory leak fix and fix the leak") Signed-off-by: Christian Engelmayer Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit f4cbe79f341ca8efe368edab89523b84bb8c0c93 Author: Paul Mackerras Date: Thu Sep 10 14:36:21 2015 +1000 powerpc/MSI: Fix race condition in tearing down MSI interrupts commit e297c939b745e420ef0b9dc989cb87bda617b399 upstream. This fixes a race which can result in the same virtual IRQ number being assigned to two different MSI interrupts. The most visible consequence of that is usually a warning and stack trace from the sysfs code about an attempt to create a duplicate entry in sysfs. The race happens when one CPU (say CPU 0) is disposing of an MSI while another CPU (say CPU 1) is setting up an MSI. CPU 0 calls (for example) pnv_teardown_msi_irqs(), which calls msi_bitmap_free_hwirqs() to indicate that the MSI (i.e. its hardware IRQ number) is no longer in use. Then, before CPU 0 gets to calling irq_dispose_mapping() to free up the virtal IRQ number, CPU 1 comes in and calls msi_bitmap_alloc_hwirqs() to allocate an MSI, and gets the same hardware IRQ number that CPU 0 just freed. CPU 1 then calls irq_create_mapping() to get a virtual IRQ number, which sees that there is currently a mapping for that hardware IRQ number and returns the corresponding virtual IRQ number (which is the same virtual IRQ number that CPU 0 was using). CPU 0 then calls irq_dispose_mapping() and frees that virtual IRQ number. Now, if another CPU comes along and calls irq_create_mapping(), it is likely to get the virtual IRQ number that was just freed, resulting in the same virtual IRQ number apparently being used for two different hardware interrupts. To fix this race, we just move the call to msi_bitmap_free_hwirqs() to after the call to irq_dispose_mapping(). Since virq_to_hw() doesn't work for the virtual IRQ number after irq_dispose_mapping() has been called, we need to call it before irq_dispose_mapping() and remember the result for the msi_bitmap_free_hwirqs() call. The pattern of calling msi_bitmap_free_hwirqs() before irq_dispose_mapping() appears in 5 places under arch/powerpc, and appears to have originated in commit 05af7bd2d75e ("[POWERPC] MPIC U3/U4 MSI backend") from 2007. Fixes: 05af7bd2d75e ("[POWERPC] MPIC U3/U4 MSI backend") Reported-by: Alexey Kardashevskiy Signed-off-by: Paul Mackerras Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 607877baeece2448dad81a44c5d03cc48ffb0b46 Author: Kapileshwar Singh Date: Tue Sep 22 14:22:03 2015 +0100 tools lib traceevent: Fix string handling in heterogeneous arch environments commit c2e4b24ff848bb180f9b9cd873a38327cd219ad2 upstream. When a trace recorded on a 32-bit device is processed with a 64-bit binary, the higher 32-bits of the address need to ignored. The lack of this results in the output of the 64-bit pointer value to the trace as the 32-bit address lookup fails in find_printk(). Before: burn-1778 [003] 548.600305: bputs: 0xc0046db2s: 2cec5c058d98c After: burn-1778 [003] 548.600305: bputs: 0xc0046db2s: RT throttling activated The problem occurs in PRINT_FIELD when the field is recognized as a pointer to a string (of the type const char *) Heterogeneous architectures cases below can arise and should be handled: * Traces recorded using 32-bit addresses processed on a 64-bit machine * Traces recorded using 64-bit addresses processed on a 32-bit machine Reported-by: Juri Lelli Signed-off-by: Kapileshwar Singh Reviewed-by: Steven Rostedt Cc: David Ahern Cc: Javi Merino Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lkml.kernel.org/r/1442928123-13824-1-git-send-email-kapileshwar.singh@arm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit c79c3ece176b0d532a06ff2ce2426b3e1631277d Author: Linus Lüssing Date: Tue Jun 30 23:45:26 2015 +0200 batman-adv: Fix potentially broken skb network header access commit 53cf037bf846417fd92dc92ddf97267f69b110f4 upstream. The two commits noted below added calls to ip_hdr() and ipv6_hdr(). They need a correctly set skb network header. Unfortunately we cannot rely on the device drivers to set it for us. Therefore setting it in the beginning of the according ndo_start_xmit handler. Fixes: 1d8ab8d3c176 ("batman-adv: Modified forwarding behaviour for multicast packets") Fixes: ab49886e3da7 ("batman-adv: Add IPv4 link-local/IPv6-ll-all-nodes multicast support") Signed-off-by: Linus Lüssing Signed-off-by: Marek Lindner Signed-off-by: Antonio Quartulli Signed-off-by: Greg Kroah-Hartman commit 897b938a239a9d7f4820205bfb8d4650f250e828 Author: Linus Lüssing Date: Tue Jun 16 17:10:26 2015 +0200 batman-adv: Fix potential synchronization issues in mcast tvlv handler commit 8a4023c5b5e30b11f1f383186f4a7222b3b823cf upstream. So far the mcast tvlv handler did not anticipate the processing of multiple incoming OGMs from the same originator at the same time. This can lead to various issues: * Broken refcounting: For instance two mcast handlers might both assume that an originator just got multicast capabilities and will together wrongly decrease mcast.num_disabled by two, potentially leading to an integer underflow. * Potential kernel panic on hlist_del_rcu(): Two mcast handlers might one after another try to do an hlist_del_rcu(&orig->mcast_want_all_*_node). The second one will cause memory corruption / crashes. (Reported by: Sven Eckelmann ) Right in the beginning the code path makes assumptions about the current multicast related state of an originator and bases all updates on that. The easiest and least error prune way to fix the issues in this case is to serialize multiple mcast handler invocations with a spinlock. Fixes: 60432d756cf0 ("batman-adv: Announce new capability via multicast TVLV") Signed-off-by: Linus Lüssing Signed-off-by: Marek Lindner Signed-off-by: Antonio Quartulli Signed-off-by: Greg Kroah-Hartman commit b727c45c545b971f71612b544cea66ce7ab7a102 Author: Linus Lüssing Date: Tue Jun 16 17:10:25 2015 +0200 batman-adv: Make MCAST capability changes atomic commit 9c936e3f4c4fad07abb6c082a89508b8f724c88f upstream. Bitwise OR/AND assignments in C aren't guaranteed to be atomic. One OGM handler might undo the set/clear of a specific bit from another handler run in between. Fix this by using the atomic set_bit()/clear_bit()/test_bit() functions. Fixes: 60432d756cf0 ("batman-adv: Announce new capability via multicast TVLV") Signed-off-by: Linus Lüssing Signed-off-by: Marek Lindner Signed-off-by: Antonio Quartulli Signed-off-by: Greg Kroah-Hartman commit c3e23f23c566dfa2d3dcd0f172973729e0838090 Author: Linus Lüssing Date: Tue Jun 16 17:10:24 2015 +0200 batman-adv: Make TT capability changes atomic commit ac4eebd48461ec993e7cb614d5afe7df8c72e6b7 upstream. Bitwise OR/AND assignments in C aren't guaranteed to be atomic. One OGM handler might undo the set/clear of a specific bit from another handler run in between. Fix this by using the atomic set_bit()/clear_bit()/test_bit() functions. Fixes: e17931d1a61d ("batman-adv: introduce capability initialization bitfield") Signed-off-by: Linus Lüssing Signed-off-by: Marek Lindner Signed-off-by: Antonio Quartulli Signed-off-by: Greg Kroah-Hartman commit 1c9f71eb86dd5f95315f2d7269fad36ced13ed60 Author: Linus Lüssing Date: Tue Jun 16 17:10:23 2015 +0200 batman-adv: Make NC capability changes atomic commit 4635469f5c617282f18c69643af36cd8c0acf707 upstream. Bitwise OR/AND assignments in C aren't guaranteed to be atomic. One OGM handler might undo the set/clear of a specific bit from another handler run in between. Fix this by using the atomic set_bit()/clear_bit()/test_bit() functions. Fixes: 3f4841ffb336 ("batman-adv: tvlv - add network coding container") Signed-off-by: Linus Lüssing Signed-off-by: Marek Lindner Signed-off-by: Antonio Quartulli Signed-off-by: Greg Kroah-Hartman commit 6990e8ca4541cd46bc5cf820953d115d37132f4e Author: Paul Burton Date: Wed Aug 5 15:42:38 2015 -0700 MIPS: CPS: #ifdef on CONFIG_MIPS_MT_SMP rather than CONFIG_MIPS_MT commit 7a63076d9a31a6c2073da45021eeb4f89d2a8b56 upstream. The CONFIG_MIPS_MT symbol can be selected by CONFIG_MIPS_VPE_LOADER in addition to CONFIG_MIPS_MT_SMP. We only want MT code in the CPS SMP boot vector if we're using MT for SMP. Thus switch the config symbol we ifdef against to CONFIG_MIPS_MT_SMP. Signed-off-by: Paul Burton Cc: Markos Chandras Cc: James Hogan Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10867/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 6d36892bacaaca3ae450a298ec6eab72a945e62b Author: Paul Burton Date: Wed Aug 5 15:42:37 2015 -0700 MIPS: CPS: Don't include MT code in non-MT kernels. commit a5b0f6db0e6cf6224e50f6585e9c8f0c2d38a8f8 upstream. The MT-specific code in mips_cps_boot_vpes can safely be omitted from kernels which don't support MT, with the default VPE==0 case being used as it would be after the has_mt (Config3.MT) check failed at runtime. Discarding the code entirely will save us a few bytes & allow cleaner handling of MT ASE instructions by later patches. Signed-off-by: Paul Burton Cc: Markos Chandras Cc: James Hogan Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10866/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit c497787e89c9b0689259d2b9e84a7b518a29a6e0 Author: Paul Burton Date: Wed Aug 5 15:42:36 2015 -0700 MIPS: CPS: Stop dangling delay slot from has_mt. commit 1e5fb282f8eda889776ee83f9214d5df9edaa26d upstream. The has_mt macro ended with a branch, leaving its callers with a delay slot that would be executed if Config3.MT is not set. However it would not be executed if Config3 (or earlier Config registers) don't exist which makes it somewhat inconsistent at best. Fill the delay slot in the macro & fix the mips_cps_boot_vpes caller appropriately. Signed-off-by: Paul Burton Cc: Markos Chandras Cc: James Hogan Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10865/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit c642638ffc41c80a7a53f7f0e559d2956f18b2ed Author: James Hogan Date: Fri Mar 27 08:33:43 2015 +0000 MIPS: dma-default: Fix 32-bit fall back to GFP_DMA commit 53960059d56ecef67d4ddd546731623641a3d2d1 upstream. If there is a DMA zone (usually 24bit = 16MB I believe), but no DMA32 zone, as is the case for some 32-bit kernels, then massage_gfp_flags() will cause DMA memory allocated for devices with a 32..63-bit coherent_dma_mask to fall back to using __GFP_DMA, even though there may only be 32-bits of physical address available anyway. Correct that case to compare against a mask the size of phys_addr_t instead of always using a 64-bit mask. Signed-off-by: James Hogan Fixes: a2e715a86c6d ("MIPS: DMA: Fix computation of DMA flags from device's coherent_dma_mask.") Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9610/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 49d72e5c9ad8fb7a0ddd5e48bcf5ae91e22712c9 Author: Aurelien Jarno Date: Sat Sep 5 18:46:57 2015 +0200 MIPS: BPF: Fix build on pre-R2 little endian CPUs commit b259e51f2e29390518021f9b8df55a3de42f371b upstream. The rotr, seh and wsbh instructions have been introduced with the R2 ISA. Thus the current BPF code fails to build on pre-R2 little endian CPUs: CC arch/mips/net/bpf_jit.o AS arch/mips/net/bpf_jit_asm.o /home/aurel32/linux-4.2/arch/mips/net/bpf_jit_asm.S: Assembler messages: /home/aurel32/linux-4.2/arch/mips/net/bpf_jit_asm.S:67: Error: opcode not supported on this processor: mips32 (mips32) `wsbh $8,$19' /home/aurel32/linux-4.2/arch/mips/net/bpf_jit_asm.S:68: Error: opcode not supported on this processor: mips32 (mips32) `rotr $19,$8,16' /home/aurel32/linux-4.2/arch/mips/net/bpf_jit_asm.S:83: Error: opcode not supported on this processor: mips32 (mips32) `wsbh $8,$19' /home/aurel32/linux-4.2/arch/mips/net/bpf_jit_asm.S:84: Error: opcode not supported on this processor: mips32 (mips32) `seh $19,$8' /home/aurel32/linux-4.2/arch/mips/net/bpf_jit_asm.S:151: Error: opcode not supported on this processor: mips32 (mips32) `wsbh $8,$12' /home/aurel32/linux-4.2/arch/mips/net/bpf_jit_asm.S:153: Error: opcode not supported on this processor: mips32 (mips32) `rotr $19,$8,16' /home/aurel32/linux-4.2/arch/mips/net/bpf_jit_asm.S:164: Error: opcode not supported on this processor: mips32 (mips32) `wsbh $19,$12' /home/aurel32/linux-4.2/scripts/Makefile.build:294: recipe for target 'arch/mips/net/bpf_jit_asm.o' failed Fix that by providing equivalent code for these CPUs. Signed-off-by: Aurelien Jarno Reviewed-by: Markos Chandras Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/11098/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 35622da74e01150c509a72ff6d37352f3d53d47a Author: Aurelien Jarno Date: Sat Sep 5 18:46:56 2015 +0200 MIPS: BPF: Avoid unreachable code on little endian commit faa9724a674e5e52316bb0d173aed16bd17d536c upstream. On little endian, avoid generating the big endian version of the code by using #else in addition to #ifdef #endif. Also fix one alignment issue wrt delay slot. Signed-off-by: Aurelien Jarno Reviewed-by: Markos Chandras Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/11097/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 649f2beb1a02efad0cb5871fb6e89cebcb405ee0 Author: Alexander Sverdlin Date: Thu Sep 3 08:36:35 2015 +0200 MIPS: bootmem: Fix mapstart calculation for contiguous maps commit 88d3426942d748b90b051b7ef2d5d765f5f3054c upstream. Commit a6335fa1 fixed the case with gap between initrd and next usable PFN zone, but broken the case when initrd is combined with usable memory into one region (in add_memory_region()). Restore the fixup initially brought in by f9a7febd. ---- error message ---- Unpacking initramfs... Initramfs unpacking failed: junk in compressed archive BUG: Bad page state in process swapper pfn:00261 page:81004c20 count:0 mapcount:-127 mapping: (null) index:0x2 flags: 0x0() page dumped because: nonzero mapcount CPU: 0 PID: 1 Comm: swapper Not tainted 4.2.0+ #1782 ----------------------- Signed-off-by: Alexander Sverdlin Reported-by: Tony Wu Tested-by: Tony Wu Cc: David Daney Cc: Zubair Lutfullah Kakakhel Cc: Huacai Chen Cc: Joe Perches Cc: Steven J. Hill Cc: Aaro Koskinen Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/11086/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit b7cce4648f2970cb1134cf723744cfe56c0e7343 Author: Guenter Roeck Date: Sun Aug 30 21:19:58 2015 -0700 MIPS: Fix console output for Fulong2e system commit fc2ca674470bbfe11d72a20a3f19fd3dc43bfca0 upstream. Commit 3adeb2566b9b ("MIPS: Loongson: Improve LEFI firmware interface") made the number of UARTs dynamic if LEFI_FIRMWARE_INTERFACE is configured. Unfortunately, it did not initialize the number of UARTs if LEFI_FIRMWARE_INTERFACE is not configured. As a result, the Fulong2e system has no console. Fixes: 3adeb2566b9b ("MIPS: Loongson: Improve LEFI firmware interface") Acked-by: Huacai Chen Signed-off-by: Guenter Roeck Tested-by: Markos Chandras Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/11076/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 891aa8f203372989ae10335f592ac2c794daab12 Author: Viresh Kumar Date: Wed Sep 2 14:36:50 2015 +0530 cpufreq: dt: Tolerance applies on both sides of target voltage commit a2022001cebd0825b96aa0f3345ea3ad44ae79d4 upstream. Tolerance applies on both sides of the target voltage, i.e. both min and max sides. But while checking if a voltage is supported by the regulator or not, we haven't taken care of tolerance on the lower side. Fix that. Cc: Lucas Stach Fixes: 045ee45c4ff2 ("cpufreq: cpufreq-dt: disable unsupported OPPs") Signed-off-by: Viresh Kumar Reviewed-by: Lucas Stach Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit ee2a52fc66229e0cd6213809bbba527759517ddf Author: Borislav Petkov Date: Sat Aug 8 10:46:02 2015 +0200 cpu/cacheinfo: Fix teardown path commit 2110d70c5e58326a10e93cfefdc0b3686e2ada12 upstream. Philip Müller reported a hang when booting 32-bit 4.1 kernel on an AMD box. A fragment of the splat was enough to pinpoint the issue: task: f58e0000 ti: f58e8000 task.ti: f58e800 EIP: 0060:[] EFLAGS: 00010206 CPU: 0 EIP is at free_cache_attributes+0x83/0xd0 EAX: 00000001 EBX: f589d46c ECX: 00000090 EDX: 360c2000 ESI: 00000000 EDI: c1724a80 EBP: f58e9ec0 ESP: f58e9ea0 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 CR0: 8005003b CR2: 000000ac CR3: 01731000 CR4: 000006d0 cache_shared_cpu_map_setup() did check sibling CPUs cacheinfo descriptor while the respective teardown path cache_shared_cpu_map_remove() didn't. Fix that. >From tglx's version: to be on the safe side, move the cacheinfo descriptor check to free_cache_attributes(), thus cleaning up the hotplug path a little and making this even more robust. Reported-and-tested-by: Philip Müller Reviewed-by: Thomas Gleixner Acked-by: Sudeep Holla Cc: Andre Przywara Cc: Guenter Roeck Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: linux-kernel@vger.kernel.org Cc: manjaro-dev@manjaro.org Cc: Philip Müller Link: https://lkml.kernel.org/r/55B47BB8.6080202@manjaro.org Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit edbee2c729e3d739242467e7cbf574bd21b6656c Author: Thomas Petazzoni Date: Fri Sep 18 17:25:36 2015 +0200 crypto: marvell - properly handle CRYPTO_TFM_REQ_MAY_BACKLOG-flagged requests commit cfcd2271a9076a9891014bc8e18d4fd48acccffe upstream. The mv_cesa_queue_req() function calls crypto_enqueue_request() to enqueue a request. In the normal case (i.e the queue isn't full), this function returns -EINPROGRESS. The current Marvell CESA crypto driver takes this into account and cleans up the request only if an error occured, i.e if the return value is not -EINPROGRESS. Unfortunately this causes problems with CRYPTO_TFM_REQ_MAY_BACKLOG-flagged requests. When such a request is passed to crypto_enqueue_request() and the queue is full, crypto_enqueue_request() will return -EBUSY, but will keep the request enqueued nonetheless. This situation was not properly handled by the Marvell CESA driver, which was anyway cleaning up the request in such a situation. When later on the request was taken out of the backlog and actually processed, a kernel crash occured due to the internal driver data structures for this structure having been cleaned up. To avoid this situation, this commit adds a mv_cesa_req_needs_cleanup() helper function which indicates if the request needs to be cleaned up or not after a call to crypto_enqueue_request(). This helper allows to do the cleanup only in the appropriate cases, and all call sites of mv_cesa_queue_req() are fixed to use this new helper function. Reported-by: Vincent Donnefort Fixes: db509a45339fd ("crypto: marvell/cesa - add TDMA support") Signed-off-by: Thomas Petazzoni Acked-by: Boris Brezillon Tested-by: Vincent Donnefort Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 730cfb7b1c5593654372461534db264414ca2fa6 Author: Yao-Wen Mao Date: Mon Aug 31 14:24:09 2015 +0800 USB: Add reset-resume quirk for two Plantronics usb headphones. commit 8484bf2981b3d006426ac052a3642c9ce1d8d980 upstream. These two headphones need a reset-resume quirk to properly resume to original volume level. Signed-off-by: Yao-Wen Mao Signed-off-by: Greg Kroah-Hartman commit ad4327fe2a4484b9712d71aa20c4184739ded5a8 Author: Vincent Palatin Date: Thu Oct 1 14:10:22 2015 -0700 usb: Add device quirk for Logitech PTZ cameras commit 72194739f54607bbf8cfded159627a2015381557 upstream. Add a device quirk for the Logitech PTZ Pro Camera and its sibling the ConferenceCam CC3000e Camera. This fixes the failed camera enumeration on some boot, particularly on machines with fast CPU. Tested by connecting a Logitech PTZ Pro Camera to a machine with a Haswell Core i7-4600U CPU @ 2.10GHz, and doing thousands of reboot cycles while recording the kernel logs and taking camera picture after each boot. Before the patch, more than 7% of the boots show some enumeration transfer failures and in a few of them, the kernel is giving up before actually enumerating the webcam. After the patch, the enumeration has been correct on every reboot. Signed-off-by: Vincent Palatin Signed-off-by: Greg Kroah-Hartman commit e542cd0ad273af24f0a220c09b47523e681dc0e7 Author: Alexander Inyukhin Date: Sat Sep 26 15:24:21 2015 +0300 USB: chaoskey read offset bug commit 1d5c47f555c5ae050fad22e4a99f88856cae5d05 upstream. Rng reads in chaoskey driver could return the same data under the certain conditions. Signed-off-by: Alexander Inyukhin Signed-off-by: Greg Kroah-Hartman commit 8c5a69e5fb303916738cd5f3a26ec97f478154fb Author: Felipe Balbi Date: Thu Aug 6 10:51:29 2015 -0500 usb: musb: cppi41: allow it to work again commit b0a688ddcc5015eb26000c63841db7c46cfb380a upstream. since commit 33c300cb90a6 ("usb: musb: dsps: don't fake of_node to musb core") we have been preventing CPPI 4.1 from probing due to NULL of_node. We can't revert said commit otherwise a different regression would show up, so the fix is to look for the parent device's (glue layer's) of_node instead, since that's the thing which is actually described in DTS. Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit fd2f3edb10119ba000be0b755c97425337ce0fc8 Author: Roger Quadros Date: Thu Aug 13 13:28:42 2015 +0300 usb: phy: phy-generic: Fix reset behaviour on legacy boot commit 762982db33b23029e98c844611e2e8beeb75bc0d upstream. The gpio-desc migration done in v4.0 caused a regression with legacy boots due to reversed reset logic. e.g. omap3-beagle USB host breaks on legacy boot. Request the reset GPIO with GPIOF_ACTIVE_LOW flag so that it matches the driver logic and pin behaviour. Fixes: e9f2cefb0cdc ("usb: phy: generic: migrate to gpio_desc") Tested-by: Fabio Estevam Signed-off-by: Roger Quadros Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit f860bf4416f338a0e22a2265cdfd720e5f5cb0da Author: Mathias Nyman Date: Mon Sep 21 17:46:09 2015 +0300 usb: Use the USB_SS_MULT() macro to get the burst multiplier. commit ff30cbc8da425754e8ab96904db1d295bd034f27 upstream. Bits 1:0 of the bmAttributes are used for the burst multiplier. The rest of the bits used to be reserved (zero), but USB3.1 takes bit 7 into use. Use the existing USB_SS_MULT() macro instead to make sure the mult value and hence max packet calculations are correct for USB3.1 devices. Note that burst multiplier in bmAttributes is zero based and that the USB_SS_MULT() macro adds one. Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 52b0a92d5906aa881471d549fdf293fe3d563ef4 Author: Peter Chen Date: Mon Aug 24 14:10:07 2015 +0800 usb: chipidea: udc: using the correct stall implementation commit 56ffa1d154c7e12af16273f0cdc42690dd05caf5 upstream. According to spec, there are functional and protocol stalls. For functional stall, it is for bulk and interrupt endpoints, below are cases for it: - Host sends SET_FEATURE request for Set-Halt, the udc driver needs to set stall, and return true unconditionally. - The gadget driver may call usb_ep_set_halt to stall certain endpoints, if there is a transfer in pending, the udc driver should not set stall, and return -EAGAIN accordingly. These two kinds of stall need to be cleared by host using CLEAR_FEATURE request (Clear-Halt). For protocol stall, it is for control endpoint, this stall will be set if the control request has failed. This stall will be cleared by next setup request (hardware will do it). It fixed usbtest (drivers/usb/misc/usbtest.c) Test 13 "set/clear halt" test failure, meanwhile, this change has been verified by USB2 CV Compliance Test and MSC Tests. Cc: Alan Stern Cc: Felipe Balbi Signed-off-by: Peter Chen Signed-off-by: Greg Kroah-Hartman commit a0a74dced8b46210a838a7d5f6ce18c9da58561d Author: Bin Liu Date: Wed Sep 16 14:49:28 2015 -0500 usb: musb: dsps: fix polling in device-only mode commit b8239dcc03afbd0886c1d9b91ba8fee7c6c9a6cb upstream. Fix the regression caused by commit ad78c918602 ("usb: musb: dsps: just start polling already") which causes polling the ID pin status even in device-only mode. Fixes: ad78c918602c ("usb: musb: dsps: just start polling already") Signed-off-by: Bin Liu Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit e716af1ed89ba0a44094e149939810dca2172226 Author: Jann Horn Date: Fri Sep 18 23:41:23 2015 +0200 security: fix typo in security_task_prctl commit b7f76ea2ef6739ee484a165ffbac98deb855d3d3 upstream. Signed-off-by: Jann Horn Reviewed-by: Andy Lutomirski Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f00eadd34d9f1392daa6a014f72b9296a242a95e Author: Mark Brown Date: Sat Sep 19 07:12:34 2015 -0700 regmap: debugfs: Don't bother actually printing when calculating max length commit 176fc2d5770a0990eebff903ba680d2edd32e718 upstream. The in kernel snprintf() will conveniently return the actual length of the printed string even if not given an output beffer at all so just do that rather than relying on the user to pass in a suitable buffer, ensuring that we don't need to worry if the buffer was truncated due to the size of the buffer passed in. Reported-by: Rasmus Villemoes Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 08098bda6e983029027548e16a6e796cefa992dc Author: Mark Brown Date: Sat Sep 19 07:00:18 2015 -0700 regmap: debugfs: Ensure we don't underflow when printing access masks commit b763ec17ac762470eec5be8ebcc43e4f8b2c2b82 upstream. If a read is attempted which is smaller than the line length then we may underflow the subtraction we're doing with the unsigned size_t type so move some of the calculation to be additions on the right hand side instead in order to avoid this. Reported-by: Rasmus Villemoes Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 9b81b02249202bef870f89c98c9b276e06dc2593 Author: Gabriel Krisman Bertazi Date: Wed Aug 19 11:47:06 2015 -0300 ipr: Enable SIS pipe commands for SIS-32 devices. commit e35d7f27fbd51a09a41a5439e39f22a3d102c00b upstream. Remove unnecessary check that disabled SIS pipe commands for SIS-32 devices. This change was sufficient to enable raw mode and send SIS pipe commands for a 57B3 device. Fixes: f8ee25d7d239 ("ipr: AF DASD raw mode implementation in ipr driver") Signed-off-by: Gabriel Krisman Bertazi Reviewed-by: Wen Xiong Acked-by: Brian King Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit bed9e9af90b0a6f758cb0ad8cbfecd198803f242 Author: Russell King Date: Thu Mar 26 10:22:20 2015 +0000 pcmcia: sa11x0: fix missing clk_put() in sa11x0 socket drivers commit 72010aca55264cfe6516a955066c846d3885b0c6 upstream. Fix the lack of clk_put() in sa11xx_base.c's error cleanup paths by converting the driver to the devm_* API. Fixes: 86d88bfca475 ("ARM: 8247/2: pcmcia: sa1100: make use of device clock") Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit ab399803e0894fb758dede3590ebc0adb2179838 Author: Michal Kazior Date: Fri Aug 7 09:08:21 2015 +0200 ath10k: wake up queue upon vif creation commit 6d2d51ecfff13f5f6ffc476dccf4d5b2668072eb upstream. Vif's vdev_id is used as queue number. However due to the tx pausing design in ath10k it was possible for a new interface to be created with its tx queue stopped (via ieee80211_stop_queues). This could in turn leave the interface inoperable until ath10k_mac_tx_unlock() was called. This problem only affected multi-vif scenarios when new interfaces were created some time later after other interfaces have been running for some time and had Tx queue full at some point prior. Possible manifestation of the bug was authentication timeout for a client vif. Fixes: 96d828d45e16 ("ath10k: rework tx queue locking") Signed-off-by: Michal Kazior Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 899ec57d57e8b42d4ca06a4882affceff37de7a0 Author: Michal Kazior Date: Thu Aug 6 14:46:54 2015 +0200 ath10k: wake up offchannel queue properly commit 3a73d1a6f22bf13044056543ad43b2a304ee0022 upstream. Once HTT Tx queue got full offchannel queue was stopped and never woken up again. This broke, e.g. P2P. This could be reproduced after running a lot of traffic enough to saturate 100% of the driver Tx queue and then trying to send offchannel traffic. Fixes: 96d828d45e16 ("ath10k: rework tx queue locking") Signed-off-by: Michal Kazior Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 1efa9c043580217337b19ae285ae9d7208b58a33 Author: Michal Kazior Date: Wed Aug 5 12:15:24 2015 +0200 ath10k: fix peer limit enforcement commit e04cafbc38c70af2aad3810ce24ab0eba8114779 upstream. Firmware peer entries are involved in internal firmware vdev structures. This was not accounted for and could lead firmware to crash due to asking it to do more than it could. Fixes: 039a0051ec1a ("ath10k: allocate fw resources for iface combinations") Signed-off-by: Michal Kazior Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit c2e35fe65305ba982f6b18f0c2d645546290ff5a Author: Michal Kazior Date: Mon Aug 3 11:16:43 2015 +0200 ath10k: reject 11b tx fragmentation configuration commit 92092fe528e79c9bd25784ca0ef341d5a1d1b642 upstream. Even though there's a WMI enum for fragmentation threshold no known firmware actually implements it. Moreover it is not possible to rely frame fragmentation to mac80211 because firmware clears the "more fragments" bit in frame control making it impossible for remote devices to reassemble frames. Hence implement a dummy callback just to say fragmentation isn't supported. This effectively prevents mac80211 from doing frame fragmentation in software. This fixes Tx becoming broken after setting fragmentation threshold. Fixes: 1010ba4c5d1c ("ath10k: unregister and remove frag_threshold callback") Signed-off-by: Michal Kazior Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 690e1a1a400da015f64754dae185903ee3013672 Author: Michal Kazior Date: Thu Jul 9 13:08:38 2015 +0200 ath10k: fix per-vif queue locking commit acd0b27bb13a09dd0a56d4562d3eb4137a7318b2 upstream. Whenever any vdev was supposed to be paused all Tx queues were stopped (except offchannel) instead of only these associated with the given vdev. This caused subtle issues with multi-channel/multi-vif scenarios, e.g. authentication of station vif could sometimes fail depending on fw tx pause request timing. Fixes: b4aa539dd8f2 ("ath10k: implement tx pause wmi event") Signed-off-by: Michal Kazior Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 4fe5efbe4de66c283385dbb08e2adf6b6d60647a Author: Andy Shevchenko Date: Wed Aug 5 16:51:11 2015 +0300 device property: fix potential NULL pointer dereference commit ecc87eed7beeb50c0be0b73322d62135277ea2b0 upstream. In device_add_property_set() we check pset parameter for a NULL, but few lines later we do a pointer arithmetic without check that will crash kernel in the set_secondary_fwnode(). Here we check if pset parameter is NULL and return immediately. Fixes: 16ba08d5c9ec (device property: Introduce firmware node type for platform data) Signed-off-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 8348de5dc44bd911cc7b2e731cc5ec04085cda65 Author: Heiko Stuebner Date: Tue Aug 4 21:36:12 2015 +0200 PM / AVS: rockchip-io: depend on CONFIG_POWER_AVS commit 28c1f1628ee4b163e615eefe1b6463e3d229a873 upstream. The rockchip io-domain driver currently only depends on ARCH_ROCKCHIP itself. This makes it possible to select the power-domain driver, but not the POWER_AVS class and results in the iodomain-driver not getting build in this case. So add the additional dependency, which also results in the driver config option now being placed nicely into the AVS submenu. Fixes: 662a958638bd ("PM / AVS: rockchip-io: add driver handling Rockchip io domains") Signed-off-by: Heiko Stuebner Acked-by: Kevin Hilman Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 98df33308ccb6412a7da6cf9fb2cddf3019523e7 Author: Dan Carpenter Date: Thu Jun 4 17:47:56 2015 +0300 hpsa: fix an sprintf() overflow in the reset handler commit 2dc127bb299d1c7436a08e79193bd0251068356e upstream. The string "cmd %d RESET FAILED, new lockup detected" is not quite large enough so the sprintf() will overflow. I have increased the size of the buffer and also changed the sprintf calls to snprintf. Fixes: 73153fe533bc ('hpsa: use block layer tag for command allocation') Signed-off-by: Dan Carpenter Acked-by: Don Brace Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit e36fb25f74ea3e21280d482a2314be4aac1ea1b0 Author: Boris BREZILLON Date: Mon Sep 14 10:41:03 2015 +0200 mtd: nand: sunxi: fix OOB handling in ->write_xxx() functions commit 03a0e8a7c5ea29b5c4e72dfd64900b47a8fb6f2d upstream. The USER_DATA register cannot be accessed using byte accessors on A13 SoCs, thus triggering a bug when using memcpy_toio on this register. Declare an helper macros to convert an OOB buffer into a suitable USER_DATA value and vice-versa. This patch also fixes an error in the oob_required logic (some OOB data are not written even if the user required it) by removing the oob_required condition, which is perfectly valid since the core already fill ->oob_poi with FFs when oob_required is false. Signed-off-by: Boris Brezillon Fixes: 1fef62c1423b ("mtd: nand: add sunxi NAND flash controller support") Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit a03e4517ee5211298ecd102813ad12ea8b843129 Author: Boris BREZILLON Date: Sun Sep 13 18:14:43 2015 +0200 mtd: nand: sunxi: fix sunxi_nand_chips_cleanup() commit 8e375ccda31ccc73b087134e263c48d2114534f4 upstream. The sunxi_nand_chips_cleanup() function is missing a call to list_del() which generates a double free error. Reported-by: Priit Laes Signed-off-by: Boris Brezillon Fixes: 1fef62c1423b ("mtd: nand: add sunxi NAND flash controller support") Tested-by: Priit Laes Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit 8747171eb44f9f4dc354800a3ff5b64c22182233 Author: Antoine Ténart Date: Tue Aug 18 10:59:10 2015 +0200 mtd: pxa3xx_nand: add a default chunk size commit bc3e00f04cc1fe033a289c2fc2e5c73c0168d360 upstream. When keeping the configuration set by the bootloader (by using the marvell,nand-keep-config property), the pxa3xx_nand_detect_config() function is called and set the chunk size to 512 as a default value if NDCR_PAGE_SZ is not set. In the other case, when not keeping the bootloader configuration, no chunk size is set. Fix this by adding a default chunk size of 512. Fixes: 70ed85232a93 ("mtd: nand: pxa3xx: Introduce multiple page I/O support") Signed-off-by: Antoine Tenart Acked-by: Robert Jarzmik Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit f11d76eb7e8776b64b9fbded9691f694810d5c72 Author: Hans de Goede Date: Mon Aug 24 00:35:36 2015 +0200 extcon: Fix attached value returned by is_extcon_changed commit f4513b065f7dbd37224226ef6e44b09eff742776 upstream. is_extcon_changed should only check the idx-th bit of new, not the entirety of new when setting attached. This fixes extcon sending notifications that a cable was inserted when it gets removed while another cable is still connected. Signed-off-by: Hans de Goede Signed-off-by: Chanwoo Choi Signed-off-by: Greg Kroah-Hartman commit 930c6cd2bd843abf267c833b3164fd760c48066a Author: Dan Carpenter Date: Tue Aug 4 10:47:23 2015 +0300 extcon: Fix signedness bugs about break error handling commit a598af7f0279195abffbfb9bf2070457e9c89ff3 upstream. Unsigned is never less than zero so this error handling won't work. Fixes: be052cc87745 ('extcon: Fix hang and extcon_get/set_cable_state().') Signed-off-by: Dan Carpenter Reviewed-by: Roger Quadros [cw00.choi: Change the patch title and fix signedness bug of find_cable_index_by_id() ] Signed-off-by: Chanwoo Choi Signed-off-by: Greg Kroah-Hartman commit 7f1fd2e4f54b8fc624eb9cf3de6274f80d5793ed Author: Mario Carrillo Date: Mon Aug 24 09:33:09 2015 -0500 docs: update HOWTO for 3.x -> 4.x versioning commit e4144fe5d47c91c92d36cdbd5f31ed8d6e3a57ab upstream. The HOWTO document needed updating for the new kernel versioning. Signed-off-by: Mario Carrillo Signed-off-by: Jonathan Corbet Signed-off-by: Greg Kroah-Hartman commit d0d35c66ec5a3dfff43916735613bd069bb26be6 Author: Marc Zyngier Date: Sun Sep 13 12:14:32 2015 +0100 irqchip/gic-v3-its: Add missing cache flushes commit 5a9a8915c8888b615521b17d70a4342187eae60b upstream. When the ITS is configured for non-cacheable transactions, make sure that the allocated, zeroed memory is flushed to the Point of Coherency, allowing the ITS to observe the zeros instead of random garbage (or even get its own data overwritten by zeros being evicted from the cache...). Fixes: 241a386c7dbb "irqchip: gicv3-its: Use non-cacheable accesses when no shareability" Reported-and-tested-by: Stuart Yoder Signed-off-by: Marc Zyngier Cc: linux-arm-kernel@lists.infradead.org Cc: Pavel Fedin Cc: Jason Cooper Link: http://lkml.kernel.org/r/1442142873-20213-3-git-send-email-marc.zyngier@arm.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit a2d9235f3461f9a35f73b1c5c98fb2ce0a44b2e1 Author: Ludovic Desroches Date: Mon Sep 21 15:46:04 2015 +0200 irqchip/atmel-aic5: Use per chip mask caches in mask/unmask() commit d32dc9aa10c739363c775baf4499416b2e0dc11f upstream. When masking/unmasking interrupts, mask_cache is updated and used later for suspend/resume. Unfortunately, it always was the mask_cache associated with the first irq chip which was updated. So when performing resume, only irqs 0-31 could be enabled. Fixes: b1479ebb7720 ("irqchip: atmel-aic: Add atmel AIC/AIC5 drivers") Signed-off-by: Ludovic Desroches Cc: Cc: Cc: Cc: Cc: Cc: Cc: Cc: Link: http://lkml.kernel.org/r/1442843173-2390-1-git-send-email-ludovic.desroches@atmel.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 4ca3a6e823901b869b71355a1f84f64b9fec15e6 Author: Peter Seiderer Date: Thu Sep 17 21:40:12 2015 +0200 cifs: use server timestamp for ntlmv2 authentication commit 98ce94c8df762d413b3ecb849e2b966b21606d04 upstream. Linux cifs mount with ntlmssp against an Mac OS X (Yosemite 10.10.5) share fails in case the clocks differ more than +/-2h: digest-service: digest-request: od failed with 2 proto=ntlmv2 digest-service: digest-request: kdc failed with -1561745592 proto=ntlmv2 Fix this by (re-)using the given server timestamp for the ntlmv2 authentication (as Windows 7 does). A related problem was also reported earlier by Namjae Jaen (see below): Windows machine has extended security feature which refuse to allow authentication when there is time difference between server time and client time when ntlmv2 negotiation is used. This problem is prevalent in embedded enviornment where system time is set to default 1970. Modern servers send the server timestamp in the TargetInfo Av_Pair structure in the challenge message [see MS-NLMP 2.2.2.1] In [MS-NLMP 3.1.5.1.2] it is explicitly mentioned that the client must use the server provided timestamp if present OR current time if it is not Reported-by: Namjae Jeon Signed-off-by: Peter Seiderer Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit eb4b8cc9c0ce779f0ab999143b4e3d4fff7eb67f Author: Li Jun Date: Wed Sep 16 14:46:32 2015 +0800 usb: chipidea: imx: fix a typo for imx6sx commit 8315b77d72c5f0b18ceb513303d845e73166133c upstream. Use imx6sx instead of imx6sl's platform flags for imx6sx. Fixes: e14db48dfcf3 ("usb: chipidea: imx: add runtime power management support") Signed-off-by: Li Jun Signed-off-by: Peter Chen Signed-off-by: Greg Kroah-Hartman commit c4e3a29030fce89272f080e7e92c162b24103736 Author: Alexey Brodkin Date: Thu Jun 25 11:25:07 2015 +0300 mmc: dw_mmc: handle data blocks > than 4kB if IDMAC is used commit 5959b32e3636f9bfe3f869d1e440bc4a4d660965 upstream. As per DW MobileStorage databook "each descriptor can transfer up to 4kB of data in chained mode", moreover buffer size that is put in "des1" is limited to 13 bits, i.e. for example on attempt to IDMAC_SET_BUFFER1_SIZE(desc, 8192) size value that's effectively written will be 0. On the platform with 8kB PAGE_SIZE I see dw_mmc gets data blocks in SG-list of 8kB size and that leads to unpredictable behavior of the SD/MMC controller. In particular on write to FAT partition of SD-card the controller will stuck in the middle of DMA transaction. Solution to the problem is simple - we need to pass large (> 4kB) data buffers to the controller via multiple descriptors. And that's what that change does. What's interesting I did try original driver on same platform but configured with 4kB PAGE_SIZE and may confirm that data blocks passed in SG-list to dw_mmc never exeed 4kB limit - that explains why nobody ever faced a problem I did. Signed-off-by: Alexey Brodkin Cc: Seungwon Jeon Cc: Jaehoon Chung Cc: Ulf Hansson Cc: arc-linux-dev@synopsys.com Cc: linux-kernel@vger.kernel.org Signed-off-by: Jaehoon Chung Signed-off-by: Greg Kroah-Hartman commit a952d66a2b1eee255018b3e9514b4dde01e77e1f Author: Dan Carpenter Date: Sat Aug 1 16:08:17 2015 -0700 hv: util: checking the wrong variable commit 9dd6a06430c94299651d74b9ed5ca8396ab8ff1f upstream. We don't catch this allocation failure because there is a typo and we check the wrong variable. Fixes: 14b50f80c32d ('Drivers: hv: util: introduce hv_utils_transport abstraction') Signed-off-by: Dan Carpenter Reviewed-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman commit fd4480eec8745c2e6b2d7764df520217f1633912 Author: Javi Merino Date: Mon Aug 17 19:21:43 2015 +0100 thermal: cpu_cooling: free power table on error or when unregistering commit eba4f88d5af84e0fcaa5d6eb4fe35a75c47203cb upstream. The power table is not being freed on error from cpufreq_cooling register or when unregistering. Free it. Fixes: c36cf0717631 ("thermal: cpu_cooling: implement the power cooling device API") Cc: Zhang Rui Cc: Eduardo Valentin Signed-off-by: Javi Merino Signed-off-by: Eduardo Valentin Signed-off-by: Greg Kroah-Hartman commit 333126b347ace518c17ebef5ef18a1a7e6721858 Author: Javi Merino Date: Mon Aug 17 19:21:42 2015 +0100 thermal: cpu_cooling: don't call kcalloc() under rcu_read_lock commit 459ac37506d195713b5e82271a2ac44a777e47df upstream. build_dyn_power_table() allocates the power table while holding rcu_read_lock. kcalloc using GFP_KERNEL may sleep, so it can't be called in an RCU read-side path. Move the rcu protection to the part of the function that really needs it: the part that handles the dev_pm_opp pointer received from dev_pm_opp_find_freq_ceil(). In the unlikely case that there is an OPP added to the cpu while this function is running, return -EAGAIN. Fixes: c36cf0717631 ("thermal: cpu_cooling: implement the power cooling device API") Cc: Zhang Rui Cc: Eduardo Valentin Signed-off-by: Javi Merino Signed-off-by: Eduardo Valentin Signed-off-by: Greg Kroah-Hartman commit d1d7b32a851668a103050e019844db656395ab1a Author: Linus Lüssing Date: Tue Jun 16 17:10:22 2015 +0200 batman-adv: Make DAT capability changes atomic commit 65d7d46050704bcdb8121ddbf4110bfbf2b38baa upstream. Bitwise OR/AND assignments in C aren't guaranteed to be atomic. One OGM handler might undo the set/clear of a specific bit from another handler run in between. Fix this by using the atomic set_bit()/clear_bit()/test_bit() functions. Fixes: 17cf0ea455f1 ("batman-adv: tvlv - add distributed arp table container") Signed-off-by: Linus Lüssing Signed-off-by: Marek Lindner Signed-off-by: Antonio Quartulli Signed-off-by: Greg Kroah-Hartman commit b0fc66ad94f466d36e54fb457560b7040f74742f Author: Linus Torvalds Date: Wed Sep 30 12:48:40 2015 -0400 Initialize msg/shm IPC objects before doing ipc_addid() commit b9a532277938798b53178d5a66af6e2915cb27cf upstream. As reported by Dmitry Vyukov, we really shouldn't do ipc_addid() before having initialized the IPC object state. Yes, we initialize the IPC object in a locked state, but with all the lockless RCU lookup work, that IPC object lock no longer means that the state cannot be seen. We already did this for the IPC semaphore code (see commit e8577d1f0329: "ipc/sem.c: fully initialize sem_array before making it visible") but we clearly forgot about msg and shm. Reported-by: Dmitry Vyukov Cc: Manfred Spraul Cc: Davidlohr Bueso Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit cfc72e39b21aa8ce88df6243ea9cced92f5b9338 Author: Reyad Attiyat Date: Thu Aug 6 19:23:58 2015 +0300 usb: xhci: Add support for URB_ZERO_PACKET to bulk/sg transfers commit 4758dcd19a7d9ba9610b38fecb93f65f56f86346 upstream. This commit checks for the URB_ZERO_PACKET flag and creates an extra zero-length td if the urb transfer length is a multiple of the endpoint's max packet length. Signed-off-by: Reyad Attiyat Signed-off-by: Mathias Nyman Cc: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit ad89cfd0e8aa0599d4c2052cf2e7103a01006521 Author: Mathias Nyman Date: Mon Sep 21 17:46:17 2015 +0300 xhci: init command timeout timer earlier to avoid deleting it uninitialized commit cc8e4fc0c3b5e8340bc8358990515d116a3c274c upstream. Don't check if timer is running with a timer_pending() before deleting it with del_timer_sync(), this defies the whole point of the sync part and can cause a possible race. Instead we just want to make sure the timer is initialized early enough before we have a chance to delete it. Reported-by: Oliver Neukum Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 4069e26916de74b9ffbf1a1326f47e26a4113027 Author: Mathias Nyman Date: Mon Sep 21 17:46:16 2015 +0300 xhci: change xhci 1.0 only restrictions to support xhci 1.1 commit dca7794539eff04b786fb6907186989e5eaaa9c2 upstream. Some changes between xhci 0.96 and xhci 1.0 specifications forced us to check the hci version in code, some of these checks were implemented as hci_version == 1.0, which will not work with new xhci 1.1 controllers. xhci 1.1 behaves similar to xhci 1.0 in these cases, so change these checks to hci_version >= 1.0 Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 958f252da26ca5ea3e2f579046768fae3713bae0 Author: Roger Quadros Date: Mon Sep 21 17:46:15 2015 +0300 usb: xhci: exit early in xhci_setup_device() if we're halted or dying commit 448116bfa856d3c076fa7178ed96661a008a5d45 upstream. During quick plug/removal of OTG adapter during dual-role testing it can happen that xhci_alloc_device() is called for the newly detected device after the DRD library has called xhci_stop to remove the HCD. If that is the case, just fail early to prevent the following warning. [ 154.732649] hub 4-0:1.0: USB hub found [ 154.742204] hub 4-0:1.0: 1 port detected [ 154.824458] hub 3-0:1.0: state 7 ports 1 chg 0002 evt 0000 [ 154.854609] hub 4-0:1.0: state 7 ports 1 chg 0000 evt 0000 [ 154.944430] usb 3-1: new high-speed USB device number 2 using xhci-hcd [ 154.951009] xhci-hcd xhci-hcd.0.auto: xhci_setup_device [ 155.038191] xhci-hcd xhci-hcd.0.auto: remove, state 4 [ 155.043315] usb usb4: USB disconnect, device number 1 [ 155.055270] xhci-hcd xhci-hcd.0.auto: xhci_stop [ 155.060094] xhci-hcd xhci-hcd.0.auto: USB bus 4 deregistered [ 155.066576] xhci-hcd xhci-hcd.0.auto: remove, state 1 [ 155.071710] usb usb3: USB disconnect, device number 1 [ 155.077124] xhci-hcd xhci-hcd.0.auto: xhci_setup_device [ 155.082389] ------------[ cut here ]------------ [ 155.087690] WARNING: CPU: 0 PID: 72 at drivers/usb/host/xhci.c:3800 xhci_setup_device+0x410/0x484 [xhci_hcd]() [ 155.097861] Modules linked in: sd_mod usb_storage scsi_mod usb_f_ss_lb g_zero libcomposite ipv6 xhci_plat_hcd xhci_hcd usbcore dwc3 udc_core evdev ti_am335x_adc joydev kfifo_buf industrialio snd_soc_simple_cc [ 155.146734] CPU: 0 PID: 72 Comm: kworker/0:3 Tainted: G W 4.1.4-00834-gcd9380b-dirty #50 [ 155.156073] Hardware name: Generic AM43 (Flattened Device Tree) [ 155.162117] Workqueue: usb_hub_wq hub_event [usbcore] [ 155.167249] Backtrace: [ 155.169751] [] (dump_backtrace) from [] (show_stack+0x18/0x1c) [ 155.177390] r6:c089d4a4 r5:ffffffff r4:00000000 r3:ee46c000 [ 155.183137] [] (show_stack) from [] (dump_stack+0x84/0xd0) [ 155.190446] [] (dump_stack) from [] (warn_slowpath_common+0x80/0xbc) [ 155.198605] r7:00000009 r6:00000ed8 r5:bf27eb70 r4:00000000 [ 155.204348] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x24/0x2c) [ 155.213202] r8:ee49f000 r7:ee7c0004 r6:00000000 r5:ee7c0158 r4:ee7c0000 [ 155.220051] [] (warn_slowpath_null) from [] (xhci_setup_device+0x410/0x484 [xhci_hcd]) [ 155.229816] [] (xhci_setup_device [xhci_hcd]) from [] (xhci_address_device+0x14/0x18 [xhci_hcd]) [ 155.240415] r10:ee598200 r9:00000001 r8:00000002 r7:00000001 r6:00000003 r5:00000002 [ 155.248363] r4:ee49f000 [ 155.250978] [] (xhci_address_device [xhci_hcd]) from [] (hub_port_init+0x1b8/0xa9c [usbcore]) [ 155.261403] [] (hub_port_init [usbcore]) from [] (hub_event+0x738/0x1020 [usbcore]) [ 155.270874] r10:ee598200 r9:ee7c0000 r8:ee7c0038 r7:ee518800 r6:ee49f000 r5:00000001 [ 155.278822] r4:00000000 [ 155.281426] [] (hub_event [usbcore]) from [] (process_one_work+0x128/0x340) [ 155.290196] r10:00000000 r9:00000003 r8:00000000 r7:fedfa000 r6:eeec5400 r5:ee598314 [ 155.298151] r4:ee434380 [ 155.300718] [] (process_one_work) from [] (worker_thread+0x158/0x49c) [ 155.308963] r10:ee434380 r9:00000003 r8:eeec5400 r7:00000008 r6:ee434398 r5:eeec5400 [ 155.316913] r4:eeec5414 [ 155.319482] [] (worker_thread) from [] (kthread+0xdc/0xf8) [ 155.326765] r10:00000000 r9:00000000 r8:00000000 r7:c00577a0 r6:ee434380 r5:ee4441c0 [ 155.334713] r4:00000000 r3:00000000 [ 155.338341] [] (kthread) from [] (ret_from_fork+0x14/0x2c) [ 155.345626] r7:00000000 r6:00000000 r5:c005cb64 r4:ee4441c0 [ 155.356108] ---[ end trace a58d34c223b190e6 ]--- [ 155.360783] xhci-hcd xhci-hcd.0.auto: Virt dev invalid for slot_id 0x1! [ 155.574404] xhci-hcd xhci-hcd.0.auto: xhci_setup_device [ 155.579667] ------------[ cut here ]------------ Signed-off-by: Roger Quadros Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit a60f61bee5db8eb94bbf2f3e435937164d361bbf Author: Roger Quadros Date: Mon Sep 21 17:46:14 2015 +0300 usb: xhci: stop everything on the first call to xhci_stop commit 8c24d6d7b09deee3036ddc4f2b81b53b28c8f877 upstream. xhci_stop will be called twice, once for the shared hcd and again for the primary hcd. We stop the XHCI controller in any case so clean up everything on the first call else we can timeout waiting for pending requests to complete. Signed-off-by: Roger Quadros Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit bd5e8c56e6de29093ce30428e957dcf7778cda2e Author: Roger Quadros Date: Mon Sep 21 17:46:13 2015 +0300 usb: xhci: Clear XHCI_STATE_DYING on start commit e5bfeab0ad515b4f6df39fe716603e9dc6d3dfd0 upstream. For whatever reason if XHCI died in the previous instant then it will never recover on the next xhci_start unless we clear the DYING flag. Signed-off-by: Roger Quadros Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 761ccab43dc8951e042b525dc05f11618e92b000 Author: Roger Quadros Date: Mon Sep 21 17:46:12 2015 +0300 usb: xhci: lock mutex on xhci_stop commit 85ac90f8953a58f6a057b727bc9db97721e3fb8e upstream. Else it races with xhci_setup_device Signed-off-by: Roger Quadros Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit de6e390a6810d5101e1ba86ef6ef6cdd0bf8a673 Author: Tomer Barletz Date: Mon Sep 21 17:46:11 2015 +0300 xhci: Move xhci_pme_quirk() behind #ifdef CONFIG_PM commit 2b7627b73e81e5d23d5ae1490fe8e690af86e053 upstream. xhci_pme_quirk() is only used when CONFIG_PM is defined. Compiling a kernel without PM complains about this function [reworded commit message -Mathias] Signed-off-by: Tomer Barletz Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 444987819ffd3d887018a4482338864baa4bbf1f Author: Mathias Nyman Date: Mon Sep 21 17:46:10 2015 +0300 xhci: give command abortion one more chance before killing xhci commit a6809ffd1687b3a8c192960e69add559b9d32649 upstream. We want to give the command abortion an additional try to stop the command ring before we completely hose xhci. Tested-by: Vincent Pelletier Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit dfdd3ccc706247624daa5e2496a238090c9c3389 Author: Johan Hovold Date: Wed Sep 23 11:41:42 2015 -0700 USB: whiteheat: fix potential null-deref at probe commit cbb4be652d374f64661137756b8f357a1827d6a4 upstream. Fix potential null-pointer dereference at probe by making sure that the required endpoints are present. The whiteheat driver assumes there are at least five pairs of bulk endpoints, of which the final pair is used for the "command port". An attempt to bind to an interface with fewer bulk endpoints would currently lead to an oops. Fixes CVE-2015-5257. Reported-by: Moein Ghasemzadeh Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 1eb8084fc4d2813e238cdb2d2948761022d03062 Author: Dave Airlie Date: Wed Sep 30 10:39:42 2015 +1000 drm/dp/mst: drop cancel work sync in the mstb destroy path (v2) commit 274d83524895fe41ca8debae4eec60ede7252bb5 upstream. Since 9eb1e57f564d4e6e10991402726cc83fe0b9172f drm/dp/mst: make sure mst_primary mstb is valid in work function we validate the mstb structs in the work function, and doing that takes a reference. So we should never get here with the work function running using the mstb device, only if the work function hasn't run yet or is running for another mstb. So we don't need to sync the work here, this was causing lockdep spew as below. [ +0.000160] ============================================= [ +0.000001] [ INFO: possible recursive locking detected ] [ +0.000002] 3.10.0-320.el7.rhel72.stable.backport.3.x86_64.debug #1 Tainted: G W ------------ [ +0.000001] --------------------------------------------- [ +0.000001] kworker/4:2/1262 is trying to acquire lock: [ +0.000001] ((&mgr->work)){+.+.+.}, at: [] flush_work+0x5/0x2e0 [ +0.000007] but task is already holding lock: [ +0.000001] ((&mgr->work)){+.+.+.}, at: [] process_one_work+0x1b4/0x710 [ +0.000004] other info that might help us debug this: [ +0.000001] Possible unsafe locking scenario: [ +0.000002] CPU0 [ +0.000000] ---- [ +0.000001] lock((&mgr->work)); [ +0.000002] lock((&mgr->work)); [ +0.000001] *** DEADLOCK *** [ +0.000001] May be due to missing lock nesting notation [ +0.000002] 2 locks held by kworker/4:2/1262: [ +0.000001] #0: (events_long){.+.+.+}, at: [] process_one_work+0x1b4/0x710 [ +0.000004] #1: ((&mgr->work)){+.+.+.}, at: [] process_one_work+0x1b4/0x710 [ +0.000003] stack backtrace: [ +0.000003] CPU: 4 PID: 1262 Comm: kworker/4:2 Tainted: G W ------------ 3.10.0-320.el7.rhel72.stable.backport.3.x86_64.debug #1 [ +0.000001] Hardware name: LENOVO 20EGS0R600/20EGS0R600, BIOS GNET71WW (2.19 ) 02/05/2015 [ +0.000008] Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper] [ +0.000001] ffffffff82c26c90 00000000a527b914 ffff88046399bae8 ffffffff816fe04d [ +0.000004] ffff88046399bb58 ffffffff8110f47f ffff880461438000 0001009b840fc003 [ +0.000002] ffff880461438a98 0000000000000000 0000000804dc26e1 ffffffff824a2c00 [ +0.000003] Call Trace: [ +0.000004] [] dump_stack+0x19/0x1b [ +0.000004] [] __lock_acquire+0x115f/0x1250 [ +0.000002] [] lock_acquire+0x99/0x1e0 [ +0.000002] [] ? flush_work+0x5/0x2e0 [ +0.000002] [] flush_work+0x4e/0x2e0 [ +0.000002] [] ? flush_work+0x5/0x2e0 [ +0.000004] [] ? native_sched_clock+0x35/0x80 [ +0.000002] [] ? sched_clock+0x9/0x10 [ +0.000002] [] ? local_clock+0x25/0x30 [ +0.000002] [] ? mark_held_locks+0xb9/0x140 [ +0.000003] [] ? __cancel_work_timer+0x95/0x160 [ +0.000002] [] __cancel_work_timer+0xa8/0x160 [ +0.000002] [] cancel_work_sync+0x10/0x20 [ +0.000007] [] drm_dp_destroy_mst_branch_device+0x27/0x120 [drm_kms_helper] [ +0.000006] [] drm_dp_mst_link_probe_work+0x78/0xa0 [drm_kms_helper] [ +0.000002] [] process_one_work+0x220/0x710 [ +0.000002] [] ? process_one_work+0x1b4/0x710 [ +0.000005] [] worker_thread+0x11b/0x3a0 [ +0.000003] [] ? process_one_work+0x710/0x710 [ +0.000002] [] kthread+0xed/0x100 [ +0.000003] [] ? insert_kthread_work+0x80/0x80 [ +0.000003] [] ret_from_fork+0x58/0x90 v2: add flush_work. Reviewed-by: Daniel Vetter Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 822b63beecffbb368809e70582bccff9efdac1d1 Author: Dave Airlie Date: Wed Sep 16 10:37:28 2015 +1000 drm/dp/mst: fixup handling hotplug on port removal. commit df4839fdc9b3c922586b945f062f38cbbda022bb upstream. output ports should always have a connector, unless in the rare case connector allocation fails in the driver. In this case we only need to teardown the pdt, and free the struct, and there is no need to send a hotplug msg. In the case were we add the port to the destroy list we need to send a hotplug if we destroy any connectors, so userspace knows to reprobe stuff. this patch also handles port->connector allocation failing which should be a rare event, but makes the code consistent. Reviewed-by: Daniel Vetter Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 5a633828b4b2bef343826afcb0a70770c4911c55 Author: Michel Dänzer Date: Mon Sep 28 18:16:31 2015 +0900 drm/radeon: Restore LCD backlight level on resume (>= R5xx) commit 4281f46ef839050d2ef60348f661eb463c21cc2e upstream. Instead of only enabling the backlight (which seems to set it to max brightness), just re-set the current backlight level, which also takes care of enabling the backlight if necessary. Only the radeon_atom_encoder_dpms_dig part tested on a Kaveri laptop, the radeon_atom_encoder_dpms_avivo part is only compile tested. Signed-off-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 60a09aef456ef590762d47da9c25650e230e2f85 Author: Daniel Vetter Date: Tue Jun 23 11:34:21 2015 +0200 drm: Reject DRI1 hw lock ioctl functions for kms drivers commit da168d81b44898404d281d5dbe70154ab5f117c1 upstream. I've done some extensive history digging across libdrm, mesa and xf86-video-{intel,nouveau,ati}. The only potential user of this with kms drivers I could find was ttmtest, which once used drmGetLock still. But that mistake was quickly fixed up. Even the intel xvmc library (which otherwise was really good with using dri1 stuff in kms mode) managed to never take the hw lock for dri2 (and hence kms). Hence it should be save to unconditionally disallow this. Cc: Peter Antoine Reviewed-by: Peter Antoine Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 230f6fd628c83fcb44ea364d69a9ad88826ef8c4 Author: Jani Nikula Date: Thu Sep 17 16:42:07 2015 +0300 drm/i915/bios: handle MIPI Sequence Block v3+ gracefully commit cd67d226ebd909d239d2c6e5a6abd6e2a338d1cd upstream. The VBT MIPI Sequence Block version 3 has forward incompatible changes: First, the block size in the header has been specified reserved, and the actual size is a separate 32-bit value within the block. The current find_section() function to will only look at the size in the block header, and, depending on what's in that now reserved size field, continue looking for other sections in the wrong place. Fix this by taking the new block size field into account. This will ensure that the lookups for other sections will work properly, as long as the new 32-bit size does not go beyond the opregion VBT mailbox size. Second, the contents of the block have been completely changed. Gracefully refuse parsing the yet unknown data version. Cc: Deepak M Reviewed-by: Deepak M Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 6822c9c3f9c4f809e366108b9a13240e843fd7d1 Author: Alex Deucher Date: Tue Sep 29 13:53:30 2015 -0400 drm/amdgpu: Restore LCD backlight level on resume commit 74b3112e95073b351e3b0b9799795bc76f8415fa upstream. Instead of only enabling the backlight (which seems to set it to max brightness), just re-set the current backlight level, which also takes care of enabling the backlight if necessary. Port of radeon commit: drm/radeon: Restore LCD backlight level on resume (>= R5xx) Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 863a016a0c51f92e970a220296ed404c011b1e81 Author: Alex Deucher Date: Tue Sep 22 10:06:45 2015 -0400 drm/amdgpu: Fix max_vblank_count value for current display engines commit 5a6adfa20b622a273205e33b20c12332aa7eb724 upstream. The value was much too low, which could cause the userspace visible vblank counter to move backwards when the hardware counter wrapped around. Ported from radeon commit: b0b9bb4dd51f396dcf843831905f729e74b0c8c0 Reviewed-by: Christian König Reviewed-by: Jammy Zhou Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 885838eef785ff810dac945be8132856f2113cf1 Author: Leo Liu Date: Tue Sep 15 10:38:38 2015 -0400 drm/amdgpu: make UVD handle checking more strict commit 5146419e6feb99cfbc8dbf005dd2f62603e15efb upstream. Invalid messages can crash the hw otherwise Ported from radeon commit a1b403da70e038ca6c6c6fe434d1d873546873a3 Signed-off-by: Leo Liu Reviewed-by: Christian König Signed-off-by: Greg Kroah-Hartman commit 7ba9a43d8286b1de7f283966d4aa0a319a68dc5a Author: Leo Liu Date: Fri Sep 11 14:22:18 2015 -0400 drm/amdgpu: fix the UVD suspend sequence order commit 2bd188d0167227932be3cf5b033c0e600b01291f upstream. Fixes suspend issues with UVD. Signed-off-by: Leo Liu Reviewed-by: Christian König Signed-off-by: Greg Kroah-Hartman commit 3512d8e6391dd0784f685a7c81ef5721c73f8e15 Author: Leo Liu Date: Thu Sep 10 13:41:38 2015 -0400 drm/amdgpu: Disable UVD PG commit 1ee4478a26cf55c8f8a6219d7e99f2b48959394d upstream. This causes problems with multiple suspend/resume cycles. Signed-off-by: Leo Liu Reviewed-by: Christian König Signed-off-by: Greg Kroah-Hartman commit d03fd6879317f1c6ef3dfab398a6bc8aaf18f58e Author: Christian König Date: Mon Sep 7 12:32:09 2015 +0200 drm/amdgpu: fix overflow on 32bit systems commit b7d698d7fd7d132c6ebe56d230584f2cae6c94ee upstream. mem->start is a long, so this can overflow on 32bit systems. Signed-off-by: Christian König Reviewed-by: Jammy Zhou Signed-off-by: Greg Kroah-Hartman commit 0c4322feb2c81c2590ed257eeb87241099a40f11 Author: Fabiano Fidêncio Date: Thu Sep 24 15:18:34 2015 +0200 drm/qxl: recreate the primary surface when the bo is not primary commit 8d0d94015e96b8853c4f7f06eac3f269e1b3d866 upstream. When disabling/enabling a crtc the primary area must be updated independently of which crtc has been disabled/enabled. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1264735 Signed-off-by: Fabiano Fidêncio Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 69ae8f5e482e2c8e1b283f8296bcdbe1179bda8f Author: Dave Airlie Date: Mon Sep 14 10:28:34 2015 +1000 drm/qxl: only report first monitor as connected if we have no state commit 69e5d3f893e19613486f300fd6e631810338aa4b upstream. If the server isn't new enough to give us state, report the first monitor as always connected, otherwise believe the server side. Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 357223fe135f0d4ba34d041ea9e8a5340054eed4 Author: Steve French Date: Mon Sep 28 17:21:07 2015 -0500 Do not fall back to SMBWriteX in set_file_size error cases commit 646200a041203f440fb6fcf9cacd9efeda9de74c upstream. The error paths in set_file_size for cifs and smb3 are incorrect. In the unlikely event that a server did not support set file info of the file size, the code incorrectly falls back to trying SMBWriteX (note that only the original core SMB Write, used for example by DOS, can set the file size this way - this actually does not work for the more recent SMBWriteX). The idea was since the old DOS SMB Write could set the file size if you write zero bytes at that offset then use that if server rejects the normal set file info call. Fortunately the SMBWriteX will never be sent on the wire (except when file size is zero) since the length and offset fields were reversed in the two places in this function that call SMBWriteX causing the fall back path to return an error. It is also important to never call an SMB request from an SMB2/sMB3 session (which theoretically would be possible, and can cause a brief session drop, although the client recovers) so this should be fixed. In practice this path does not happen with modern servers but the error fall back to SMBWriteX is clearly wrong. Removing the calls to SMBWriteX in the error paths in cifs_set_file_size Pointed out by PaX/grsecurity team Signed-off-by: Steve French Reported-by: PaX Team CC: Emese Revfy CC: Brad Spengler Signed-off-by: Greg Kroah-Hartman commit 25ef5d974e3a2d05af7c717f20874609d2858ac2 Author: Steve French Date: Tue Sep 22 09:29:38 2015 -0500 disabling oplocks/leases via module parm enable_oplocks broken for SMB3 commit e0ddde9d44e37fbc21ce893553094ecf1a633ab5 upstream. leases (oplocks) were always requested for SMB2/SMB3 even when oplocks disabled in the cifs.ko module. Signed-off-by: Steve French Reviewed-by: Chandrika Srinivasan Signed-off-by: Greg Kroah-Hartman commit abe6e8910658a8f1780c0787b87fb11deca3591b Author: Steve French Date: Thu Sep 24 00:52:37 2015 -0500 Fix sec=krb5 on smb3 mounts commit ceb1b0b9b4d1089e9f2731a314689ae17784c861 upstream. Kerberos, which is very important for security, was only enabled for CIFS not SMB2/SMB3 mounts (e.g. vers=3.0) Patch based on the information detailed in http://thread.gmane.org/gmane.linux.kernel.cifs/10081/focus=10307 to enable Kerberized SMB2/SMB3 a) SMB2_negotiate: enable/use decode_negTokenInit in SMB2_negotiate b) SMB2_sess_setup: handle Kerberos sectype and replicate Kerberos SMB1 processing done in sess_auth_kerberos Signed-off-by: Noel Power Signed-off-by: Jim McDonough Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit c67cd73a47442affcc9ad6c0efd43196bb64ee3b Author: Trond Myklebust Date: Thu Oct 1 18:38:27 2015 -0400 NFS: Fix a write performance regression commit 8fa4592a14ebb3c22a21d846d1e4f65dab7d1a7c upstream. If all other conditions in nfs_can_extend_write() are met, and there are no locks, then we should be able to assume close-to-open semantics and the ability to extend our write to cover the whole page. With this patch, the xfstests generic/074 test completes in 242s instead of >1400s on my test rig. Fixes: bd61e0a9c852 ("locks: convert posix locks to file_lock_context") Cc: Jeff Layton Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 0561ad19a608ac982f1b373ffc9f56a92a875f1b Author: Peng Tao Date: Fri Sep 11 11:14:06 2015 +0800 nfs: fix pg_test page count calculation commit 048883e0b934d9a5103d40e209cb14b7f33d2933 upstream. We really want sizeof(struct page *) instead. Otherwise we limit maximum IO size to 64 pages rather than 512 pages on a 64bit system. Fixes 2e11f829(nfs: cap request size to fit a kmalloced page array). Cc: Christoph Hellwig Signed-off-by: Peng Tao Fixes: 2e11f8296d22 ("nfs: cap request size to fit a kmalloced page array") Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 6244b5cded4c3b0749a144b84d7aaa17b6b84dce Author: Trond Myklebust Date: Sun Sep 20 10:50:17 2015 -0400 NFSv4: Recovery of recalled read delegations is broken commit 24311f884189d42d40354a6f38ca218eb9aeb811 upstream. When a read delegation is being recalled, and we're reclaiming the cached opens, we need to make sure that we only reclaim read-only modes. A previous attempt to do this, relied on retrieving the delegation type from the nfs4_opendata structure. Unfortunately, as Kinglong pointed out, this field can only be set when performing reboot recovery. Furthermore, if we call nfs4_open_recover(), then we end up clobbering the state->flags for all modes that we're not recovering... The fix is to have the delegation recall code pass this information to the recovery call, and then refactor the recovery code so that nfs4_open_delegation_recall() does not need to call nfs4_open_recover(). Reported-by: Kinglong Mee Fixes: 39f897fdbd46 ("NFSv4: When returning a delegation, don't...") Tested-by: Kinglong Mee Cc: NeilBrown Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 21cd8add842d49997b1dd14c497473e9cdb8af21 Author: Kinglong Mee Date: Sun Sep 20 23:03:28 2015 +0800 NFS: Do cleanup before resetting pageio read/write to mds commit 6f29b9bba7b08c6b1d6f2cc4cf750b342fc1946c upstream. There is a reference leak of layout segment after resetting pageio read/write to mds. Signed-off-by: Kinglong Mee Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 9147105e88273e537b26d976bf6a38b0bb30e654 Author: J. Bruce Fields Date: Wed Sep 16 17:21:27 2015 -0400 nfs: fix v4.2 SEEK on files over 2 gigs commit 306a5549355966e480e0dcacdc6b9321d153e0c0 upstream. We're incorrectly assigning a loff_t return to an int. If SEEK_HOLE or SEEK_DATA returns an offset over 2^31 then the application will see a weird lseek() result (usually -EIO). Fixes: bdcc2cd14e4e "NFSv4.2: handle NFS-specific llseek errors" Signed-off-by: J. Bruce Fields Reviewed-by: Anna Schumaker Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 221c44b47adf5a8ec849618ae507ee515b094a8d Author: Johan Hedberg Date: Fri Sep 4 12:22:46 2015 +0300 Bluetooth: Delay check for conn->smp in smp_conn_security() commit d8949aad3eab5d396f4fefcd581773bf07b9a79e upstream. There are several actions that smp_conn_security() might make that do not require a valid SMP context (conn->smp pointer). One of these actions is to encrypt the link with an existing LTK. If the SMP context wasn't initialized properly we should still allow the independent actions to be done, i.e. the check for the context should only be done at the last possible moment. Reported-by: Chuck Ebbert Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 58bee20eeae7f50ec2471f250fdfcd04badbd184 Author: Mark Brown Date: Thu Oct 1 10:59:48 2015 +0100 regulator: core: Handle probe deferral from DT when resolving supplies commit 06423121d9eba0a56b9341cf82b88479017bce14 upstream. When resolving regulator-regulator supplies we ignore probe deferral returns from regulator_dev_lookup() (such as are generated for DT when we can see a supply is registered) and just fall back to the dummy regulator if there are full constraints (as is the case for DT). This means that probe deferral is broken for DT systems, fix that by paying attention to -EPROBE_DEFER return codes like we do -ENODEV. A further patch will simplify this further, this is a minimal fix for the specific issue. Fixes: 9f7e25edb1575a6d2 (regulator: core: Handle full constraints systems when resolving supplies) Reported-by: Sascha Hauer Tested-by: Sascha Hauer Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 24a51705489274a705fdca494321e5ddc5b18757 Author: Chen-Yu Tsai Date: Sat Sep 26 21:21:12 2015 +0800 regulator: axp20x: Fix enable bit indexes for DCDC4 and DCDC5 commit 6b3600b4ba0810c84437cf76556d9afbd55c1bfc upstream. The enable bit indexes for DCDC4 and DCDC5 regulators are off by 1. We haven't run into any problems with this since either the regulators aren't defined in the DT and aren't used, or all the DCDC regulators have the "always-on" property set, as they are almost always used for system critical loads. Signed-off-by: Chen-Yu Tsai Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b6556d8cd9ec858a17a8ebcdcb686ee4dcfed075 Author: Charles Keepax Date: Thu Sep 17 14:50:20 2015 +0100 regulator: core: Correct return value check in regulator_resolve_supply commit 23c3f310e897837aeb8ffe8700b803cb58e7b35d upstream. The ret pointer passed to regulator_dev_lookup is only filled with a valid error code if regulator_dev_lookup returned NULL. Currently regulator_resolve_supply checks this ret value before it checks if a regulator was returned, this can result in valid regulator lookups being ignored. Fixes: 6261b06de565 ("regulator: Defer lookup of supply to regulator_get") Signed-off-by: Charles Keepax Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 3d21d90d681ee539aa8774d3fe86fd2bd6e87217 Author: Florian Westphal Date: Wed Sep 9 02:57:21 2015 +0200 netfilter: nf_log: don't zap all loggers on unregister commit 205ee117d4dc4a11ac3bd9638bb9b2e839f4de9a upstream. like nf_log_unset, nf_log_unregister must not reset the list of loggers. Otherwise, a call to nf_log_unregister() will render loggers of other nf protocols unusable: iptables -A INPUT -j LOG modprobe nf_log_arp ; rmmod nf_log_arp iptables -A INPUT -j LOG iptables: No chain/target/match by that name Fixes: 30e0c6a6be ("netfilter: nf_log: prepare net namespace support for loggers") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 9177f81fcb11182578bed988269282a40193e786 Author: Pablo Neira Ayuso Date: Mon Sep 14 18:04:09 2015 +0200 netfilter: nft_compat: skip family comparison in case of NFPROTO_UNSPEC commit ba378ca9c04a5fc1b2cf0f0274a9d02eb3d1bad9 upstream. Fix lookup of existing match/target structures in the corresponding list by skipping the family check if NFPROTO_UNSPEC is used. This is resulting in the allocation and insertion of one match/target structure for each use of them. So this not only bloats memory consumption but also severely affects the time to reload the ruleset from the iptables-compat utility. After this patch, iptables-compat-restore and iptables-compat take almost the same time to reload large rulesets. Fixes: 0ca743a55991 ("netfilter: nf_tables: add compatibility layer for x_tables") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit e1f5251641cdbf0cd701236fd3b8642549764c79 Author: Pablo Neira Ayuso Date: Thu Sep 17 13:37:00 2015 +0200 netfilter: nf_log: wait for rcu grace after logger unregistration commit ad5001cc7cdf9aaee5eb213fdee657e4a3c94776 upstream. The nf_log_unregister() function needs to call synchronize_rcu() to make sure that the objects are not dereferenced anymore on module removal. Fixes: 5962815a6a56 ("netfilter: nf_log: use an array of loggers instead of list") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 14573919afbe6214ae8c27ac14b944c890542f96 Author: Daniel Borkmann Date: Mon Aug 31 19:11:02 2015 +0200 netfilter: conntrack: use nf_ct_tmpl_free in CT/synproxy error paths commit 9cf94eab8b309e8bcc78b41dd1561c75b537dd0b upstream. Commit 0838aa7fcfcd ("netfilter: fix netns dependencies with conntrack templates") migrated templates to the new allocator api, but forgot to update error paths for them in CT and synproxy to use nf_ct_tmpl_free() instead of nf_conntrack_free(). Due to that, memory is being freed into the wrong kmemcache, but also we drop the per net reference count of ct objects causing an imbalance. In Brad's case, this leads to a wrap-around of net->ct.count and thus lets __nf_conntrack_alloc() refuse to create a new ct object: [ 10.340913] xt_addrtype: ipv6 does not support BROADCAST matching [ 10.810168] nf_conntrack: table full, dropping packet [ 11.917416] r8169 0000:07:00.0 eth0: link up [ 11.917438] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 12.815902] nf_conntrack: table full, dropping packet [ 15.688561] nf_conntrack: table full, dropping packet [ 15.689365] nf_conntrack: table full, dropping packet [ 15.690169] nf_conntrack: table full, dropping packet [ 15.690967] nf_conntrack: table full, dropping packet [...] With slab debugging, it also reports the wrong kmemcache (kmalloc-512 vs. nf_conntrack_ffffffff81ce75c0) and reports poison overwrites, etc. Thus, to fix the problem, export and use nf_ct_tmpl_free() instead. Fixes: 0838aa7fcfcd ("netfilter: fix netns dependencies with conntrack templates") Reported-by: Brad Jackson Signed-off-by: Daniel Borkmann Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 43fd0843d479d580cd1b2fffc672244a8d30328d Author: Elad Raz Date: Sat Aug 22 08:44:11 2015 +0300 netfilter: ipset: Fixing unnamed union init commit 96be5f2806cd65a2ebced3bfcdf7df0116e6c4a6 upstream. In continue to proposed Vinson Lee's post [1], this patch fixes compilation issues founded at gcc 4.4.7. The initialization of .cidr field of unnamed unions causes compilation error in gcc 4.4.x. References Visible links [1] https://lkml.org/lkml/2015/7/5/74 Signed-off-by: Elad Raz Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 44016f5ec2548cea88d9b787b74e4c28961fe57d Author: Jozsef Kadlecsik Date: Tue Aug 25 11:17:51 2015 +0200 netfilter: ipset: Out of bound access in hash:net* types fixed commit 6fe7ccfd77415a6ba250c10c580eb3f9acf79753 upstream. Dave Jones reported that KASan detected out of bounds access in hash:net* types: [ 23.139532] ================================================================== [ 23.146130] BUG: KASan: out of bounds access in hash_net4_add_cidr+0x1db/0x220 at addr ffff8800d4844b58 [ 23.152937] Write of size 4 by task ipset/457 [ 23.159742] ============================================================================= [ 23.166672] BUG kmalloc-512 (Not tainted): kasan: bad access detected [ 23.173641] ----------------------------------------------------------------------------- [ 23.194668] INFO: Allocated in hash_net_create+0x16a/0x470 age=7 cpu=1 pid=456 [ 23.201836] __slab_alloc.constprop.66+0x554/0x620 [ 23.208994] __kmalloc+0x2f2/0x360 [ 23.216105] hash_net_create+0x16a/0x470 [ 23.223238] ip_set_create+0x3e6/0x740 [ 23.230343] nfnetlink_rcv_msg+0x599/0x640 [ 23.237454] netlink_rcv_skb+0x14f/0x190 [ 23.244533] nfnetlink_rcv+0x3f6/0x790 [ 23.251579] netlink_unicast+0x272/0x390 [ 23.258573] netlink_sendmsg+0x5a1/0xa50 [ 23.265485] SYSC_sendto+0x1da/0x2c0 [ 23.272364] SyS_sendto+0xe/0x10 [ 23.279168] entry_SYSCALL_64_fastpath+0x12/0x6f The bug is fixed in the patch and the testsuite is extended in ipset to check cidr handling more thoroughly. Signed-off-by: Jozsef Kadlecsik Signed-off-by: Greg Kroah-Hartman commit 81907cb73ba38050a8323bbd0e7fefe813c17547 Author: Pablo Neira Ayuso Date: Wed Aug 12 17:41:00 2015 +0200 netfilter: nf_tables: Use 32 bit addressing register from nft_type_to_reg() commit bf798657eb5ba57552096843c315f096fdf9b715 upstream. nft_type_to_reg() needs to return the register in the new 32 bit addressing, otherwise we hit EINVAL when using mappings. Fixes: 49499c3 ("netfilter: nf_tables: switch registers to 32 bit addressing") Reported-by: Andreas Schultz Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit fa193d93ec84460f1660e83a25d1c42951719b8c Author: Pablo Neira Ayuso Date: Fri Aug 28 21:01:43 2015 +0200 netfilter: nfnetlink: work around wrong endianess in res_id field commit a9de9777d613500b089a7416f936bf3ae5f070d2 upstream. The convention in nfnetlink is to use network byte order in every header field as well as in the attribute payload. The initial version of the batching infrastructure assumes that res_id comes in host byte order though. The only client of the batching infrastructure is nf_tables, so let's add a workaround to address this inconsistency. We currently have 11 nfnetlink subsystems according to NFNL_SUBSYS_COUNT, so we can assume that the subsystem 2560, ie. htons(10), will not be allocated anytime soon, so it can be an alias of nf_tables from the nfnetlink batching path when interpreting the res_id field. Based on original patch from Florian Westphal. Reported-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 969bdb93abbea3c199eb4d9991ff20f547c1133e Author: Bernhard Thaler Date: Thu Aug 13 08:58:15 2015 +0200 netfilter: bridge: fix IPv6 packets not being bridged with CONFIG_IPV6=n commit 18e1db67e93ed75d9dc0d34c8d783ccf10547c2b upstream. 230ac490f7fba introduced a dependency to CONFIG_IPV6 which breaks bridging of IPv6 packets on a bridge with CONFIG_IPV6=n. Sysctl entry /proc/sys/net/bridge/bridge-nf-call-ip6tables defaults to 1, for this reason packets are handled by br_nf_pre_routing_ipv6(). When compiled with CONFIG_IPV6=n this function returns NF_DROP but should return NF_ACCEPT to let packets through. Change CONFIG_IPV6=n br_nf_pre_routing_ipv6() return value to NF_ACCEPT. Tested with a simple bridge with two interfaces and IPv6 packets trying to pass from host on left side to host on right side of the bridge. Fixes: 230ac490f7fba ("netfilter: bridge: split ipv6 code into separated file") Signed-off-by: Bernhard Thaler Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 64d7be572e378f7a4405e4b8c2d98d122bd91f89 Author: Mikulas Patocka Date: Fri Oct 2 11:17:37 2015 -0400 dm raid: fix round up of default region size commit 042745ee53a0a7c1f5aff191a4a24213c6dcfb52 upstream. Commit 3a0f9aaee028 ("dm raid: round region_size to power of two") intended to make sure that the default region size is a power of two. However, the logic in that commit is incorrect and sets the variable region_size to 0 or 1, depending on whether min_region_size is a power of two. Fix this logic, using roundup_pow_of_two(), so that region_size is properly rounded up to the next power of two. Signed-off-by: Mikulas Patocka Fixes: 3a0f9aaee028 ("dm raid: round region_size to power of two") Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit c4e429f1fde59aaff269b71c9c78914e2b52a647 Author: NeilBrown Date: Thu Sep 24 15:47:47 2015 +1000 md/raid0: apply base queue limits *before* disk_stack_limits commit 66eefe5de11db1e0d8f2edc3880d50e7c36a9d43 upstream. Calling e.g. blk_queue_max_hw_sectors() after calls to disk_stack_limits() discards the settings determined by disk_stack_limits(). So we need to make those calls first. Fixes: 199dc6ed5179 ("md/raid0: update queue parameter in a safer location.") Reported-by: Jes Sorensen Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit a585e23d282f28e6a4a13ce597e65957b286a59f Author: NeilBrown Date: Mon Aug 3 13:11:47 2015 +1000 md/raid0: update queue parameter in a safer location. commit 199dc6ed5179251fa6158a461499c24bdd99c836 upstream. When a (e.g.) RAID5 array is reshaped to RAID0, the updating of queue parameters (e.g. max number of sectors per bio) is done in the wrong place. It should be part of ->run, but it is actually part of ->takeover. This means it happens before level_store() calls: blk_set_stacking_limits(&mddev->queue->limits); and so it ineffective. This can lead to errors from underlying devices. So move all the relevant settings out of create_stripe_zones() and into raid0_run(). As this can lead to a bug-on it is suitable for any -stable kernel which supports reshape to RAID0. So 2.6.35 or later. As the bug has been present for five years there is no urgency, so no need to rush into -stable. Fixes: 9af204cf720c ("md: Add support for Raid5->Raid0 and Raid10->Raid0 takeover") Reported-by: Yi Zhang Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 05bbd1d848c897b7973f8dc89cc0f483c3d487e8 Author: Liu.Zhao Date: Mon Aug 24 08:36:12 2015 -0700 USB: option: add ZTE PIDs commit 19ab6bc5674a30fdb6a2436b068d19a3c17dc73e upstream. This is intended to add ZTE device PIDs on kernel. Signed-off-by: Liu.Zhao [johan: sort the new entries ] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 0bb5f025725635f66de179aeaef8919e101ace06 Author: Shawn Lin Date: Wed Sep 9 15:41:52 2015 +0800 staging: ion: fix corruption of ion_import_dma_buf commit 6fa92e2bcf6390e64895b12761e851c452d87bd8 upstream. we found this issue but still exit in lastest kernel. Simply keep ion_handle_create under mutex_lock to avoid this race. WARNING: CPU: 2 PID: 2648 at drivers/staging/android/ion/ion.c:512 ion_handle_add+0xb4/0xc0() ion_handle_add: buffer already found. Modules linked in: iwlmvm iwlwifi mac80211 cfg80211 compat CPU: 2 PID: 2648 Comm: TimedEventQueue Tainted: G W 3.14.0 #7 00000000 00000000 9a3efd2c 80faf273 9a3efd6c 9a3efd5c 80935dc9 811d7fd3 9a3efd88 00000a58 812208a0 00000200 80e128d4 80e128d4 8d4ae00c a8cd8600 a8cd8094 9a3efd74 80935e0e 00000009 9a3efd6c 811d7fd3 9a3efd88 9a3efd9c Call Trace: [<80faf273>] dump_stack+0x48/0x69 [<80935dc9>] warn_slowpath_common+0x79/0x90 [<80e128d4>] ? ion_handle_add+0xb4/0xc0 [<80e128d4>] ? ion_handle_add+0xb4/0xc0 [<80935e0e>] warn_slowpath_fmt+0x2e/0x30 [<80e128d4>] ion_handle_add+0xb4/0xc0 [<80e144cc>] ion_import_dma_buf+0x8c/0x110 [<80c517c4>] reg_init+0x364/0x7d0 [<80993363>] ? futex_wait+0x123/0x210 [<80992e0e>] ? get_futex_key+0x16e/0x1e0 [<8099308f>] ? futex_wake+0x5f/0x120 [<80c51e19>] vpu_service_ioctl+0x1e9/0x500 [<80994aec>] ? do_futex+0xec/0x8e0 [<80971080>] ? prepare_to_wait_event+0xc0/0xc0 [<80c51c30>] ? reg_init+0x7d0/0x7d0 [<80a22562>] do_vfs_ioctl+0x2d2/0x4c0 [<80b198ad>] ? inode_has_perm.isra.41+0x2d/0x40 [<80b199cf>] ? file_has_perm+0x7f/0x90 [<80b1a5f7>] ? selinux_file_ioctl+0x47/0xf0 [<80a227a8>] SyS_ioctl+0x58/0x80 [<80fb45e8>] syscall_call+0x7/0x7 [<80fb0000>] ? mmc_do_calc_max_discard+0xab/0xe4 Fixes: 83271f626 ("ion: hold reference to handle...") Signed-off-by: Shawn Lin Reviewed-by: Laura Abbott Signed-off-by: Greg Kroah-Hartman commit d4aaf034211609061872808495e5ed9b8f4cb744 Author: Chuck Lever Date: Thu Jul 9 16:45:18 2015 -0400 svcrdma: Fix send_reply() scatter/gather set-up commit 9d11b51ce7c150a69e761e30518f294fc73d55ff upstream. The Linux NFS server returns garbage in the data payload of inline NFS/RDMA READ replies. These are READs of under 1000 bytes or so where the client has not provided either a reply chunk or a write list. The NFS server delivers the data payload for an NFS READ reply to the transport in an xdr_buf page list. If the NFS client did not provide a reply chunk or a write list, send_reply() is supposed to set up a separate sge for the page containing the READ data, and another sge for XDR padding if needed, then post all of the sges via a single SEND Work Request. The problem is send_reply() does not advance through the xdr_buf when setting up scatter/gather entries for SEND WR. It always calls dma_map_xdr with xdr_off set to zero. When there's more than one sge, dma_map_xdr() sets up the SEND sge's so they all point to the xdr_buf's head. The current Linux NFS/RDMA client always provides a reply chunk or a write list when performing an NFS READ over RDMA. Therefore, it does not exercise this particular case. The Linux server has never had to use more than one extra sge for building RPC/RDMA replies with a Linux client. However, an NFS/RDMA client _is_ allowed to send small NFS READs without setting up a write list or reply chunk. The NFS READ reply fits entirely within the inline reply buffer in this case. This is perhaps a more efficient way of performing NFS READs that the Linux NFS/RDMA client may some day adopt. Fixes: b432e6b3d9c1 ('svcrdma: Change DMA mapping logic to . . .') BugLink: https://bugzilla.linux-nfs.org/show_bug.cgi?id=285 Signed-off-by: Chuck Lever Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit e3f48292195ee63b191a225fbd6cb76f3b638948 Author: Michal Kazior Date: Wed Aug 19 13:10:43 2015 +0200 ath10k: fix dma_mapping_error() handling commit 5e55e3cbd1042cffa6249f22c10585e63f8a29bf upstream. The function returns 1 when DMA mapping fails. The driver would return bogus values and could possibly confuse itself if DMA failed. Fixes: 767d34fc67af ("ath10k: remove DMA mapping wrappers") Reported-by: Dan Carpenter Signed-off-by: Michal Kazior Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit b544e58963421d03b0f8dd9560bcf5b5ed123727 Author: Mike Snitzer Date: Wed Sep 9 21:34:51 2015 -0400 dm crypt: constrain crypt device's max_segment_size to PAGE_SIZE commit 586b286b110e94eb31840ac5afc0c24e0881fe34 upstream. Setting the dm-crypt device's max_segment_size to PAGE_SIZE is an unfortunate constraint that is required to avoid the potential for exceeding dm-crypt's underlying device's max_segments limits -- due to crypt_alloc_buffer() possibly allocating pages for the encryption bio that are not as physically contiguous as the original bio. It is interesting to note that this problem was already fixed back in 2007 via commit 91e106259 ("dm crypt: use bio_add_page"). But Linux 4.0 commit cf2f1abfb ("dm crypt: don't allocate pages for a partial request") regressed dm-crypt back to _not_ using bio_add_page(). But given dm-crypt's cpu parallelization changes all depend on commit cf2f1abfb's abandoning of the more complex io fragments processing that dm-crypt previously had we cannot easily go back to using bio_add_page(). So all said the cleanest way to resolve this issue is to fix dm-crypt to properly constrain the original bios entering dm-crypt so the encryption bios that dm-crypt generates from the original bios are always compatible with the underlying device's max_segments queue limits. It should be noted that technically Linux 4.3 does _not_ need this fix because of the block core's new late bio-splitting capability. But, it is reasoned, there is little to be gained by having the block core split the encrypted bio that is composed of PAGE_SIZE segments. That said, in the future we may revert this change. Fixes: cf2f1abfb ("dm crypt: don't allocate pages for a partial request") Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=104421 Suggested-by: Jeff Moyer Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 0bc3b652089213873a43960cb686d2a1bd7cddf4 Author: Mike Snitzer Date: Tue Sep 8 08:56:13 2015 -0400 dm thin: disable discard support for thin devices if pool's is disabled commit 216076705d6ac291d42e0f8dd85e6a0da98c0fa3 upstream. If the pool is configured with 'ignore_discard' its discard support is disabled. The pool's thin devices should also have queue_limits that reflect discards are disabled. Fixes: 34fbcf62 ("dm thin: range discard support") Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 4e0bada8a59a7251977cfd548b2fca0503ecdec6 Author: Bjorn Helgaas Date: Tue Sep 22 17:03:54 2015 -0500 PCI: Clear IORESOURCE_UNSET when clipping a bridge window commit b838b39e930aa1cfd099ea82ac40ed6d6413af26 upstream. c770cb4cb505 ("PCI: Mark invalid BARs as unassigned") sets IORESOURCE_UNSET if we fail to claim a resource. If we tried to claim a bridge window, failed, clipped the window, and tried to claim the clipped window, we failed again because of IORESOURCE_UNSET: pci_bus 0000:00: root bus resource [mem 0xc0000000-0xffffffff window] pci 0000:00:01.0: can't claim BAR 15 [mem 0xbdf00000-0xddefffff 64bit pref]: no compatible bridge window pci 0000:00:01.0: [mem size 0x20000000 64bit pref] clipped to [mem size 0x1df00000 64bit pref] pci 0000:00:01.0: bridge window [mem size 0x1df00000 64bit pref] pci 0000:00:01.0: can't claim BAR 15 [mem size 0x1df00000 64bit pref]: no address assigned The 00:01.0 window started as [mem 0xbdf00000-0xddefffff 64bit pref]. That starts before the host bridge window [mem 0xc0000000-0xffffffff window], so we clipped the 00:01.0 window to [mem 0xc0000000-0xddefffff 64bit pref]. But we left it marked IORESOURCE_UNSET, so the second claim failed when it should have succeeded. This means downstream devices will also fail for lack of resources, e.g., in the bugzilla below, radeon 0000:01:00.0: Fatal error during GPU init Clear IORESOURCE_UNSET when we clip a bridge window. Also clear IORESOURCE_UNSET in our copy of the unclipped window so we can see exactly what the original window was and how it now fits inside the upstream window. Fixes: c770cb4cb505 ("PCI: Mark invalid BARs as unassigned") Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491#c47 Based-on-patch-by: Lorenzo Pieralisi Based-on-patch-by: Yinghai Lu Tested-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Reviewed-by: Lorenzo Pieralisi Acked-by: Yinghai Lu Signed-off-by: Greg Kroah-Hartman commit f6983f24635144e55651a32a22a94735ed13f548 Author: Alex Williamson Date: Tue Sep 15 22:24:46 2015 -0600 PCI: Use function 0 VPD for identical functions, regular VPD for others commit da2d03ea27f6ed9d2005a67b20dd021ddacf1e4d upstream. 932c435caba8 ("PCI: Add dev_flags bit to access VPD through function 0") added PCI_DEV_FLAGS_VPD_REF_F0. Previously, we set the flag on every non-zero function of quirked devices. If a function turned out to be different from function 0, i.e., it had a different class, vendor ID, or device ID, the flag remained set but we didn't make VPD accessible at all. Flip this around so we only set PCI_DEV_FLAGS_VPD_REF_F0 for functions that are identical to function 0, and allow regular VPD access for any other functions. [bhelgaas: changelog, stable tag] Fixes: 932c435caba8 ("PCI: Add dev_flags bit to access VPD through function 0") Signed-off-by: Alex Williamson Signed-off-by: Bjorn Helgaas Acked-by: Myron Stowe Acked-by: Mark Rustad Signed-off-by: Greg Kroah-Hartman commit 471802a39886920f40a7d4d1e9f16869a1a05548 Author: Alex Williamson Date: Tue Sep 15 11:17:21 2015 -0600 PCI: Fix devfn for VPD access through function 0 commit 9d9240756e63dd87d6cbf5da8b98ceb8f8192b55 upstream. Commit 932c435caba8 ("PCI: Add dev_flags bit to access VPD through function 0") passes PCI_SLOT(devfn) for the devfn parameter of pci_get_slot(). Generally this works because we're fairly well guaranteed that a PCIe device is at slot address 0, but for the general case, including conventional PCI, it's incorrect. We need to get the slot and then convert it back into a devfn. Fixes: 932c435caba8 ("PCI: Add dev_flags bit to access VPD through function 0") Signed-off-by: Alex Williamson Signed-off-by: Bjorn Helgaas Acked-by: Myron Stowe Acked-by: Mark Rustad Signed-off-by: Greg Kroah-Hartman commit 141b2ad2e380866d9eba283ecf940baafba31434 Author: Rusty Russell Date: Wed Aug 26 10:42:26 2015 +0930 tools/lguest: Fix redefinition of struct virtio_pci_cfg_cap commit e523caa601f4a7c2fa1ecd040db921baf7453798 upstream. Ours uses a u32 for the data, since we ensure it's always aligned and it's x86 so it doesn't matter anyway. lguest.c:128:8: error: redefinition of ‘struct virtio_pci_cfg_cap’ Signed-off-by: Rusty Russell Cc: Linus Torvalds Cc: Michael S. Tsirkin Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.org Fixes: 3121bb023e2db ("virtio: define virtio_pci_cfg_cap in header.") Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit e83e472a46257f0457d2fe815afa038cba9bce9c Author: Filipe Manana Date: Mon Sep 28 09:56:26 2015 +0100 Btrfs: update fix for read corruption of compressed and shared extents commit 808f80b46790f27e145c72112189d6a3be2bc884 upstream. My previous fix in commit 005efedf2c7d ("Btrfs: fix read corruption of compressed and shared extents") was effective only if the compressed extents cover a file range with a length that is not a multiple of 16 pages. That's because the detection of when we reached a different range of the file that shares the same compressed extent as the previously processed range was done at extent_io.c:__do_contiguous_readpages(), which covers subranges with a length up to 16 pages, because extent_readpages() groups the pages in clusters no larger than 16 pages. So fix this by tracking the start of the previously processed file range's extent map at extent_readpages(). The following test case for fstests reproduces the issue: seq=`basename $0` seqres=$RESULT_DIR/$seq echo "QA output created by $seq" tmp=/tmp/$$ status=1 # failure is the default! trap "_cleanup; exit \$status" 0 1 2 3 15 _cleanup() { rm -f $tmp.* } # get standard environment, filters and checks . ./common/rc . ./common/filter # real QA test starts here _need_to_be_root _supported_fs btrfs _supported_os Linux _require_scratch _require_cloner rm -f $seqres.full test_clone_and_read_compressed_extent() { local mount_opts=$1 _scratch_mkfs >>$seqres.full 2>&1 _scratch_mount $mount_opts # Create our test file with a single extent of 64Kb that is going to # be compressed no matter which compression algo is used (zlib/lzo). $XFS_IO_PROG -f -c "pwrite -S 0xaa 0K 64K" \ $SCRATCH_MNT/foo | _filter_xfs_io # Now clone the compressed extent into an adjacent file offset. $CLONER_PROG -s 0 -d $((64 * 1024)) -l $((64 * 1024)) \ $SCRATCH_MNT/foo $SCRATCH_MNT/foo echo "File digest before unmount:" md5sum $SCRATCH_MNT/foo | _filter_scratch # Remount the fs or clear the page cache to trigger the bug in # btrfs. Because the extent has an uncompressed length that is a # multiple of 16 pages, all the pages belonging to the second range # of the file (64K to 128K), which points to the same extent as the # first range (0K to 64K), had their contents full of zeroes instead # of the byte 0xaa. This was a bug exclusively in the read path of # compressed extents, the correct data was stored on disk, btrfs # just failed to fill in the pages correctly. _scratch_remount echo "File digest after remount:" # Must match the digest we got before. md5sum $SCRATCH_MNT/foo | _filter_scratch } echo -e "\nTesting with zlib compression..." test_clone_and_read_compressed_extent "-o compress=zlib" _scratch_unmount echo -e "\nTesting with lzo compression..." test_clone_and_read_compressed_extent "-o compress=lzo" status=0 exit Signed-off-by: Filipe Manana Tested-by: Timofey Titovets Signed-off-by: Greg Kroah-Hartman commit ee81cb3d793feff45866309add84936844ac04e4 Author: Filipe Manana Date: Mon Sep 14 09:09:31 2015 +0100 Btrfs: fix read corruption of compressed and shared extents commit 005efedf2c7d0a270ffbe28d8997b03844f3e3e7 upstream. If a file has a range pointing to a compressed extent, followed by another range that points to the same compressed extent and a read operation attempts to read both ranges (either completely or part of them), the pages that correspond to the second range are incorrectly filled with zeroes. Consider the following example: File layout [0 - 8K] [8K - 24K] | | | | points to extent X, points to extent X, offset 4K, length of 8K offset 0, length 16K [extent X, compressed length = 4K uncompressed length = 16K] If a readpages() call spans the 2 ranges, a single bio to read the extent is submitted - extent_io.c:submit_extent_page() would only create a new bio to cover the second range pointing to the extent if the extent it points to had a different logical address than the extent associated with the first range. This has a consequence of the compressed read end io handler (compression.c:end_compressed_bio_read()) finish once the extent is decompressed into the pages covering the first range, leaving the remaining pages (belonging to the second range) filled with zeroes (done by compression.c:btrfs_clear_biovec_end()). So fix this by submitting the current bio whenever we find a range pointing to a compressed extent that was preceded by a range with a different extent map. This is the simplest solution for this corner case. Making the end io callback populate both ranges (or more, if we have multiple pointing to the same extent) is a much more complex solution since each bio is tightly coupled with a single extent map and the extent maps associated to the ranges pointing to the shared extent can have different offsets and lengths. The following test case for fstests triggers the issue: seq=`basename $0` seqres=$RESULT_DIR/$seq echo "QA output created by $seq" tmp=/tmp/$$ status=1 # failure is the default! trap "_cleanup; exit \$status" 0 1 2 3 15 _cleanup() { rm -f $tmp.* } # get standard environment, filters and checks . ./common/rc . ./common/filter # real QA test starts here _need_to_be_root _supported_fs btrfs _supported_os Linux _require_scratch _require_cloner rm -f $seqres.full test_clone_and_read_compressed_extent() { local mount_opts=$1 _scratch_mkfs >>$seqres.full 2>&1 _scratch_mount $mount_opts # Create a test file with a single extent that is compressed (the # data we write into it is highly compressible no matter which # compression algorithm is used, zlib or lzo). $XFS_IO_PROG -f -c "pwrite -S 0xaa 0K 4K" \ -c "pwrite -S 0xbb 4K 8K" \ -c "pwrite -S 0xcc 12K 4K" \ $SCRATCH_MNT/foo | _filter_xfs_io # Now clone our extent into an adjacent offset. $CLONER_PROG -s $((4 * 1024)) -d $((16 * 1024)) -l $((8 * 1024)) \ $SCRATCH_MNT/foo $SCRATCH_MNT/foo # Same as before but for this file we clone the extent into a lower # file offset. $XFS_IO_PROG -f -c "pwrite -S 0xaa 8K 4K" \ -c "pwrite -S 0xbb 12K 8K" \ -c "pwrite -S 0xcc 20K 4K" \ $SCRATCH_MNT/bar | _filter_xfs_io $CLONER_PROG -s $((12 * 1024)) -d 0 -l $((8 * 1024)) \ $SCRATCH_MNT/bar $SCRATCH_MNT/bar echo "File digests before unmounting filesystem:" md5sum $SCRATCH_MNT/foo | _filter_scratch md5sum $SCRATCH_MNT/bar | _filter_scratch # Evicting the inode or clearing the page cache before reading # again the file would also trigger the bug - reads were returning # all bytes in the range corresponding to the second reference to # the extent with a value of 0, but the correct data was persisted # (it was a bug exclusively in the read path). The issue happened # only if the same readpages() call targeted pages belonging to the # first and second ranges that point to the same compressed extent. _scratch_remount echo "File digests after mounting filesystem again:" # Must match the same digests we got before. md5sum $SCRATCH_MNT/foo | _filter_scratch md5sum $SCRATCH_MNT/bar | _filter_scratch } echo -e "\nTesting with zlib compression..." test_clone_and_read_compressed_extent "-o compress=zlib" _scratch_unmount echo -e "\nTesting with lzo compression..." test_clone_and_read_compressed_extent "-o compress=lzo" status=0 exit Signed-off-by: Filipe Manana Reviewed-by: Qu Wenruo Reviewed-by: Liu Bo Signed-off-by: Greg Kroah-Hartman commit 6117f99394c62c7873a193303e5e633970df6d1d Author: Jeff Mahoney Date: Fri Sep 11 21:44:17 2015 -0400 btrfs: skip waiting on ordered range for special files commit a30e577c96f59b1e1678ea5462432b09bf7d5cbc upstream. In btrfs_evict_inode, we properly truncate the page cache for evicted inodes but then we call btrfs_wait_ordered_range for every inode as well. It's the right thing to do for regular files but results in incorrect behavior for device inodes for block devices. filemap_fdatawrite_range gets called with inode->i_mapping which gets resolved to the block device inode before getting passed to wbc_attach_fdatawrite_inode and ultimately to inode_to_bdi. What happens next depends on whether there's an open file handle associated with the inode. If there is, we write to the block device, which is unexpected behavior. If there isn't, we through normally and inode->i_data is used. We can also end up racing against open/close which can result in crashes when i_mapping points to a block device inode that has been closed. Since there can't be any page cache associated with special file inodes, it's safe to skip the btrfs_wait_ordered_range call entirely and avoid the problem. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100911 Tested-by: Christoph Biedl Signed-off-by: Jeff Mahoney Reviewed-by: Filipe Manana Signed-off-by: Greg Kroah-Hartman commit 0bfc2f5be12d31d56053c0dd933ee0686690237a Author: Andreas Dannenberg Date: Mon Oct 5 15:00:14 2015 -0500 ASoC: tas2552: fix dBscale-min declaration commit e2600460bc3aa14ca1df86318a327cbbabedf9a8 upstream. The minimum volume level for the TAS2552 (control register value 0x00) is -7dB however the driver declares it as -0.07dB. Running amixer before the patch reports: dBscale-min=-0.07dB,step=1.00dB,mute=0 Running amixer with the patch applied reports: dBscale-min=-7.00dB,step=1.00dB,mute=0 Signed-off-by: Andreas Dannenberg Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit db120b6f5fa664cbd146b174737593140e27c2e4 Author: Gianluca Renzi Date: Fri Sep 25 21:33:41 2015 +0200 ASoC: sgtl5000: fix wrong register MIC_BIAS_VOLTAGE setup on probe commit e256da84a04ea31c3c215997c847609af224e8f4 upstream. Signed-off-by: Gianluca Renzi Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 795d71206cd381e144cfa9e03608172af5edca76 Author: Lars-Peter Clausen Date: Fri Sep 25 11:07:04 2015 +0200 ASoC: db1200: Fix DAI link format for db1300 and db1550 commit e74679b38c9417c1c524081121cdcdb36f82264d upstream. Commit b4508d0f95fa ("ASoC: db1200: Use static DAI format setup") switched the db1200 driver over to using static DAI format setup instead of a callback function. But the commit only added the dai_fmt field to one of the three DAI links in the driver. This breaks audio on db1300 and db1550. Add the two missing dai_fmt settings to fix the issue. Fixes: b4508d0f95fa ("ASoC: db1200: Use static DAI format setup") Reported-by: Manuel Lauss Tested-by: Manuel Lauss Signed-off-by: Lars-Peter Clausen Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 0633d0e613d72298e1265e90587a046590fcd5cc Author: Yitian Bu Date: Fri Oct 2 15:18:41 2015 +0800 ASoC: dwc: correct irq clear method commit 4873867e5f2bd90faad861dd94865099fc3140f3 upstream. from Designware I2S datasheet, tx/rx XRUN irq is cleared by reading register TOR/ROR, rather than by writing into them. Signed-off-by: Yitian Bu Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit a0e9b9f1b1f8bb945735476a4d98cb78e206a209 Author: Robert Jarzmik Date: Tue Sep 15 20:51:31 2015 +0200 ASoC: fix broken pxa SoC support commit 3c8f7710c1c44fb650bc29b6ef78ed8b60cfaa28 upstream. The previous fix of pxa library support, which was introduced to fix the library dependency, broke the previous SoC behavior, where a machine code binding pxa2xx-ac97 with a coded relied on : - sound/soc/pxa/pxa2xx-ac97.c - sound/soc/codecs/XXX.c For example, the mioa701_wm9713.c machine code is currently broken. The "select ARM" statement wrongly selects the soc/arm/pxa2xx-ac97 for compilation, as per an unfortunate fate SND_PXA2XX_AC97 is both declared in sound/arm/Kconfig and sound/soc/pxa/Kconfig. Fix this by ensuring that SND_PXA2XX_SOC correctly triggers the correct pxa2xx-ac97 compilation. Fixes: 846172dfe33c ("ASoC: fix SND_PXA2XX_LIB Kconfig warning") Signed-off-by: Robert Jarzmik Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e23564c6fd1c394b1198378f778a1e84cbe343bc Author: Robert Jarzmik Date: Tue Sep 22 21:20:22 2015 +0200 ASoC: pxa: pxa2xx-ac97: fix dma requestor lines commit 8811191fdf7ed02ee07cb8469428158572d355a2 upstream. PCM receive and transmit DMA requestor lines were reverted, breaking the PCM playback interface for PXA platforms using the sound/soc/ variant instead of the sound/arm variant. The commit below shows the inversion in the requestor lines. Fixes: d65a14587a9b ("ASoC: pxa: use snd_dmaengine_dai_dma_data") Signed-off-by: Robert Jarzmik Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 403fd405834a02cc5163528590f385653166915e Author: Takashi Iwai Date: Sun Oct 4 22:44:12 2015 +0200 ALSA: hda - Disable power_save_node for IDT 92HD73xx chips commit c7e1008048a97148d3aecae742f66fb2f944644c upstream. The recent widget power saving introduced some unavoidable click noises on old IDT 92HD73xx chips while it still seems working on the compatible new chips. In the bugzilla, we tried lots of tests and workarounds, but they didn't help much. So, let's disable the feature for these specific chips as the least (but safest) fix. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104981 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 99b50c2483a42d7adfb498b4780eac10bcfa3906 Author: John Flatness Date: Fri Oct 2 17:07:49 2015 -0400 ALSA: hda - Apply SPDIF pin ctl to MacBookPro 12,1 commit e8ff581f7ac2bc3b8886094b7ca635dcc4d1b0e9 upstream. The MacBookPro 12,1 has the same setup as the 11 for controlling the status of the optical audio light. Simply apply the existing workaround to the subsystem ID for the 12,1. [sorted the fixup entry by tiwai] Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105401 Signed-off-by: John Flatness Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 22b502d40016fe63504d510200cab91da52d4eca Author: Laura Abbott Date: Fri Oct 2 11:09:54 2015 -0700 ALSA: hda: Add dock support for ThinkPad T550 commit d05ea7da0e8f6df3c62cfee75538f347cb3d89ef upstream. Much like all the other Lenovo laptops, add a quirk to make sound work with docking. Reported-and-tested-by: lacknerflo@gmail.com Signed-off-by: Laura Abbott Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4154d4e8b744ddf4592c274b4b45bd32ed07293b Author: Takashi Iwai Date: Mon Oct 5 16:55:09 2015 +0200 ALSA: synth: Fix conflicting OSS device registration on AWE32 commit 225db5762dc1a35b26850477ffa06e5cd0097243 upstream. When OSS emulation is loaded on ISA SB AWE32 chip, we get now kernel warnings like: WARNING: CPU: 0 PID: 2791 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x51/0x80() sysfs: cannot create duplicate filename '/devices/isa/sbawe.0/sound/card0/seq-oss-0-0' It's because both emux synth and opl3 drivers try to register their OSS device object with the same static index number 0. This hasn't been a big problem until the recent rewrite of device management code (that exposes sysfs at the same time), but it's been an obvious bug. This patch works around it just by using a different index number of emux synth object. There can be a more elegant way to fix, but it's enough for now, as this code won't be touched so often, in anyway. Reported-and-tested-by: Michael Shell Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d061d1d5ddb796cbdd85c0810cfc8ca0033cac31 Author: Takashi Iwai Date: Thu Sep 24 17:36:51 2015 +0200 ALSA: hda - Disable power_save_node for Thinkpads commit 7f57d803ee03730d570dc59a9e3e4842b58dd5cc upstream. Lenovo Thinkpads with recent Realtek codecs seem suffering from click noises at power transition since the introduction of widget power saving in 4.1 kernel. Although this might be solved by some delays in appropriate points, as a quick workaround, just disable the power_save_node feature for now. The gain it gives is relatively small, and this makes the situation back to pre 4.1 time. This patch ended up with a bit more code changes than usual because the existing fixup for Thinkpads is highly chained. Instead of adding yet another chain, combine a few of them into a single fixup entry, as a gratis cleanup. Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=943982 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 839fe740753d047bf2e9ec53f2ce4fb4a57f1f30 Author: Takashi Iwai Date: Thu Sep 24 11:00:18 2015 +0200 ALSA: hda/tegra - async probe for avoiding module loading deadlock commit 83510441bc08bee201c0ded9d81da6dfd008d69a upstream. The Tegra HD-audio controller driver causes deadlocks when loaded as a module since the driver invokes request_module() at binding with the codec driver. This patch works around it by deferring the probe in a work like Intel HD-audio controller driver does. Although hovering the codec probe stuff into udev would be a better solution, it may cause other regressions, so let's try this band-aid fix until the more proper solution gets landed. Reported-by: Thierry Reding Tested-by: Thierry Reding Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit aba3953d525672ee7f6c59d340e0ad59a8838275 Author: Greg Thelen Date: Thu Oct 1 15:37:02 2015 -0700 memcg: fix dirty page migration commit 0610c25daa3e76e38ad5a8fae683a89ff9f71798 upstream. The problem starts with a file backed dirty page which is charged to a memcg. Then page migration is used to move oldpage to newpage. Migration: - copies the oldpage's data to newpage - clears oldpage.PG_dirty - sets newpage.PG_dirty - uncharges oldpage from memcg - charges newpage to memcg Clearing oldpage.PG_dirty decrements the charged memcg's dirty page count. However, because newpage is not yet charged, setting newpage.PG_dirty does not increment the memcg's dirty page count. After migration completes newpage.PG_dirty is eventually cleared, often in account_page_cleaned(). At this time newpage is charged to a memcg so the memcg's dirty page count is decremented which causes underflow because the count was not previously incremented by migration. This underflow causes balance_dirty_pages() to see a very large unsigned number of dirty memcg pages which leads to aggressive throttling of buffered writes by processes in non root memcg. This issue: - can harm performance of non root memcg buffered writes. - can report too small (even negative) values in memory.stat[(total_)dirty] counters of all memcg, including the root. To avoid polluting migrate.c with #ifdef CONFIG_MEMCG checks, introduce page_memcg() and set_page_memcg() helpers. Test: 0) setup and enter limited memcg mkdir /sys/fs/cgroup/test echo 1G > /sys/fs/cgroup/test/memory.limit_in_bytes echo $$ > /sys/fs/cgroup/test/cgroup.procs 1) buffered writes baseline dd if=/dev/zero of=/data/tmp/foo bs=1M count=1k sync grep ^dirty /sys/fs/cgroup/test/memory.stat 2) buffered writes with compaction antagonist to induce migration yes 1 > /proc/sys/vm/compact_memory & rm -rf /data/tmp/foo dd if=/dev/zero of=/data/tmp/foo bs=1M count=1k kill % sync grep ^dirty /sys/fs/cgroup/test/memory.stat 3) buffered writes without antagonist, should match baseline rm -rf /data/tmp/foo dd if=/dev/zero of=/data/tmp/foo bs=1M count=1k sync grep ^dirty /sys/fs/cgroup/test/memory.stat (speed, dirty residue) unpatched patched 1) 841 MB/s 0 dirty pages 886 MB/s 0 dirty pages 2) 611 MB/s -33427456 dirty pages 793 MB/s 0 dirty pages 3) 114 MB/s -33427456 dirty pages 891 MB/s 0 dirty pages Notice that unpatched baseline performance (1) fell after migration (3): 841 -> 114 MB/s. In the patched kernel, post migration performance matches baseline. Fixes: c4843a7593a9 ("memcg: add per cgroup dirty page accounting") Signed-off-by: Greg Thelen Reported-by: Dave Hansen Acked-by: Michal Hocko Acked-by: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5c760d8ef2126690dbbd96b3473e01655f17630f Author: Mel Gorman Date: Thu Oct 1 15:36:57 2015 -0700 mm: hugetlbfs: skip shared VMAs when unmapping private pages to satisfy a fault commit 2f84a8990ebbe235c59716896e017c6b2ca1200f upstream. SunDong reported the following on https://bugzilla.kernel.org/show_bug.cgi?id=103841 I think I find a linux bug, I have the test cases is constructed. I can stable recurring problems in fedora22(4.0.4) kernel version, arch for x86_64. I construct transparent huge page, when the parent and child process with MAP_SHARE, MAP_PRIVATE way to access the same huge page area, it has the opportunity to lead to huge page copy on write failure, and then it will munmap the child corresponding mmap area, but then the child mmap area with VM_MAYSHARE attributes, child process munmap this area can trigger VM_BUG_ON in set_vma_resv_flags functions (vma - > vm_flags & VM_MAYSHARE). There were a number of problems with the report (e.g. it's hugetlbfs that triggers this, not transparent huge pages) but it was fundamentally correct in that a VM_BUG_ON in set_vma_resv_flags() can be triggered that looks like this vma ffff8804651fd0d0 start 00007fc474e00000 end 00007fc475e00000 next ffff8804651fd018 prev ffff8804651fd188 mm ffff88046b1b1800 prot 8000000000000027 anon_vma (null) vm_ops ffffffff8182a7a0 pgoff 0 file ffff88106bdb9800 private_data (null) flags: 0x84400fb(read|write|shared|mayread|maywrite|mayexec|mayshare|dontexpand|hugetlb) ------------ kernel BUG at mm/hugetlb.c:462! SMP Modules linked in: xt_pkttype xt_LOG xt_limit [..] CPU: 38 PID: 26839 Comm: map Not tainted 4.0.4-default #1 Hardware name: Dell Inc. PowerEdge R810/0TT6JF, BIOS 2.7.4 04/26/2012 set_vma_resv_flags+0x2d/0x30 The VM_BUG_ON is correct because private and shared mappings have different reservation accounting but the warning clearly shows that the VMA is shared. When a private COW fails to allocate a new page then only the process that created the VMA gets the page -- all the children unmap the page. If the children access that data in the future then they get killed. The problem is that the same file is mapped shared and private. During the COW, the allocation fails, the VMAs are traversed to unmap the other private pages but a shared VMA is found and the bug is triggered. This patch identifies such VMAs and skips them. Signed-off-by: Mel Gorman Reported-by: SunDong Reviewed-by: Michal Hocko Cc: Andrea Arcangeli Cc: Hugh Dickins Cc: Naoya Horiguchi Cc: David Rientjes Reviewed-by: Naoya Horiguchi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6d48b1e9e8b8c4dfa4a492fc7345e6a07b4484d4 Author: Joseph Qi Date: Tue Sep 22 14:59:20 2015 -0700 ocfs2/dlm: fix deadlock when dispatch assert master commit 012572d4fc2e4ddd5c8ec8614d51414ec6cae02a upstream. The order of the following three spinlocks should be: dlm_domain_lock < dlm_ctxt->spinlock < dlm_lock_resource->spinlock But dlm_dispatch_assert_master() is called while holding dlm_ctxt->spinlock and dlm_lock_resource->spinlock, and then it calls dlm_grab() which will take dlm_domain_lock. Once another thread (for example, dlm_query_join_handler) has already taken dlm_domain_lock, and tries to take dlm_ctxt->spinlock deadlock happens. Signed-off-by: Joseph Qi Cc: Joel Becker Cc: Mark Fasheh Cc: "Junxiao Bi" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 27a6aafaf68823abe51378f1e81b70e63c6cd6c3 Author: Sowmini Varadhan Date: Tue Sep 22 14:59:20 2015 -0700 lib/iommu-common.c: do not try to deref a null iommu->lazy_flush() pointer when n < pool->hint commit d046b770c9fc36ccb19c27afdb8322220108cbc7 upstream. The check for invoking iommu->lazy_flush() from iommu_tbl_range_alloc() has to be refactored so that we only call ->lazy_flush() if it is non-null. I had a sparc kernel that was crashing when I was trying to process some very large perf.data files- the crash happens when the scsi driver calls into dma_4v_map_sg and thus the iommu_tbl_range_alloc(). Signed-off-by: Sowmini Varadhan Cc: Benjamin Herrenschmidt Cc: Guenter Roeck Cc: David S. Miller Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9a8d4105affd364d3b266834b5ce4b207e0eb97d Author: Naoya Horiguchi Date: Tue Sep 22 14:59:14 2015 -0700 mm: migrate: hugetlb: putback destination hugepage to active list commit 3aaa76e125c1dd58c9b599baa8c6021896874c12 upstream. Since commit bcc54222309c ("mm: hugetlb: introduce page_huge_active") each hugetlb page maintains its active flag to avoid a race condition betwe= en multiple calls of isolate_huge_page(), but current kernel doesn't set the f= lag on a hugepage allocated by migration because the proper putback routine isn= 't called. This means that users could still encounter the race referred to by bcc54222309c in this special case, so this patch fixes it. Fixes: bcc54222309c ("mm: hugetlb: introduce page_huge_active") Signed-off-by: Naoya Horiguchi Cc: Michal Hocko Cc: Andi Kleen Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1bda8dbe4d7c985f4679f094e68b90fdffe67858 Author: Sudip Mukherjee Date: Thu Sep 10 16:48:13 2015 +0530 spi: spidev: fix possible NULL dereference commit dd85ebf681ef0ee1fc985c353dd45e8b53b5dc1e upstream. During the last close we are freeing spidev if spidev->spi is NULL, but just before checking if spidev->spi is NULL we are dereferencing it. Lets add a check there to avoid the NULL dereference. Fixes: 9169051617df ("spi: spidev: Don't mangle max_speed_hz in underlying spi device") Signed-off-by: Sudip Mukherjee Reviewed-by: Jarkko Nikula Tested-by: Jarkko Nikula Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 9280d7dc378fe0e7cf750729f02f6ab68b7014e8 Author: Tan, Jui Nee Date: Tue Sep 1 10:22:51 2015 +0800 spi: spi-pxa2xx: Check status register to determine if SSSR_TINT is disabled commit 02bc933ebb59208f42c2e6305b2c17fd306f695d upstream. On Intel Baytrail, there is case when interrupt handler get called, no SPI message is captured. The RX FIFO is indeed empty when RX timeout pending interrupt (SSSR_TINT) happens. Use the BIOS version where both HSUART and SPI are on the same IRQ. Both drivers are using IRQF_SHARED when calling the request_irq function. When running two separate and independent SPI and HSUART application that generate data traffic on both components, user will see messages like below on the console: pxa2xx-spi pxa2xx-spi.0: bad message state in interrupt handler This commit will fix this by first checking Receiver Time-out Interrupt, if it is disabled, ignore the request and return without servicing. Signed-off-by: Tan, Jui Nee Acked-by: Jarkko Nikula Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 3a06f82c3e6264c903491f3743a306b447af20bc Author: Martin Sperl Date: Thu Sep 10 09:32:14 2015 +0000 spi: bcm2835: BUG: fix wrong use of PAGE_MASK commit 2a3fffd45822070309bcf0b1e1dae624d633824a upstream. There is a bug in the alignment checking of transfers, that results in DMA not being used for un-aligned transfers that do not cross page-boundries, which is valid. This is due to a missconception of the meaning PAGE_MASK when implementing that check originally - (PAGE_SIZE - 1) should have been used instead. Also fixes a copy/paste error. Reported-by: Signed-off-by: Martin Sperl Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 980f841e9b92f3cbe7f5034c2c7359f9d03dfbe6 Author: Max Filippov Date: Tue Sep 22 14:32:03 2015 +0300 spi: xtensa-xtfpga: fix register endianness commit b0b4855099e301c8603ea37da9a0103a96c2e0b1 upstream. XTFPGA SPI controller has native endian registers. Fix register acessors so that they work in big-endian configurations. Signed-off-by: Max Filippov Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5bc7b6b38603f4a7508939537f83794fc6051ed2 Author: Guenter Roeck Date: Sun Sep 6 01:46:54 2015 +0300 spi: Fix documentation of spi_alloc_master() commit a394d635193b641f2c86ead5ada5b115d57c51f8 upstream. Actually, spi_master_put() after spi_alloc_master() must _not_ be followed by kfree(). The memory is already freed with the call to spi_master_put() through spi_master_class, which registers a release function. Calling both spi_master_put() and kfree() results in often nasty (and delayed) crashes elsewhere in the kernel, often in the networking stack. This reverts commit eb4af0f5349235df2e4a5057a72fc8962d00308a. Link to patch and concerns: https://lkml.org/lkml/2012/9/3/269 or http://lkml.iu.edu/hypermail/linux/kernel/1209.0/00790.html Alexey Klimov: This revert becomes valid after 94c69f765f1b4a658d96905ec59928e3e3e07e6a when spi-imx.c has been fixed and there is no need to call kfree() so comment for spi_alloc_master() should be fixed. Signed-off-by: Guenter Roeck Signed-off-by: Alexey Klimov Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 08a1208a4992f79b4d1691014cc7804a68134bbf Author: Greg Thelen Date: Thu Oct 1 15:37:05 2015 -0700 memcg: make mem_cgroup_read_stat() unsigned commit 484ebb3b8c8b27dd2171696462a3116edb9ff801 upstream. mem_cgroup_read_stat() returns a page count by summing per cpu page counters. The summing is racy wrt. updates, so a transient negative sum is possible. Callers don't want negative values: - mem_cgroup_wb_stats() doesn't want negative nr_dirty or nr_writeback. This could confuse dirty throttling. - oom reports and memory.stat shouldn't show confusing negative usage. - tree_usage() already avoids negatives. Avoid returning negative page counts from mem_cgroup_read_stat() and convert it to unsigned. [akpm@linux-foundation.org: fix old typo while we're in there] Signed-off-by: Greg Thelen Cc: Johannes Weiner Acked-by: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 205f67610791fcbad0b8f61e43d2f2bd3c5188ae Author: Tejun Heo Date: Wed Sep 16 11:51:12 2015 -0400 Revert "sched, cgroup: replace signal_struct->group_rwsem with a global percpu_rwsem" commit 0c986253b939cc14c69d4adbe2b4121bdf4aa220 upstream. This reverts commit d59cfc09c32a2ae31f1c3bc2983a0cd79afb3f14. d59cfc09c32a ("sched, cgroup: replace signal_struct->group_rwsem with a global percpu_rwsem") and b5ba75b5fc0e ("cgroup: simplify threadgroup locking") changed how cgroup synchronizes against task fork and exits so that it uses global percpu_rwsem instead of per-process rwsem; unfortunately, the write [un]lock paths of percpu_rwsem always involve synchronize_rcu_expedited() which turned out to be too expensive. Improvements for percpu_rwsem are scheduled to be merged in the coming v4.4-rc1 merge window which alleviates this issue. For now, revert the two commits to restore per-process rwsem. They will be re-applied for the v4.4-rc1 merge window. Signed-off-by: Tejun Heo Link: http://lkml.kernel.org/g/55F8097A.7000206@de.ibm.com Reported-by: Christian Borntraeger Cc: Oleg Nesterov Cc: "Paul E. McKenney" Cc: Peter Zijlstra Cc: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 38b329c2785844a15b9ef784eb237fa15e716661 Author: Tejun Heo Date: Wed Sep 16 11:51:12 2015 -0400 Revert "cgroup: simplify threadgroup locking" commit f9f9e7b776142fb1c0782cade004cc8e0147a199 upstream. This reverts commit b5ba75b5fc0e8404e2c50cb68f39bb6a53fc916f. d59cfc09c32a ("sched, cgroup: replace signal_struct->group_rwsem with a global percpu_rwsem") and b5ba75b5fc0e ("cgroup: simplify threadgroup locking") changed how cgroup synchronizes against task fork and exits so that it uses global percpu_rwsem instead of per-process rwsem; unfortunately, the write [un]lock paths of percpu_rwsem always involve synchronize_rcu_expedited() which turned out to be too expensive. Improvements for percpu_rwsem are scheduled to be merged in the coming v4.4-rc1 merge window which alleviates this issue. For now, revert the two commits to restore per-process rwsem. They will be re-applied for the v4.4-rc1 merge window. Signed-off-by: Tejun Heo Link: http://lkml.kernel.org/g/55F8097A.7000206@de.ibm.com Reported-by: Christian Borntraeger Cc: Oleg Nesterov Cc: "Paul E. McKenney" Cc: Peter Zijlstra Cc: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 048d7e86e3bd24d8b9a6251353609ee29da8d0c4 Author: Christian Borntraeger Date: Mon Sep 28 22:47:42 2015 +0200 s390/boot/decompression: disable floating point in decompressor commit adc0b7fbf6fe9967505c0254d9535ec7288186ae upstream. my gcc 5.1 used an ldgr instruction with a register != 0,2,4,6 for spilling/filling into a floating point register in our decompressor. This will cause an AFP-register data exception as the decompressor did not setup the additional floating point registers via cr0. That causes a program check loop that looked like a hang with one "Uncompressing Linux... " message (directly booted via kvm) or a loop of "Uncompressing Linux... " messages (when booted via zipl boot loader). The offending code in my build was 48e400: e3 c0 af ff ff 71 lay %r12,-1(%r10) -->48e406: b3 c1 00 1c ldgr %f1,%r12 48e40a: ec 6c 01 22 02 7f clij %r6,2,12,0x48e64e but gcc could do spilling into an fpr at any function. We can simply disable floating point support at that early stage. Signed-off-by: Christian Borntraeger Acked-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 2ef005e0afd60627bedd5b74b6e8768f9e60be8f Author: Martin Schwidefsky Date: Tue Sep 8 15:25:39 2015 +0200 s390/compat: correct uc_sigmask of the compat signal frame commit 8d4bd0ed0439dfc780aab801a085961925ed6838 upstream. The uc_sigmask in the ucontext structure is an array of words to keep the 64 signal bits (or 1024 if you ask glibc but the kernel sigset_t only has 64 bits). For 64 bit the sigset_t contains a single 8 byte word, but for 31 bit there are two 4 byte words. The compat signal handler code uses a simple copy of the 64 bit sigset_t to the 31 bit compat_sigset_t. As s390 is a big-endian architecture this is incorrect, the two words in the 31 bit sigset_t array need to be swapped. Reported-by: Stefan Liebler Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 0738f6995eb87456bf1fb2b2c99d7cb73e82f672 Author: Peter Zijlstra Date: Tue Sep 29 14:45:09 2015 +0200 sched/core: Fix TASK_DEAD race in finish_task_switch() commit 95913d97914f44db2b81271c2e2ebd4d2ac2df83 upstream. So the problem this patch is trying to address is as follows: CPU0 CPU1 context_switch(A, B) ttwu(A) LOCK A->pi_lock A->on_cpu == 0 finish_task_switch(A) prev_state = A->state <-. WMB | A->on_cpu = 0; | UNLOCK rq0->lock | | context_switch(C, A) `-- A->state = TASK_DEAD prev_state == TASK_DEAD put_task_struct(A) context_switch(A, C) finish_task_switch(A) A->state == TASK_DEAD put_task_struct(A) The argument being that the WMB will allow the load of A->state on CPU0 to cross over and observe CPU1's store of A->state, which will then result in a double-drop and use-after-free. Now the comment states (and this was true once upon a long time ago) that we need to observe A->state while holding rq->lock because that will order us against the wakeup; however the wakeup will not in fact acquire (that) rq->lock; it takes A->pi_lock these days. We can obviously fix this by upgrading the WMB to an MB, but that is expensive, so we'd rather avoid that. The alternative this patch takes is: smp_store_release(&A->on_cpu, 0), which avoids the MB on some archs, but not important ones like ARM. Reported-by: Oleg Nesterov Signed-off-by: Peter Zijlstra (Intel) Acked-by: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.org Cc: manfred@colorfullife.com Cc: will.deacon@arm.com Fixes: e4a52bcb9a18 ("sched: Remove rq->lock from the first half of ttwu()") Link: http://lkml.kernel.org/r/20150929124509.GG3816@twins.programming.kicks-ass.net Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 88d508eb06025252a130da5593eff07b4ede11ae Author: Ricardo Ribalda Delgado Date: Fri Jul 31 13:36:21 2015 +0200 leds/led-class: Add missing put_device() commit e5b5a61fcb3743f1dacf9e20d28f48423cecf0c1 upstream. Devices found by class_find_device must be freed with put_device(). Otherwise the reference count will not work properly. Fixes: a96aa64cb572 ("leds/led-class: Handle LEDs with the same name") Reported-by: Alan Tull Signed-off-by: Ricardo Ribalda Delgado Signed-off-by: Jacek Anaszewski Signed-off-by: Greg Kroah-Hartman commit 24f0c28de22c6f7c9f3ab37ad1564524f2d6c4c1 Author: Takashi Iwai Date: Mon Sep 7 14:25:01 2015 +0200 leds:lp55xx: Correct Kconfig dependency for f/w user helper commit 2338f73d407d5abe2036d92716ba25ef5279c3d2 upstream. The commit [b67893206fc0: leds:lp55xx: fix firmware loading error] tries to address the firmware file handling with user helper, but it sets a wrong Kconfig CONFIG_FW_LOADER_USER_HELPER_FALLBACK. Since the wrong option was enabled, the system got a regression -- it suffers from the unexpected long delays for non-present firmware files. This patch corrects the Kconfig dependency to the right one, CONFIG_FW_LOADER_USER_HELPER. This doesn't change the fallback behavior but only enables UMH when needed. Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=944661 Fixes: b67893206fc0 ('leds:lp55xx: fix firmware loading error') Signed-off-by: Takashi Iwai Signed-off-by: Jacek Anaszewski Signed-off-by: Greg Kroah-Hartman commit a13999eccd5817e5be57b64c0b30fff6edf1cbfa Author: Vitaly Kuznetsov Date: Fri Sep 25 11:59:52 2015 +0200 x86/xen: Support kexec/kdump in HVM guests by doing a soft reset commit 0b34a166f291d255755be46e43ed5497cdd194f2 upstream. Currently there is a number of issues preventing PVHVM Xen guests from doing successful kexec/kdump: - Bound event channels. - Registered vcpu_info. - PIRQ/emuirq mappings. - shared_info frame after XENMAPSPACE_shared_info operation. - Active grant mappings. Basically, newly booted kernel stumbles upon already set up Xen interfaces and there is no way to reestablish them. In Xen-4.7 a new feature called 'soft reset' is coming. A guest performing kexec/kdump operation is supposed to call SCHEDOP_shutdown hypercall with SHUTDOWN_soft_reset reason before jumping to new kernel. Hypervisor (with some help from toolstack) will do full domain cleanup (but keeping its memory and vCPU contexts intact) returning the guest to the state it had when it was first booted and thus allowing it to start over. Doing SHUTDOWN_soft_reset on Xen hypervisors which don't support it is probably OK as by default all unknown shutdown reasons cause domain destroy with a message in toolstack log: 'Unknown shutdown reason code 5. Destroying domain.' which gives a clue to what the problem is and eliminates false expectations. Signed-off-by: Vitaly Kuznetsov Signed-off-by: David Vrabel Signed-off-by: Greg Kroah-Hartman commit 3861de2048a7af2f47ad953e4d262076c995c019 Author: Stephen Smalley Date: Thu Oct 1 09:04:22 2015 -0400 x86/mm: Set NX on gap between __ex_table and rodata commit ab76f7b4ab2397ffdd2f1eb07c55697d19991d10 upstream. Unused space between the end of __ex_table and the start of rodata can be left W+x in the kernel page tables. Extend the setting of the NX bit to cover this gap by starting from text_end rather than rodata_start. Before: ---[ High Kernel Mapping ]--- 0xffffffff80000000-0xffffffff81000000 16M pmd 0xffffffff81000000-0xffffffff81600000 6M ro PSE GLB x pmd 0xffffffff81600000-0xffffffff81754000 1360K ro GLB x pte 0xffffffff81754000-0xffffffff81800000 688K RW GLB x pte 0xffffffff81800000-0xffffffff81a00000 2M ro PSE GLB NX pmd 0xffffffff81a00000-0xffffffff81b3b000 1260K ro GLB NX pte 0xffffffff81b3b000-0xffffffff82000000 4884K RW GLB NX pte 0xffffffff82000000-0xffffffff82200000 2M RW PSE GLB NX pmd 0xffffffff82200000-0xffffffffa0000000 478M pmd After: ---[ High Kernel Mapping ]--- 0xffffffff80000000-0xffffffff81000000 16M pmd 0xffffffff81000000-0xffffffff81600000 6M ro PSE GLB x pmd 0xffffffff81600000-0xffffffff81754000 1360K ro GLB x pte 0xffffffff81754000-0xffffffff81800000 688K RW GLB NX pte 0xffffffff81800000-0xffffffff81a00000 2M ro PSE GLB NX pmd 0xffffffff81a00000-0xffffffff81b3b000 1260K ro GLB NX pte 0xffffffff81b3b000-0xffffffff82000000 4884K RW GLB NX pte 0xffffffff82000000-0xffffffff82200000 2M RW PSE GLB NX pmd 0xffffffff82200000-0xffffffffa0000000 478M pmd Signed-off-by: Stephen Smalley Acked-by: Kees Cook Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.org Link: http://lkml.kernel.org/r/1443704662-3138-1-git-send-email-sds@tycho.nsa.gov Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 7450c22876516d8163a254b14c80a6a43b238c7a Author: Thomas Gleixner Date: Wed Sep 30 08:38:22 2015 +0000 x86/process: Add proper bound checks in 64bit get_wchan() commit eddd3826a1a0190e5235703d1e666affa4d13b96 upstream. Dmitry Vyukov reported the following using trinity and the memory error detector AddressSanitizer (https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel). [ 124.575597] ERROR: AddressSanitizer: heap-buffer-overflow on address ffff88002e280000 [ 124.576801] ffff88002e280000 is located 131938492886538 bytes to the left of 28857600-byte region [ffffffff81282e0a, ffffffff82e0830a) [ 124.578633] Accessed by thread T10915: [ 124.579295] inlined in describe_heap_address ./arch/x86/mm/asan/report.c:164 [ 124.579295] #0 ffffffff810dd277 in asan_report_error ./arch/x86/mm/asan/report.c:278 [ 124.580137] #1 ffffffff810dc6a0 in asan_check_region ./arch/x86/mm/asan/asan.c:37 [ 124.581050] #2 ffffffff810dd423 in __tsan_read8 ??:0 [ 124.581893] #3 ffffffff8107c093 in get_wchan ./arch/x86/kernel/process_64.c:444 The address checks in the 64bit implementation of get_wchan() are wrong in several ways: - The lower bound of the stack is not the start of the stack page. It's the start of the stack page plus sizeof (struct thread_info) - The upper bound must be: top_of_stack - TOP_OF_KERNEL_STACK_PADDING - 2 * sizeof(unsigned long). The 2 * sizeof(unsigned long) is required because the stack pointer points at the frame pointer. The layout on the stack is: ... IP FP ... IP FP. So we need to make sure that both IP and FP are in the bounds. Fix the bound checks and get rid of the mix of numeric constants, u64 and unsigned long. Making all unsigned long allows us to use the same function for 32bit as well. Use READ_ONCE() when accessing the stack. This does not prevent a concurrent wakeup of the task and the stack changing, but at least it avoids TOCTOU. Also check task state at the end of the loop. Again that does not prevent concurrent changes, but it avoids walking for nothing. Add proper comments while at it. Reported-by: Dmitry Vyukov Reported-by: Sasha Levin Based-on-patch-from: Wolfram Gloger Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Reviewed-by: Dmitry Vyukov Cc: Andrey Ryabinin Cc: Andy Lutomirski Cc: Andrey Konovalov Cc: Kostya Serebryany Cc: Alexander Potapenko Cc: kasan-dev Cc: Denys Vlasenko Cc: Andi Kleen Cc: Wolfram Gloger Link: http://lkml.kernel.org/r/20150930083302.694788319@linutronix.de Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 1e0b561641cc4362e88e2e6287977dff86e069a8 Author: Lee, Chun-Yi Date: Tue Sep 29 20:58:57 2015 +0800 x86/kexec: Fix kexec crash in syscall kexec_file_load() commit e3c41e37b0f4b18cbd4dac76cbeece5a7558b909 upstream. The original bug is a page fault crash that sometimes happens on big machines when preparing ELF headers: BUG: unable to handle kernel paging request at ffffc90613fc9000 IP: [] prepare_elf64_ram_headers_callback+0x165/0x260 The bug is caused by us under-counting the number of memory ranges and subsequently not allocating enough ELF header space for them. The bug is typically masked on smaller systems, because the ELF header allocation is rounded up to the next page. This patch modifies the code in fill_up_crash_elf_data() by using walk_system_ram_res() instead of walk_system_ram_range() to correctly count the max number of crash memory ranges. That's because the walk_system_ram_range() filters out small memory regions that reside in the same page, but walk_system_ram_res() does not. Here's how I found the bug: After tracing prepare_elf64_headers() and prepare_elf64_ram_headers_callback(), the code uses walk_system_ram_res() to fill-in crash memory regions information to the program header, so it counts those small memory regions that reside in a page area. But, when the kernel was using walk_system_ram_range() in fill_up_crash_elf_data() to count the number of crash memory regions, it filters out small regions. I printed those small memory regions, for example: kexec: Get nr_ram ranges. vaddr=0xffff880077592258 paddr=0x77592258, sz=0xdc0 Based on the code in walk_system_ram_range(), this memory region will be filtered out: pfn = (0x77592258 + 0x1000 - 1) >> 12 = 0x77593 end_pfn = (0x77592258 + 0xfc0 -1 + 1) >> 12 = 0x77593 end_pfn - pfn = 0x77593 - 0x77593 = 0 <=== if (end_pfn > pfn) is FALSE So, the max_nr_ranges that's counted by the kernel doesn't include small memory regions - causing us to under-allocate the required space. That causes the page fault crash that happens in a later code path when preparing ELF headers. This bug is not easy to reproduce on small machines that have few CPUs, because the allocated page aligned ELF buffer has more free space to cover those small memory regions' PT_LOAD headers. Signed-off-by: Lee, Chun-Yi Cc: Andy Lutomirski Cc: Baoquan He Cc: Jiang Liu Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Stephen Rothwell Cc: Takashi Iwai Cc: Thomas Gleixner Cc: Viresh Kumar Cc: Vivek Goyal Cc: kexec@lists.infradead.org Cc: linux-kernel@vger.kernel.org Link: http://lkml.kernel.org/r/1443531537-29436-1-git-send-email-jlee@suse.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 496c2053cd784dd653d295e499503f14907022b3 Author: Matt Fleming Date: Fri Sep 25 23:02:18 2015 +0100 x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down commit a5caa209ba9c29c6421292e7879d2387a2ef39c9 upstream. Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced that signals that the firmware PE/COFF loader supports splitting code and data sections of PE/COFF images into separate EFI memory map entries. This allows the kernel to map those regions with strict memory protections, e.g. EFI_MEMORY_RO for code, EFI_MEMORY_XP for data, etc. Unfortunately, an unwritten requirement of this new feature is that the regions need to be mapped with the same offsets relative to each other as observed in the EFI memory map. If this is not done crashes like this may occur, BUG: unable to handle kernel paging request at fffffffefe6086dd IP: [] 0xfffffffefe6086dd Call Trace: [] efi_call+0x7e/0x100 [] ? virt_efi_set_variable+0x61/0x90 [] efi_delete_dummy_variable+0x63/0x70 [] efi_enter_virtual_mode+0x383/0x392 [] start_kernel+0x38a/0x417 [] x86_64_start_reservations+0x2a/0x2c [] x86_64_start_kernel+0xeb/0xef Here 0xfffffffefe6086dd refers to an address the firmware expects to be mapped but which the OS never claimed was mapped. The issue is that included in these regions are relative addresses to other regions which were emitted by the firmware toolchain before the "splitting" of sections occurred at runtime. Needless to say, we don't satisfy this unwritten requirement on x86_64 and instead map the EFI memory map entries in reverse order. The above crash is almost certainly triggerable with any kernel newer than v3.13 because that's when we rewrote the EFI runtime region mapping code, in commit d2f7cbe7b26a ("x86/efi: Runtime services virtual mapping"). For kernel versions before v3.13 things may work by pure luck depending on the fragmentation of the kernel virtual address space at the time we map the EFI regions. Instead of mapping the EFI memory map entries in reverse order, where entry N has a higher virtual address than entry N+1, map them in the same order as they appear in the EFI memory map to preserve this relative offset between regions. This patch has been kept as small as possible with the intention that it should be applied aggressively to stable and distribution kernels. It is very much a bugfix rather than support for a new feature, since when EFI_PROPERTIES_TABLE is enabled we must map things as outlined above to even boot - we have no way of asking the firmware not to split the code/data regions. In fact, this patch doesn't even make use of the more strict memory protections available in UEFI v2.5. That will come later. Suggested-by: Ard Biesheuvel Reported-by: Ard Biesheuvel Signed-off-by: Matt Fleming Cc: Borislav Petkov Cc: Chun-Yi Cc: Dave Young Cc: H. Peter Anvin Cc: James Bottomley Cc: Lee, Chun-Yi Cc: Leif Lindholm Cc: Linus Torvalds Cc: Matthew Garrett Cc: Mike Galbraith Cc: Peter Jones Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.org Link: http://lkml.kernel.org/r/1443218539-7610-2-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit bc533fbc79f3e18c74fe4a030c3c65a16923daf1 Author: Dirk Müller Date: Thu Oct 1 13:43:42 2015 +0200 Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS commit d2922422c48df93f3edff7d872ee4f3191fefb08 upstream. The cpu feature flags are not ever going to change, so warning everytime can cause a lot of kernel log spam (in our case more than 10GB/hour). The warning seems to only occur when nested virtualization is enabled, so it's probably triggered by a KVM bug. This is a sensible and safe change anyway, and the KVM bug fix might not be suitable for stable releases anyway. Signed-off-by: Dirk Mueller Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit c4cceeaf6604e8b7d71fe9729f78c73dbd4f79e4 Author: Andy Lutomirski Date: Sun Sep 20 16:32:05 2015 -0700 x86/nmi/64: Fix a paravirt stack-clobbering bug in the NMI code commit 83c133cf11fb0e68a51681447e372489f052d40e upstream. The NMI entry code that switches to the normal kernel stack needs to be very careful not to clobber any extra stack slots on the NMI stack. The code is fine under the assumption that SWAPGS is just a normal instruction, but that assumption isn't really true. Use SWAPGS_UNSAFE_STACK instead. This is part of a fix for some random crashes that Sasha saw. Fixes: 9b6e6a8334d5 ("x86/nmi/64: Switch stacks on userspace NMI entry") Reported-and-tested-by: Sasha Levin Signed-off-by: Andy Lutomirski Link: http://lkml.kernel.org/r/974bc40edffdb5c2950a5c4977f821a446b76178.1442791737.git.luto@kernel.org Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 9cdde1d2df7ff6c1001c6d8b268ec39d0654355b Author: Andy Lutomirski Date: Sun Sep 20 16:32:04 2015 -0700 x86/paravirt: Replace the paravirt nop with a bona fide empty function commit fc57a7c68020dcf954428869eafd934c0ab1536f upstream. PARAVIRT_ADJUST_EXCEPTION_FRAME generates this code (using nmi as an example, trimmed for readability): ff 15 00 00 00 00 callq *0x0(%rip) # 2796 2792: R_X86_64_PC32 pv_irq_ops+0x2c That's a call through a function pointer to regular C function that does nothing on native boots, but that function isn't protected against kprobes, isn't marked notrace, and is certainly not guaranteed to preserve any registers if the compiler is feeling perverse. This is bad news for a CLBR_NONE operation. Of course, if everything works correctly, once paravirt ops are patched, it gets nopped out, but what if we hit this code before paravirt ops are patched in? This can potentially cause breakage that is very difficult to debug. A more subtle failure is possible here, too: if _paravirt_nop uses the stack at all (even just to push RBP), it will overwrite the "NMI executing" variable if it's called in the NMI prologue. The Xen case, perhaps surprisingly, is fine, because it's already written in asm. Fix all of the cases that default to paravirt_nop (including adjust_exception_frame) with a big hammer: replace paravirt_nop with an asm function that is just a ret instruction. The Xen case may have other problems, so document them. This is part of a fix for some random crashes that Sasha saw. Reported-and-tested-by: Sasha Levin Signed-off-by: Andy Lutomirski Link: http://lkml.kernel.org/r/8f5d2ba295f9d73751c33d97fda03e0495d9ade0.1442791737.git.luto@kernel.org Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit d522c43f081b5a6bb9787d60380dad497a35d1a3 Author: Andy Shevchenko Date: Wed Jul 29 12:16:47 2015 +0300 x86/pci/intel_mid_pci: Work around for IRQ0 assignment commit 39d9b77b8debb4746e189aa5b61ae6e81ec5eab8 upstream. On Intel Tangier the MMC host controller is wired up to irq 0. But several other devices have irq 0 associated as well due to a bogus PCI configuration. The first initialized driver will acquire irq 0 and make it unavailable for other devices. If the sdhci driver is not the first one it will fail to acquire the interrupt and therefor be non functional. Add a quirk to the pci irq enable function which denies irq 0 to anything else than the MMC host controller driver on Tangier platforms. Fixes: 90b9aacf912a (serial: 8250_pci: add Intel Tangier support) Signed-off-by: Andy Shevchenko Cc: Bjorn Helgaas Link: http://lkml.kernel.org/r/1438161409-4671-2-git-send-email-andriy.shevchenko@linux.intel.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 21f751a634f3b5eaf916f940e47f327fbc6e9727 Author: Thomas Gleixner Date: Mon Sep 14 12:00:55 2015 +0200 x86/ioapic: Force affinity setting in setup_ioapic_dest() commit 4857c91f0d195f05908fff296ba1ec5fca87066c upstream. The recent ioapic cleanups changed the affinity setting in setup_ioapic_dest() from a direct write to the hardware to the delayed affinity setup via irq_set_affinity(). That results in a warning from chained_irq_exit(): WARNING: CPU: 0 PID: 5 at kernel/irq/migration.c:32 irq_move_masked_irq [] irq_move_masked_irq+0xb8/0xc0 [] ioapic_ack_level+0x111/0x130 [] intel_gpio_irq_handler+0x148/0x1c0 The reason is that irq_set_affinity() does not write directly to the hardware. It marks the affinity setting as pending and executes it from the next interrupt. The chained handler infrastructure does not take the irq descriptor lock for performance reasons because such a chained interrupt is not visible to any interfaces. So the delayed affinity setting triggers the warning in irq_move_masked_irq(). Restore the old behaviour by calling the set_affinity function of the ioapic chip in setup_ioapic_dest(). This is safe as none of the interrupts can be on the fly at this point. Fixes: aa5cb97f14a2 'x86/irq: Remove x86_io_apic_ops.set_affinity and related interfaces' Reported-and-tested-by: Mika Westerberg Signed-off-by: Thomas Gleixner Cc: Jiang Liu Cc: jarkko.nikula@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit c8a7318666fca5573199d5e06ec1d779671caf07 Author: David Woodhouse Date: Wed Sep 16 14:10:03 2015 +0100 x86/platform: Fix Geode LX timekeeping in the generic x86 build commit 03da3ff1cfcd7774c8780d2547ba0d995f7dc03d upstream. In 2007, commit 07190a08eef36 ("Mark TSC on GeodeLX reliable") bypassed verification of the TSC on Geode LX. However, this code (now in the check_system_tsc_reliable() function in arch/x86/kernel/tsc.c) was only present if CONFIG_MGEODE_LX was set. OpenWRT has recently started building its generic Geode target for Geode GX, not LX, to include support for additional platforms. This broke the timekeeping on LX-based devices, because the TSC wasn't marked as reliable: https://dev.openwrt.org/ticket/20531 By adding a runtime check on is_geode_lx(), we can also include the fix if CONFIG_MGEODEGX1 or CONFIG_X86_GENERIC are set, thus fixing the problem. Signed-off-by: David Woodhouse Cc: Andres Salomon Cc: Linus Torvalds Cc: Marcelo Tosatti Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1442409003.131189.87.camel@infradead.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit bacb15d25a8b4d618c2783e8fac185b42f0845df Author: Thomas Gleixner Date: Thu Sep 3 12:34:55 2015 +0200 x86/alternatives: Make optimize_nops() interrupt safe and synced commit 66c117d7fa2ae429911e60d84bf31a90b2b96189 upstream. Richard reported the following crash: [ 0.036000] BUG: unable to handle kernel paging request at 55501e06 [ 0.036000] IP: [] common_interrupt+0xb/0x38 [ 0.036000] Call Trace: [ 0.036000] [] ? add_nops+0x90/0xa0 [ 0.036000] [] apply_alternatives+0x274/0x630 Chuck decoded: " 0: 8d 90 90 83 04 24 lea 0x24048390(%eax),%edx 6: 80 fc 0f cmp $0xf,%ah 9: a8 0f test $0xf,%al >> b: a0 06 1e 50 55 mov 0x55501e06,%al 10: 57 push %edi 11: 56 push %esi Interrupt 0x30 occurred while the alternatives code was replacing the initial 0x90,0x90,0x90 NOPs (from the ASM_CLAC macro) with the optimized version, 0x8d,0x76,0x00. Only the first byte has been replaced so far, and it makes a mess out of the insn decoding." optimize_nops() is buggy in two aspects: - It's not disabling interrupts across the modification - It's lacking a sync_core() call Add both. Fixes: 4fd4b6e5537c 'x86/alternatives: Use optimized NOPs for padding' Reported-and-tested-by: "Richard W.M. Jones" Signed-off-by: Thomas Gleixner Cc: Richard W.M. Jones Cc: Chuck Ebbert Cc: Borislav Petkov Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1509031232340.15006@nanos Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit d81b869ce3d742a79fb49e0a4000ff92d48236b7 Author: Shaohua Li Date: Thu Jul 30 16:24:43 2015 -0700 x86/apic: Serialize LVTT and TSC_DEADLINE writes commit 5d7c631d926b59aa16f3c56eaeb83f1036c81dc7 upstream. The APIC LVTT register is MMIO mapped but the TSC_DEADLINE register is an MSR. The write to the TSC_DEADLINE MSR is not serializing, so it's not guaranteed that the write to LVTT has reached the APIC before the TSC_DEADLINE MSR is written. In such a case the write to the MSR is ignored and as a consequence the local timer interrupt never fires. The SDM decribes this issue for xAPIC and x2APIC modes. The serialization methods recommended by the SDM differ. xAPIC: "1. Memory-mapped write to LVT Timer Register, setting bits 18:17 to 10b. 2. WRMSR to the IA32_TSC_DEADLINE MSR a value much larger than current time-stamp counter. 3. If RDMSR of the IA32_TSC_DEADLINE MSR returns zero, go to step 2. 4. WRMSR to the IA32_TSC_DEADLINE MSR the desired deadline." x2APIC: "To allow for efficient access to the APIC registers in x2APIC mode, the serializing semantics of WRMSR are relaxed when writing to the APIC registers. Thus, system software should not use 'WRMSR to APIC registers in x2APIC mode' as a serializing instruction. Read and write accesses to the APIC registers will occur in program order. A WRMSR to an APIC register may complete before all preceding stores are globally visible; software can prevent this by inserting a serializing instruction, an SFENCE, or an MFENCE before the WRMSR." The xAPIC method is to just wait for the memory mapped write to hit the LVTT by checking whether the MSR write has reached the hardware. There is no reason why a proper MFENCE after the memory mapped write would not do the same. Andi Kleen confirmed that MFENCE is sufficient for the xAPIC case as well. Issue MFENCE before writing to the TSC_DEADLINE MSR. This can be done unconditionally as all CPUs which have TSC_DEADLINE also have MFENCE support. [ tglx: Massaged the changelog ] Signed-off-by: Shaohua Li Reviewed-by: Ingo Molnar Cc: Cc: Cc: Cc: Andi Kleen Cc: H. Peter Anvin Link: http://lkml.kernel.org/r/20150909041352.GA2059853@devbig257.prn2.facebook.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit f78a8483d8fc418032f1f891848d11cb92c8717c Author: Ross Zwisler Date: Wed Sep 16 14:52:21 2015 -0600 pmem: add proper fencing to pmem_rw_page() commit ba8fe0f85e15d047686caf8a42463b592c63c98c upstream. pmem_rw_page() needs to call wmb_pmem() on writes to make sure that the newly written data is durable. This flow was added to pmem_rw_bytes() and pmem_make_request() with this commit: commit 61031952f4c8 ("arch, x86: pmem api for ensuring durability of persistent memory updates") ...the pmem_rw_page() path was missed. Signed-off-by: Ross Zwisler Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit e5f35496107d192fb069c54e4d5ae05d110c1cc5 Author: Robert Jarzmik Date: Mon Sep 21 11:06:32 2015 +0200 dmaengine: pxa_dma: fix initial list move commit aebf5a67db8dbacbc624b9c652b81f5460b15eff upstream. Since the commit to have an allocated list of virtual descriptors was reverted, the pxa_dma driver is broken, as it assumes the descriptor is placed on the allocated list upon allocation. Fix the issue in pxa_dma by making an allocated virtual descriptor a singleton. Fixes: 8c8fe97b2b8a ("Revert "dmaengine: virt-dma: don't always free descriptor upon completion"") Signed-off-by: Robert Jarzmik Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit aea324b7fe9b6dbc98fc8e52da58e9a244a7fa7f Author: Ludovic Desroches Date: Wed Jul 22 16:12:29 2015 +0200 dmaengine: at_xdmac: fix bug in prep_dma_cyclic commit e900c30dc1bb0cbc07708e9be1188f531632b2ef upstream. In cyclic mode, the round chaining has been broken by the introduction of at_xdmac_queue_desc(): AT_XDMAC_MBR_UBC_NDE is set for all descriptors excepted for the last one. at_xdmac_queue_desc() has to be called one more time to chain the last and the first descriptors. Signed-off-by: Ludovic Desroches Fixes: 0d0ee751f7f7 ("dmaengine: xdmac: Rework the chaining logic") Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 7ed23a5ce738219bc498cfe0d717186ecbf2890c Author: Andy Shevchenko Date: Mon Sep 28 18:57:03 2015 +0300 dmaengine: dw: properly read DWC_PARAMS register commit 6bea0f6d1c47b07be88dfd93f013ae05fcb3d8bf upstream. In case we have less than maximum allowed channels (8) and autoconfiguration is enabled the DWC_PARAMS read is wrong because it uses different arithmetic to what is needed for channel priority setup. Re-do the caclulations properly. This now works on AVR32 board well. Fixes: fed2574b3c9f (dw_dmac: introduce software emulation of LLP transfers) Cc: yitian.bu@tangramtek.com Signed-off-by: Andy Shevchenko Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit b111b3a634eaff62f655977763d33f1d54cfa846 Author: Ludovic Desroches Date: Tue Sep 15 15:39:11 2015 +0200 dmaengine: at_xdmac: clean used descriptor commit 0be2136b67067617b36c70e525d7534108361e36 upstream. When putting back a descriptor to the free descs list, some fields are not set to 0, it can cause bugs if someone uses it without having this in mind. Descriptor are not put back one by one so it is easier to clean descriptors when we request them. Signed-off-by: Ludovic Desroches Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit f788de2664c2640307b93d658e2bf54f79f1192d Author: Maxime Ripard Date: Tue Sep 15 15:36:00 2015 +0200 dmaengine: at_xdmac: change block increment addressing mode commit a1cf09031e641d3cceaca4a4dd20ef6a785bc9b3 upstream. The addressing mode we were using was not only incrementing the address at each microblock, but also at each data boundary, which was severely slowing the transfer, without any benefit since we were not using the data stride. Switch to the micro block increment only in order to get back to an acceptable performance level. Signed-off-by: Maxime Ripard Signed-off-by: Ludovic Desroches Fixes: 6007ccb57744 ("dmaengine: xdmac: Add interleaved transfer support") Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 56b8a2ad6358ca78c0f14d7a1a6561573c2d8c47 Author: Tejun Heo Date: Sat Sep 5 15:47:36 2015 -0400 block: blkg_destroy_all() should clear q->root_blkg and ->root_rl.blkg commit 6fe810bda0bd9a5d7674fc671fac27b8aa8ec243 upstream. While making the root blkg unconditional, ec13b1d6f0a0 ("blkcg: always create the blkcg_gq for the root blkcg") removed the part which clears q->root_blkg and ->root_rl.blkg during q exit. This leaves the two pointers dangling after blkg_destroy_all(). blk-throttle exit path performs blkg traversals and dereferences ->root_blkg and can lead to the following oops. BUG: unable to handle kernel NULL pointer dereference at 0000000000000558 IP: [] __blkg_lookup+0x26/0x70 ... task: ffff88001b4e2580 ti: ffff88001ac0c000 task.ti: ffff88001ac0c000 RIP: 0010:[] [] __blkg_lookup+0x26/0x70 ... Call Trace: [] blk_throtl_drain+0x5a/0x110 [] blkcg_drain_queue+0x18/0x20 [] __blk_drain_queue+0xc0/0x170 [] blk_queue_bypass_start+0x61/0x80 [] blkcg_deactivate_policy+0x39/0x100 [] blk_throtl_exit+0x38/0x50 [] blkcg_exit_queue+0x3e/0x50 [] blk_release_queue+0x1e/0xc0 ... While the bug is a straigh-forward use-after-free bug, it is tricky to reproduce because blkg release is RCU protected and the rest of exit path usually finishes before RCU grace period. This patch fixes the bug by updating blkg_destro_all() to clear q->root_blkg and ->root_rl.blkg. Signed-off-by: Tejun Heo Reported-by: "Richard W.M. Jones" Reported-by: Josh Boyer Link: http://lkml.kernel.org/g/CA+5PVA5rzQ0s4723n5rHBcxQa9t0cW8BPPBekr_9aMRoWt2aYg@mail.gmail.com Fixes: ec13b1d6f0a0 ("blkcg: always create the blkcg_gq for the root blkcg") Tested-by: Richard W.M. Jones Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 5704348dfc130c1482ac41da0c635ad157b43f4c Author: Jeff Moyer Date: Fri Aug 14 16:15:32 2015 -0400 blockdev: don't set S_DAX for misaligned partitions commit f0b2e563bc419df7c1b3d2f494574c25125f6aed upstream. The dax code doesn't currently support misaligned partitions, so disable O_DIRECT via dax until such time as that support materializes. Suggested-by: Boaz Harrosh Signed-off-by: Jeff Moyer Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit fda7e543449bf0fde30464e8005dba8f1af36a2d Author: Jeff Moyer Date: Fri Aug 14 16:15:31 2015 -0400 dax: fix O_DIRECT I/O to the last block of a blockdev commit e94f5a2285fc94202a9efb2c687481f29b64132c upstream. commit bbab37ddc20b (block: Add support for DAX reads/writes to block devices) caused a regression in mkfs.xfs. That utility sets the block size of the device to the logical block size using the BLKBSZSET ioctl, and then issues a single sector read from the last sector of the device. This results in the dax_io code trying to do a page-sized read from 512 bytes from the end of the device. The result is -ERANGE being returned to userspace. The fix is to align the block to the page size before calling get_block. Thanks to willy for simplifying my original patch. Signed-off-by: Jeff Moyer Tested-by: Linda Knippers Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 47365d694f3bc4da33923aca12836b378caf4017 Author: Felipe F. Tonello Date: Wed Sep 16 18:40:32 2015 +0100 ARM: dts: fix usb pin control for imx-rex dts commit 0af822110871400908d5b6f83a8908c45f881d8f upstream. This fixes a duplicated pin control causing this error: imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_GPIO_1 already requested by regulators:regulator@2; cannot claim for 2184000.usb imx6q-pinctrl 20e0000.iomuxc: pin-137 (2184000.usb) status -22 imx6q-pinctrl 20e0000.iomuxc: could not request pin 137 (MX6Q_PAD_GPIO_1) from group usbotggrp on device 20e0000.iomuxc imx_usb 2184000.usb: Error applying setting, reverse things back imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_EIM_D31 already requested by regulators:regulator@1; cannot claim for 2184200.usb imx6q-pinctrl 20e0000.iomuxc: pin-52 (2184200.usb) status -22 imx6q-pinctrl 20e0000.iomuxc: could not request pin 52 (MX6Q_PAD_EIM_D31) from group usbh1grp on device 20e0000.iomuxc imx_usb 2184200.usb: Error applying setting, reverse things back Signed-off-by: Felipe F. Tonello Fixes: e2047e33f2bd ("ARM: dts: add initial Rex Pro board support") Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit c6c5b607f5c297cdd48fc45415895f55459944af Author: Joonyoung Shim Date: Wed Sep 23 16:41:55 2015 +0900 ARM: dts: Fix wrong clock binding for sysmmu_fimd1_1 on exynos5420 commit c7d2ecd9f64c351cb4d551f1f472d0fc09c3cae8 upstream. The sysmmu_fimd1_1 should bind the clock CLK_SMMU_FIMD1M1, not the clock CLK_SMMU_FIMD1M0. CLK_SMMU_FIMD1M0 is a clock for the sysmmu_fimd1_0. This wrong clock binding causes the problem that is blocked in iommu_map function when IOMMU is enabled and exynos-drm driver tries to allocate buffer via DMA mapping API on Odroid-XU3 board. Fixes: b70045167815 ("ARM: dts: add sysmmu nodes for exynos5420") Signed-off-by: Joonyoung Shim Reviewed-by: Javier Martinez Canillas Acked-by: Marek Szyprowski Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit 7bff4cf150f415aaa5587c1f0d9b8b6f9b3011e2 Author: Timo Sigurdsson Date: Tue Aug 4 23:08:01 2015 +0200 ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to meet SoC specifications commit eaeef1ad9b6ea6df1d1220c254d9563da60cb9d1 upstream. sun7i-a20.dtsi contains a cpufreq operating point at 0.9 volts. The minimum CPU voltage for the Allwinner A20 SoC, however, is 1.0 volts. Thus, raise the voltage for the lowest operating point to 1.0 volts in order to stay within the SoC specifications. It is an undervolted setting that isn't stable across all SoCs and boards out there. Fixes: d96b7161916f ("ARM: dts: sun7i: Add cpu clock reference and operating points to dtsi") Signed-off-by: Timo Sigurdsson Acked-by: Iain Paton Signed-off-by: Maxime Ripard Signed-off-by: Greg Kroah-Hartman commit 0a6184931aeffe6fea5842fca8b06fd64105ee72 Author: Chanho Park Date: Tue Sep 1 23:17:03 2015 +0900 ARM: EXYNOS: reset Little cores when cpu is up commit 833b5794e3303cc97a0d2d4ba97f26cc9d9b4b79 upstream. The cpu booting of exynos5422 has been still broken since we discussed it in last year[1]. This patch is inspired from Odroid XU3 code (Actually, it was from samsung exynos vendor kernel)[2]. This weird reset code was founded exynos5420 octa cores series SoCs and only required for the first boot core is the Little core (Cortex A7). Some of the exynos5420 boards and all of the exynos5422 boards will require this code. There is two ways to check the little core is the first cpu. One is checking GPG2CON[1] GPIO value and the other is checking the cluster number of the first cpu. I selected the latter because it's more easier than the former. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html [2] https://patchwork.kernel.org/patch/6782891/ Cc: Kevin Hilman Cc: Javier Martinez Canillas Cc: Krzysztof Kozlowski Tested-by: Kevin Hilman Signed-off-by: Chanho Park [k.kozlowski: Adding stable for v4.1+, reformat comment] Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit 5903d8e4008f6c0d9b4dd2cce8c5debf0a31c1b2 Author: Jarkko Nikula Date: Mon Sep 7 10:23:01 2015 +0300 ARM: pxa: ssp: Fix build error by removing originally incorrect DT binding commit b692cb83b14d2f741f513221f5f78042c674c2a9 upstream. Commit 03fbf488cece ("spi: pxa2xx: Differentiate Intel LPSS types") caused build error here because it removed the type LPSS_SSP and I didn't notice the type was used here too. I believe commit a6e56c28a178 ("ARM: pxa: ssp: add DT bindings") added it accidentally by copying all enum pxa_ssp_type types from include/linux/pxa2xx_ssp.h even LPSS_SSP was for Intel LPSS SPI devices. Fix the build error by removing this incorrect binding. Fixes: 03fbf488cece ("spi: pxa2xx: Differentiate Intel LPSS types") Signed-off-by: Jarkko Nikula Reported-by: Axel Lin Signed-off-by: Robert Jarzmik Signed-off-by: Greg Kroah-Hartman commit bb12eb239fcc1167735fb124a6778a4c15384682 Author: Carl Frederik Werner Date: Wed Sep 2 10:07:57 2015 +0900 ARM: dts: omap3-beagle: make i2c3, ddc and tfp410 gpio work again commit 3a2fa775bd1d0579113666c1a2e37654a34018a0 upstream. Let's fix pinmux address of gpio 170 used by tfp410 powerdown-gpio. According to the OMAP35x Technical Reference Manual CONTROL_PADCONF_I2C3_SDA[15:0] 0x480021C4 mode0: i2c3_sda CONTROL_PADCONF_I2C3_SDA[31:16] 0x480021C4 mode4: gpio_170 the pinmux address of gpio 170 must be 0x480021C6. The former wrong address broke i2c3 (used by hdmi ddc), resulting in kernel message: omap_i2c 48060000.i2c: controller timed out Fixes: 8cecf52befd7 ("ARM: omap3-beagle.dts: add display information") Signed-off-by: Carl Frederik Werner Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 49107849eb0f2b98570a781ef537d415fcb130fc Author: Grazvydas Ignotas Date: Wed Sep 16 01:34:31 2015 +0300 ARM: dts: omap5-uevm.dts: fix i2c5 pinctrl offsets commit 1dbdad75074d16c3e3005180f81a01cdc04a7872 upstream. The i2c5 pinctrl offsets are wrong. If the bootloader doesn't set the pins up, communication with tca6424a doesn't work (controller timeouts) and it is not possible to enable HDMI. Fixes: 9be495c42609 ("ARM: dts: omap5-evm: Add I2c pinctrl data") Signed-off-by: Grazvydas Ignotas Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit d05cc8b34fc73e40ef9df0dfa9924e33990daaa2 Author: Doug Anderson Date: Wed Aug 26 18:26:49 2015 +0100 ARM: 8425/1: kgdb: Don't try to stop the machine when setting breakpoints commit 7ae85dc7687c7e7119053d83d02c560ea217b772 upstream. In (23a4e40 arm: kgdb: Handle read-only text / modules) we moved to using patch_text() to set breakpoints so that we could handle the case when we had CONFIG_DEBUG_RODATA. That patch used patch_text(). Unfortunately, patch_text() assumes that we're not in atomic context when it runs since it needs to grab a mutex and also wait for other CPUs to stop (which it does with a completion). This would result in a stack crawl if you had CONFIG_DEBUG_ATOMIC_SLEEP and tried to set a breakpoint in kgdb. The crawl looked something like: BUG: scheduling while atomic: swapper/0/0/0x00010007 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc7-00133-geb63b34 #1073 Hardware name: Rockchip (Device Tree) (unwind_backtrace) from [] (show_stack+0x20/0x24) (show_stack) from [] (dump_stack+0x84/0xb8) (dump_stack) from [] (__schedule_bug+0x54/0x6c) (__schedule_bug) from [] (__schedule+0x80/0x668) (__schedule) from [] (schedule+0xb8/0xd4) (schedule) from [] (schedule_timeout+0x2c/0x234) (schedule_timeout) from [] (wait_for_common+0xf4/0x188) (wait_for_common) from [] (wait_for_completion+0x20/0x24) (wait_for_completion) from [] (__stop_cpus+0x58/0x70) (__stop_cpus) from [] (stop_cpus+0x3c/0x54) (stop_cpus) from [] (__stop_machine+0xcc/0xe8) (__stop_machine) from [] (stop_machine+0x34/0x44) (stop_machine) from [] (patch_text+0x28/0x34) (patch_text) from [] (kgdb_arch_set_breakpoint+0x40/0x4c) (kgdb_arch_set_breakpoint) from [] (kgdb_validate_break_address+0x2c/0x60) (kgdb_validate_break_address) from [] (dbg_set_sw_break+0x1c/0xdc) (dbg_set_sw_break) from [] (gdb_serial_stub+0x9c4/0xba4) (gdb_serial_stub) from [] (kgdb_cpu_enter+0x1f8/0x60c) (kgdb_cpu_enter) from [] (kgdb_handle_exception+0x19c/0x1d0) (kgdb_handle_exception) from [] (kgdb_compiled_brk_fn+0x30/0x3c) (kgdb_compiled_brk_fn) from [] (do_undefinstr+0x1a4/0x20c) (do_undefinstr) from [] (__und_svc_finish+0x0/0x34) It turns out that when we're in kgdb all the CPUs are stopped anyway so there's no reason we should be calling patch_text(). We can instead directly call __patch_text() which assumes that CPUs have already been stopped. Fixes: 23a4e4050ba9 ("arm: kgdb: Handle read-only text / modules") Reported-by: Aapo Vienamo Signed-off-by: Douglas Anderson Reviewed-by: Stephen Boyd Acked-by: Kees Cook Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 4195c742511fe4631008004e1a03757b245dd15d Author: Paul Bolle Date: Fri Jul 31 14:08:58 2015 +0200 windfarm: decrement client count when unregistering commit fe2b592173ff0274e70dc44d1d28c19bb995aa7c upstream. wf_unregister_client() increments the client count when a client unregisters. That is obviously incorrect. Decrement that client count instead. Fixes: 75722d3992f5 ("[PATCH] ppc64: Thermal control for SMU based machines") Signed-off-by: Paul Bolle Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit a9170ad82024cdc1798406537bafe46754d70c5d Author: Ard Biesheuvel Date: Thu Sep 3 13:24:40 2015 +0100 ARM: 8429/1: disable GCC SRA optimization commit a077224fd35b2f7fbc93f14cf67074fc792fbac2 upstream. While working on the 32-bit ARM port of UEFI, I noticed a strange corruption in the kernel log. The following snprintf() statement (in drivers/firmware/efi/efi.c:efi_md_typeattr_format()) snprintf(pos, size, "|%3s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]", was producing the following output in the log: | | | | | |WB|WT|WC|UC] | | | | | |WB|WT|WC|UC] | | | | | |WB|WT|WC|UC] |RUN| | | | |WB|WT|WC|UC]* |RUN| | | | |WB|WT|WC|UC]* | | | | | |WB|WT|WC|UC] |RUN| | | | |WB|WT|WC|UC]* | | | | | |WB|WT|WC|UC] |RUN| | | | | | | |UC] |RUN| | | | | | | |UC] As it turns out, this is caused by incorrect code being emitted for the string() function in lib/vsprintf.c. The following code if (!(spec.flags & LEFT)) { while (len < spec.field_width--) { if (buf < end) *buf = ' '; ++buf; } } for (i = 0; i < len; ++i) { if (buf < end) *buf = *s; ++buf; ++s; } while (len < spec.field_width--) { if (buf < end) *buf = ' '; ++buf; } when called with len == 0, triggers an issue in the GCC SRA optimization pass (Scalar Replacement of Aggregates), which handles promotion of signed struct members incorrectly. This is a known but as yet unresolved issue. (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932). In this particular case, it is causing the second while loop to be executed erroneously a single time, causing the additional space characters to be printed. So disable the optimization by passing -fno-ipa-sra. Acked-by: Nicolas Pitre Signed-off-by: Ard Biesheuvel Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 30477feadc4d86d40011326fb2f9e45f3987f504 Author: Russell King Date: Fri Sep 11 16:44:02 2015 +0100 ARM: fix Thumb2 signal handling when ARMv6 is enabled commit 9b55613f42e8d40d5c9ccb8970bde6af4764b2ab upstream. When a kernel is built covering ARMv6 to ARMv7, we omit to clear the IT state when entering a signal handler. This can cause the first few instructions to be conditionally executed depending on the parent context. In any case, the original test for >= ARMv7 is broken - ARMv6 can have Thumb-2 support as well, and an ARMv6T2 specific build would omit this code too. Relax the test back to ARMv6 or greater. This results in us always clearing the IT state bits in the PSR, even on CPUs where these bits are reserved. However, they're reserved for the IT state, so this should cause no harm. Fixes: d71e1352e240 ("Clear the IT state when invoking a Thumb-2 signal handler") Acked-by: Tony Lindgren Tested-by: H. Nikolaus Schaller Tested-by: Grazvydas Ignotas Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 6c0a1c7b39ad1c949e367873067e6c0f9b82016b Author: Guenter Roeck Date: Mon Aug 31 16:13:47 2015 -0700 hwmon: (nct6775) Swap STEP_UP_TIME and STEP_DOWN_TIME registers for most chips commit 728d29400488d54974d3317fe8a232b45fdb42ee upstream. The STEP_UP_TIME and STEP_DOWN_TIME registers are swapped for all chips but NCT6775. Reported-by: Grazvydas Ignotas Reviewed-by: Jean Delvare Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 6f09b507974af9228ea3b6f86ac7dc853db8ac49 Author: Dominik Dingel Date: Fri Sep 18 11:27:45 2015 +0200 sched: access local runqueue directly in single_task_running commit 00cc1633816de8c95f337608a1ea64e228faf771 upstream. Commit 2ee507c47293 ("sched: Add function single_task_running to let a task check if it is the only task running on a cpu") referenced the current runqueue with the smp_processor_id. When CONFIG_DEBUG_PREEMPT is enabled, that is only allowed if preemption is disabled or the currrent task is bound to the local cpu (e.g. kernel worker). With commit f78195129963 ("kvm: add halt_poll_ns module parameter") KVM calls single_task_running. If CONFIG_DEBUG_PREEMPT is enabled that generates a lot of kernel messages. To avoid adding preemption in that cases, as it would limit the usefulness, we change single_task_running to access directly the cpu local runqueue. Cc: Tim Chen Suggested-by: Peter Zijlstra Acked-by: Peter Zijlstra (Intel) Fixes: 2ee507c472939db4b146d545352b8a7c79ef47f8 Signed-off-by: Dominik Dingel Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 427315eac64b51b45813e235bcdc3ec8a3d5e292 Author: Ezequiel Garcia Date: Thu Jul 23 17:21:16 2015 -0300 watchdog: imgpdc: Unregister restart handler on remove commit 8a340dbbc4b10fe07a924e91979bfc93e966dd65 upstream. Commit c631f20068 ("watchdog: imgpdc: Add reboot support") introduced a restart handler but forgot to unregister it on driver removal. Fix it. Fixes: c631f20068 ("watchdog: imgpdc: Add reboot support") Reported-by: Ariel D'Alessandro Signed-off-by: Ezequiel Garcia Reviewed-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman commit 6b73ab3608ed4d6ac548b3bcde45098f48320aea Author: Francesco Lavra Date: Sat Jul 25 08:25:18 2015 +0200 watchdog: sunxi: fix activation of system reset commit 0919e4445190da18496d31aac08b90828a47d45f upstream. Commit f2147de33470 ("watchdog: sunxi: support parameterized compatible strings") introduced a regression in sunxi_wdt_start(), by which the system reset function of the watchdog is not enabled upon starting the watchdog. As a result, the system is not reset when the watchdog expires. Fix it. Fixes: f2147de33470 ("watchdog: sunxi: support parameterized compatible strings") Signed-off-by: Francesco Lavra Acked-by: Maxime Ripard Reviewed-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman commit f8ecfcb2611766e3721124d49bf62335ada1cc93 Author: Vineet Gupta Date: Fri Sep 11 16:32:22 2015 -0700 ARCv2: [axs103_smp] Reduce clk for SMP FPGA configs commit 3ebb0540c20d6670396ccee9ff6794c095fa9311 upstream. Newer bitfiles needs the reduced clk even for SMP builds Signed-off-by: Vineet Gupta Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3e119ee539a56be78f560284d9cc2efed1a29f13 Author: Arnaldo Carvalho de Melo Date: Thu Sep 24 11:24:18 2015 -0300 perf probe: Use existing routine to look for a kernel module by dso->short_name commit 266fa2b22294909ddf6e7d2f8acfe07adf9fd978 upstream. We have map_groups__find_by_name() to look at the list of modules that are in place for a given machine, so use it instead of traversing the machine dso list, which also includes DSOs for userspace. When merging the user and kernel DSO lists a bug was introduced where 'perf probe' stopped being able to add probes to modules using its short name: # perf probe -m usbnet --add usbnet_start_xmit usbnet_start_xmit is out of .text, skip it. Error: Failed to add events. # With this fix it works again: # perf probe -m usbnet --add usbnet_start_xmit Added new event: probe:usbnet_start_xmit (on usbnet_start_xmit in usbnet) You can now use it in all perf tools, such as: perf record -e probe:usbnet_start_xmit -aR sleep 1 # Reported-by: Wang Nan Acked-by: Masami Hiramatsu Cc: Adrian Hunter Cc: Borislav Petkov Cc: David Ahern Cc: Frederic Weisbecker Cc: Jiri Olsa Cc: Namhyung Kim Cc: Stephane Eranian Fixes: 3d39ac538629 ("perf machine: No need to have two DSOs lists") Link: http://lkml.kernel.org/r/20150924015008.GE1897@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 5890162dd59b0999f68b0f550fc5e29e5e7f0e46 Author: Arnaldo Carvalho de Melo Date: Fri Sep 11 12:36:12 2015 -0300 perf header: Fixup reading of HEADER_NRCPUS feature commit caa470475d9b59eeff093ae650800d34612c4379 upstream. The original patch introducing this header wrote the number of CPUs available and online in one order and then swapped those values when reading, fix it. Before: # perf record usleep 1 # perf report --header-only | grep 'nrcpus \(online\|avail\)' # nrcpus online : 4 # nrcpus avail : 4 # echo 0 > /sys/devices/system/cpu/cpu2/online # perf record usleep 1 # perf report --header-only | grep 'nrcpus \(online\|avail\)' # nrcpus online : 4 # nrcpus avail : 3 # echo 0 > /sys/devices/system/cpu/cpu1/online # perf record usleep 1 # perf report --header-only | grep 'nrcpus \(online\|avail\)' # nrcpus online : 4 # nrcpus avail : 2 After the fix, bringing back the CPUs online: # perf report --header-only | grep 'nrcpus \(online\|avail\)' # nrcpus online : 2 # nrcpus avail : 4 # echo 1 > /sys/devices/system/cpu/cpu2/online # perf record usleep 1 # perf report --header-only | grep 'nrcpus \(online\|avail\)' # nrcpus online : 3 # nrcpus avail : 4 # echo 1 > /sys/devices/system/cpu/cpu1/online # perf record usleep 1 # perf report --header-only | grep 'nrcpus \(online\|avail\)' # nrcpus online : 4 # nrcpus avail : 4 Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Borislav Petkov Cc: David Ahern Cc: Frederic Weisbecker Cc: Jiri Olsa Cc: Kan Liang Cc: Stephane Eranian Cc: Wang Nan Fixes: fbe96f29ce4b ("perf tools: Make perf.data more self-descriptive (v8)") Link: http://lkml.kernel.org/r/20150911153323.GP23511@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 6962d198fd3ad01bcf00d022e71c9c13a20c5f9d Author: Jiri Olsa Date: Wed Sep 2 09:56:31 2015 +0200 perf tools: Fix parse_events_add_pmu caller commit 5ad4da4302712fba10624d28cb6c269fee592b69 upstream. Following commit changed parse_events_add_pmu interface: 36adec85a86f perf tools: Change parse_events_add_pmu interface but forgot to change one caller. Because of lessen compilation rules for the bison parser, the compiler did not warn on that. Signed-off-by: Jiri Olsa Cc: Raphael Beamonte Cc: David Ahern Cc: Matt Fleming Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Steven Rostedt Fixes: 36adec85a86f ("perf tools: Change parse_events_add_pmu interface") Link: http://lkml.kernel.org/r/1441180605-24737-2-git-send-email-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit d186164f415ca7f00627a7580181c14526e6941c Author: Ben Hutchings Date: Tue Aug 4 17:10:27 2015 +0100 perf tools: Add empty Build files for architectures lacking them commit 93df8a1ed6231727c5db94a80b1a6bd5ee67cec3 upstream. perf currently fails to build on MIPS as there is no tools/perf/arch/mips/Build file. Adding an empty file fixes this as there are no MIPS-specific sources to build. It looks like the same is needed for Alpha and PA-RISC, though I haven't been able to test those. Signed-off-by: Ben Hutchings Fixes: 5e8c0fb6a957 ("perf build: Add arch x86 objects building") Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1438704627.7315.2.camel@decadent.org.uk Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 8d3fd369d5c0af7892b6fd05d85c472ac29c332d Author: Wang Nan Date: Fri Jun 19 08:42:48 2015 +0000 perf tools: Add missing forward declaration of struct map to probe-event.h commit 5a023b57a8e96327925a39312bccc443a7c540b6 upstream. Commit 7b6ff0bdbf4f7f429c2116cca92a6d171217449e ("perf probe ppc64le: Fixup function entry if using kallsyms lookup") adds 'struct map' into probe-event.h but not forward declares it. This patch fixes it. Signed-off-by: Wang Nan Cc: Alexei Starovoitov Cc: Brendan Gregg Cc: Daniel Borkmann Cc: David Ahern Cc: He Kuang Cc: Jiri Olsa Cc: Kaixu Xia Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Zefan Li Cc: pi3orama@163.com Fixes: 7b6ff0bdbf4f ("perf probe ppc64le: Fixup function entry if using kallsyms lookup") Link: http://lkml.kernel.org/n/1436445342-1402-30-git-send-email-wangnan0@huawei.com [ No need to include map.h, just forward declare 'struct map' ] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 4a56176e57baefacf1581c6bf1ba0753b5ce55b0 Author: Kan Liang Date: Thu Jul 2 03:08:43 2015 -0400 perf stat: Get correct cpu id for print_aggr commit 601083cffb7cabdcc55b8195d732f0f7028570fa upstream. print_aggr() fails to print per-core/per-socket statistics after commit 582ec0829b3d ("perf stat: Fix per-socket output bug for uncore events") if events have differnt cpus. Because in print_aggr(), aggr_get_id needs index (not cpu id) to find core/pkg id. Also, evsel cpu maps should be used to get aggregated id. Here is an example: Counting events cycles,uncore_imc_0/cas_count_read/. (Uncore event has cpumask 0,18) $ perf stat -e cycles,uncore_imc_0/cas_count_read/ -C0,18 --per-core sleep 2 Without this patch, it failes to get CPU 18 result. Performance counter stats for 'CPU(s) 0,18': S0-C0 1 7526851 cycles S0-C0 1 1.05 MiB uncore_imc_0/cas_count_read/ S1-C0 0 cycles S1-C0 0 MiB uncore_imc_0/cas_count_read/ With this patch, it can get both CPU0 and CPU18 result. Performance counter stats for 'CPU(s) 0,18': S0-C0 1 6327768 cycles S0-C0 1 0.47 MiB uncore_imc_0/cas_count_read/ S1-C0 1 330228 cycles S1-C0 1 0.29 MiB uncore_imc_0/cas_count_read/ Signed-off-by: Kan Liang Acked-by: Jiri Olsa Acked-by: Stephane Eranian Cc: Adrian Hunter Cc: Andi Kleen Cc: David Ahern Cc: Namhyung Kim Cc: Peter Zijlstra Fixes: 582ec0829b3d ("perf stat: Fix per-socket output bug for uncore events") Link: http://lkml.kernel.org/r/1435820925-51091-1-git-send-email-kan.liang@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 1ff3f0cd336a0232894a3aeae92938b0d09816db Author: Arnaldo Carvalho de Melo Date: Mon Aug 10 16:53:54 2015 -0300 perf hists: Update the column width for the "srcline" sort key commit e8e6d37e73e6b950c891c780745460b87f4755b6 upstream. When we introduce a new sort key, we need to update the hists__calc_col_len() function accordingly, otherwise the width will be limited to strlen(header). We can't update it when obtaining a line value for a column (for instance, in sort__srcline_cmp()), because we reset it all when doing a resort (see hists__output_recalc_col_len()), so we need to, from what is in the hist_entry fields, set each of the column widths. Cc: Namhyung Kim Cc: Andi Kleen Cc: Jiri Olsa Fixes: 409a8be61560 ("perf tools: Add sort by src line/number") Link: http://lkml.kernel.org/n/tip-jgbe0yx8v1gs89cslr93pvz2@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 75c0dceaa2c4517d3939a9ee1f64fcc6048c23d8 Author: Stephen Boyd Date: Tue Jul 7 18:16:15 2015 +0100 ARM: 8401/1: perf: Set affinity for PPI based PMUs commit 8ded1e1a92daa96307e4b84b707fee5993bc6047 upstream. For PPI based PMUs, we bail out early in of_pmu_irq_cfg() without setting the PMU's supported_cpus bitmap. This causes the smp_call_function_any() in armv7_probe_num_events() to fail. Set the bitmap to be all CPUs so that we properly probe PMUs that use PPIs. Fixes: cc88116da0d1 ("arm: perf: treat PMUs as CPU affine") Cc: Mark Rutland Signed-off-by: Stephen Boyd Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit dada311c9c207ec55a9a587fe276053dc6798996 Author: Adrian Hunter Date: Thu Sep 24 13:05:22 2015 +0300 perf tools: Fix copying of /proc/kcore commit b5cabbcbd157a4bf5a92dfc85134999a3b55342d upstream. A copy of /proc/kcore containing the kernel text can be made to the buildid cache. e.g. perf buildid-cache -v -k /proc/kcore To workaround objdump limitations, a copy is also made when annotating against /proc/kcore. The copying process stops working from libelf about v1.62 onwards (the problem was found with v1.63). The cause is that a call to gelf_getphdr() in kcore__add_phdr() fails because additional validation has been added to gelf_getphdr(). The use of gelf_getphdr() is a misguided attempt to get default initialization of the Gelf_Phdr structure. That should not be necessary because every member of the Gelf_Phdr structure is subsequently assigned. So just remove the call to gelf_getphdr(). Similarly, a call to gelf_getehdr() in gelf_kcore__init() can be removed also. Committer notes: Note to stable@kernel.org, from Adrian in the cover letter for this patchkit: The "Fix copying of /proc/kcore" problem goes back to v3.13 if you think it is important enough for stable. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Link: http://lkml.kernel.org/r/1443089122-19082-3-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 75928be688c2ba28e41566ba1b9d942f906d90f4 Author: Peter Zijlstra Date: Sat Sep 5 16:55:05 2015 +0200 locking/qspinlock/x86: Only emit the test-and-set fallback when building guest support commit a6b277857fd2c990bc208ca1958d3f34d26052f7 upstream. Only emit the test-and-set fallback for Hypervisors lacking PARAVIRT_SPINLOCKS support when building for guests. Suggested-by: Linus Torvalds Signed-off-by: Peter Zijlstra (Intel) Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 304b8b47da42152baf13fbf73f074db76d970bc9 Author: Peter Zijlstra Date: Fri Sep 4 17:25:23 2015 +0200 locking/qspinlock/x86: Fix performance regression under unaccelerated VMs commit 43b3f02899f74ae9914a39547cc5492156f0027a upstream. Dave ran into horrible performance on a VM without PARAVIRT_SPINLOCKS set and Linus noted that the test-and-set implementation was retarded. One should spin on the variable with a load, not a RMW. While there, remove 'queued' from the name, as the lock isn't queued at all, but a simple test-and-set. Suggested-by: Linus Torvalds Reported-by: Dave Chinner Tested-by: Dave Chinner Signed-off-by: Peter Zijlstra (Intel) Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Waiman Long Link: http://lkml.kernel.org/r/20150904152523.GR18673@twins.programming.kicks-ass.net Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit d78a2be4f9a1b9a31dff96e17d175860c30db4c2 Author: Peter Zijlstra Date: Thu Sep 10 11:58:27 2015 +0200 perf/x86/intel: Fix constraint access commit ebfb4988f0378e2ac3b4a0aa1ea20d724293f392 upstream. Sasha reported that we can get here with .idx==-1, and cpuc->event_constraints unallocated. Suggested-by: Stephane Eranian Reported-by: Sasha Levin Signed-off-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Fixes: b371b5943178 ("perf/x86: Fix event/group validation") Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 23f8f4326a15a7f04656f19fa94aa385eef67e4d Author: Azael Avalos Date: Wed Sep 9 11:25:45 2015 -0600 toshiba_acpi: Fix hotkeys registration on some toshiba models commit 53147b6cabee5e8d1997b5682fcc0c3b72ddf9c2 upstream. Commit a2b3471b5b13 ("toshiba_acpi: Use the Hotkey Event Type function for keymap choosing") changed the *setup_keyboard function to query for the Hotkey Event Type to help choose the correct keymap, but turns out that here are certain Toshiba models out there not implementing this feature, and thus, failing to continue the input device registration and leaving such laptops without hotkey support. This patch changes such check, and instead of returning an error if the Hotkey Event Type is not present, we simply inform userspace about it, changing the message printed from err to notice, making the function responsible for registering the input device to continue. This issue was found on a Toshiba Portege Z30-B, but there might be some other models out there affected by this regression as well. Signed-off-by: Azael Avalos Signed-off-by: Darren Hart Signed-off-by: Greg Kroah-Hartman commit 0404d26f31742bea0f5258c90acd21041b0afa9c Author: Jenny Derzhavetz Date: Sun Sep 6 14:52:21 2015 +0300 iser-target: Put the reference on commands waiting for unsol data commit 3e03c4b01da3e6a5f3081eb0aa252490fe83e352 upstream. The iscsi target core teardown sequence calls wait_conn for all active commands to finish gracefully by: - move the queue-pair to error state - drain all the completions - wait for the core to finish handling all session commands However, when tearing down a session while there are sequenced commands that are still waiting for unsolicited data outs, we can block forever as these are missing an extra reference put. We basically need the equivalent of iscsit_free_queue_reqs_for_conn() which is called after wait_conn has returned. Address this by an explicit walk on conn_cmd_list and put the extra reference. Signed-off-by: Jenny Derzhavetz Signed-off-by: Sagi Grimberg Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 59eb449741154256343fb15f137c26ce7f756759 Author: Jenny Derzhavetz Date: Sun Sep 6 14:52:20 2015 +0300 iser-target: remove command with state ISTATE_REMOVE commit a4c15cd957cbd728f685645de7a150df5912591a upstream. As documented in iscsit_sequence_cmd: /* * Existing callers for iscsit_sequence_cmd() will silently * ignore commands with CMDSN_LOWER_THAN_EXP, so force this * return for CMDSN_MAXCMDSN_OVERRUN as well.. */ We need to silently finish a command when it's in ISTATE_REMOVE. This fixes an teardown hang we were seeing where a mis-behaved initiator (triggered by allocation error injections) sent us a cmdsn which was lower than expected. Signed-off-by: Jenny Derzhavetz Signed-off-by: Sagi Grimberg Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 13d7eec73c169367ba33d8a08882ff42cb62d2a3 Author: Nicholas Bellinger Date: Sun Sep 13 02:30:46 2015 -0700 target: Fix PR registration + APTPL RCU conversion regression commit 3ccd6e83df8a0d4a664edeecc453c4fa046395fb upstream. This patch fixes a v4.2+ regression introduced by commit 79dc9c9e86 where lookup of t10_pr_registration->pr_reg_deve and associated ->pr_kref get was missing from __core_scsi3_do_alloc_registration(), which is responsible for setting DEF_PR_REG_ACTIVE. This would result in REGISTER operations completing successfully, but subsequent core_scsi3_pr_seq_non_holder() checking would fail with !DEF_PR_REG_ACTIVE -> RESERVATION CONFLICT status. Update __core_scsi3_add_registration() to drop ->pr_kref reference after registration and any optional ALL_TG_PT=1 processing has completed. Update core_scsi3_decode_spec_i_port() to release the new parent local_pr_reg->pr_kref as well. Also, update __core_scsi3_check_aptpl_registration() to perform the same target_nacl_find_deve() lookup + ->pr_kref get, now that __core_scsi3_add_registration() expects to drop the reference. Finally, since there are cases when se_dev_entry->se_lun_acl can still be dereferenced in core_scsi3_lunacl_undepend_item() while holding ->pr_kref, go ahead and move explicit rcu_assign_pointer() NULL assignments within core_disable_device_list_for_node() until after orig->pr_comp finishes. Reported-by: Scott L. Lykens Tested-by: Scott L. Lykens Cc: Christoph Hellwig Cc: Hannes Reinecke Cc: Lee Duncan Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit a361b8fa5e1b7bf1dd05b3a68f133433ea945a77 Author: Nicholas Bellinger Date: Thu Sep 3 06:30:45 2015 +0000 target: Attach EXTENDED_COPY local I/O descriptors to xcopy_pt_sess commit 4416f89b8cfcb794d040fc3b68e5fb159b7d8d02 upstream. This patch is a >= v4.1 regression bug-fix where control CDB emulation logic in commit 38b57f82 now expects a se_cmd->se_sess pointer to exist when determining T10-PI support is to be exposed for initiator host ports. To address this bug, go ahead and add locally generated se_cmd descriptors for copy-offload block-copy to it's own stand-alone se_session nexus, while the parent EXTENDED_COPY se_cmd descriptor remains associated with it's originating se_cmd->se_sess nexus. Note a valid se_cmd->se_sess is also required for future support of WRITE_INSERT and READ_STRIP software emulation when submitting backend I/O to se_device that exposes T10-PI suport. Reported-by: Alex Gorbachev Tested-by: Alex Gorbachev Cc: "Martin K. Petersen" Cc: Hannes Reinecke Cc: Christoph Hellwig Cc: Doug Gilbert Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 4a248398eb8fab3b85bda9ba59a7834ea124a367 Author: Michal Hocko Date: Thu Aug 27 20:16:37 2015 +0200 scsi: fix scsi_error_handler vs. scsi_host_dev_release race commit 537b604c8b3aa8b96fe35f87dd085816552e294c upstream. b9d5c6b7ef57 ("[SCSI] cleanup setting task state in scsi_error_handler()") has introduced a race between scsi_error_handler and scsi_host_dev_release resulting in the hang when the device goes away because scsi_error_handler might miss a wake up: CPU0 CPU1 scsi_error_handler scsi_host_dev_release kthread_stop() kthread_should_stop() test_bit(KTHREAD_SHOULD_STOP) set_bit(KTHREAD_SHOULD_STOP) wake_up_process() wait_for_completion() set_current_state(TASK_INTERRUPTIBLE) schedule() The most straightforward solution seems to be to invert the ordering of the set_current_state and kthread_should_stop. The issue has been noticed during reboot test on a 3.0 based kernel but the current code seems to be affected in the same way. [jejb: additional comment added] Reported-and-debugged-by: Mike Mayer Signed-off-by: Michal Hocko Reviewed-by: Dan Williams Reviewed-by: Hannes Reinecke Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 0df8a7a1a277c20fa8e55afbdbdacd7eb7c2aed4 Author: Andy Grover Date: Mon Aug 24 10:26:03 2015 -0700 target/iscsi: Fix np_ip bracket issue by removing np_ip commit 76c28f1fcfeb42b47f798fe498351ee1d60086ae upstream. Revert commit 1997e6259, which causes double brackets on ipv6 inaddr_any addresses. Since we have np_sockaddr, if we need a textual representation we can use "%pISc". Change iscsit_add_network_portal() and iscsit_add_np() signatures to remove *ip_str parameter. Fix and extend some comments earlier in the function. Tested to work for :: and ::1 via iscsiadm, previously :: failed, see https://bugzilla.redhat.com/show_bug.cgi?id=1249107 . Signed-off-by: Andy Grover Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit d6402e4ecf0d9a3ec9ceee9d218dcc7605611df7 Author: John Stultz Date: Wed Sep 9 16:07:30 2015 -0700 time: Fix timekeeping_freqadjust()'s incorrect use of abs() instead of abs64() commit 2619d7e9c92d524cb155ec89fd72875321512e5b upstream. The internal clocksteering done for fine-grained error correction uses a logarithmic approximation, so any time adjtimex() adjusts the clock steering, timekeeping_freqadjust() quickly approximates the correct clock frequency over a series of ticks. Unfortunately, the logic in timekeeping_freqadjust(), introduced in commit: dc491596f639 ("timekeeping: Rework frequency adjustments to work better w/ nohz") used the abs() function with a s64 error value to calculate the size of the approximated adjustment to be made. Per include/linux/kernel.h: "abs() should not be used for 64-bit types (s64, u64, long long) - use abs64()". Thus on 32-bit platforms, this resulted in the clocksteering to take a quite dampended random walk trying to converge on the proper frequency, which caused the adjustments to be made much slower then intended (most easily observed when large adjustments are made). This patch fixes the issue by using abs64() instead. Reported-by: Nuno Gonçalves Tested-by: Nuno Goncalves Signed-off-by: John Stultz Cc: Linus Torvalds Cc: Miroslav Lichvar Cc: Peter Zijlstra Cc: Prarit Bhargava Cc: Richard Cochran Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1441840051-20244-1-git-send-email-john.stultz@linaro.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 1ac987c5e08c42111fc8b81588cbf20a22c2e5bf Author: Paolo Bonzini Date: Thu Oct 1 13:28:15 2015 +0200 Revert "KVM: SVM: Sync g_pat with guest-written PAT value" commit 625422f60c55bbc368b8568ff925770b36bfc189 upstream. This reverts commit e098223b789b4a618dacd79e5e0dad4a9d5018d1, which has a dependency on other commits being reverted. Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit f943aa539655aa7105c0737791e39d09c5d9bb59 Author: Paolo Bonzini Date: Thu Oct 1 13:20:22 2015 +0200 Revert "KVM: SVM: use NPT page attributes" commit fc07e76ac7ffa3afd621a1c3858a503386a14281 upstream. This reverts commit 3c2e7f7de3240216042b61073803b61b9b3cfb22. Initializing the mapping from MTRR to PAT values was reported to fail nondeterministically, and it also caused extremely slow boot (due to caching getting disabled---bug 103321) with assigned devices. Reported-by: Markus Trippelsdorf Reported-by: Sebastian Schuette Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 98eee9987abe51a260ad8b521c33205ce8ea0028 Author: Paolo Bonzini Date: Thu Oct 1 13:12:47 2015 +0200 Revert "KVM: x86: apply guest MTRR virtualization on host reserved pages" commit 606decd67049217684e3cb5a54104d51ddd4ef35 upstream. This reverts commit fd717f11015f673487ffc826e59b2bad69d20fe5. It was reported to cause Machine Check Exceptions (bug 104091). Reported-by: harn-solo@gmx.de Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit eec2b28cfed52a1154ee6b8577bc1464c03b0838 Author: Gautham R. Shenoy Date: Thu May 21 13:57:04 2015 +0530 KVM: PPC: Book3S HV: Pass the correct trap argument to kvmhv_commence_exit commit 7e022e717f54897e396504306d0c9b61452adf4e upstream. In guest_exit_cont we call kvmhv_commence_exit which expects the trap number as the argument. However r3 doesn't contain the trap number at this point and as a result we would be calling the function with a spurious trap number. Fix this by copying r12 into r3 before calling kvmhv_commence_exit as r12 contains the trap number. Fixes: eddb60fb1443 Signed-off-by: Gautham R. Shenoy Signed-off-by: Paul Mackerras Signed-off-by: Greg Kroah-Hartman commit 1f3de4fb018fd8f8bff252128b1b8270f10f21e9 Author: Thomas Huth Date: Fri Sep 18 08:57:28 2015 +0200 KVM: PPC: Book3S: Take the kvm->srcu lock in kvmppc_h_logical_ci_load/store() commit 3eb4ee68254235e4f47bc0410538fcdaede39589 upstream. Access to the kvm->buses (like with the kvm_io_bus_read() and -write() functions) has to be protected via the kvm->srcu lock. The kvmppc_h_logical_ci_load() and -store() functions are missing this lock so far, so let's add it there, too. This fixes the problem that the kernel reports "suspicious RCU usage" when lock debugging is enabled. Fixes: 99342cf8044420eebdf9297ca03a14cb6a7085a1 Signed-off-by: Thomas Huth Signed-off-by: Paul Mackerras Signed-off-by: Greg Kroah-Hartman commit 76eaee10fb38ace8d4e0741cd27731bc11333fd8 Author: Paolo Bonzini Date: Fri Sep 18 17:33:04 2015 +0200 KVM: x86: trap AMD MSRs for the TSeg base and mask commit 3afb1121800128aae9f5722e50097fcf1a9d4d88 upstream. These have roughly the same purpose as the SMRR, which we do not need to implement in KVM. However, Linux accesses MSR_K8_TSEG_ADDR at boot, which causes problems when running a Xen dom0 under KVM. Just return 0, meaning that processor protection of SMRAM is not in effect. Reported-by: M A Young Acked-by: Borislav Petkov Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 6742cc7c113389eec23acbef066e14b6823f690c Author: Igor Mammedov Date: Fri Sep 18 15:39:05 2015 +0200 kvm: svm: reset mmu on VCPU reset commit ebae871a509d3c24b32ff67af2671dadffc58770 upstream. When INIT/SIPI sequence is sent to VCPU which before that was in use by OS, VMRUN might fail with: KVM: entry failed, hardware error 0xffffffff EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006d3 ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 EIP=00000000 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0000 00000000 0000ffff 00009300 CS =9a00 0009a000 0000ffff 00009a00 [...] CR0=60000010 CR2=b6f3e000 CR3=01942000 CR4=000007e0 [...] EFER=0000000000000000 with corresponding SVM error: KVM: FAILED VMRUN WITH VMCB: [...] cpl: 0 efer: 0000000000001000 cr0: 0000000080010010 cr2: 00007fd7fe85bf90 cr3: 0000000187d0c000 cr4: 0000000000000020 [...] What happens is that VCPU state right after offlinig: CR0: 0x80050033 EFER: 0xd01 CR4: 0x7e0 -> long mode with CR3 pointing to longmode page tables and when VCPU gets INIT/SIPI following transition happens CR0: 0 -> 0x60000010 EFER: 0x0 CR4: 0x7e0 -> paging disabled with stale CR3 However SVM under the hood puts VCPU in Paged Real Mode* which effectively translates CR0 0x60000010 -> 80010010 after svm_vcpu_reset() -> init_vmcb() -> kvm_set_cr0() -> svm_set_cr0() but from kvm_set_cr0() perspective CR0: 0 -> 0x60000010 only caching bits are changed and commit d81135a57aa6 ("KVM: x86: do not reset mmu if CR0.CD and CR0.NW are changed")' regressed svm_vcpu_reset() which relied on MMU being reset. As result VMRUN after svm_vcpu_reset() tries to run VCPU in Paged Real Mode with stale MMU context (longmode page tables), which causes some AMD CPUs** to bail out with VMEXIT_INVALID. Fix issue by unconditionally resetting MMU context at init_vmcb() time. * AMD64 Architecture Programmer’s Manual, Volume 2: System Programming, rev: 3.25 15.19 Paged Real Mode ** Opteron 1216 Signed-off-by: Igor Mammedov Fixes: d81135a57aa6 Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 9d7fc3585ec82c19b5265c903ad9ebb143adde2a Author: Marc Zyngier Date: Wed Sep 16 16:18:59 2015 +0100 arm: KVM: Disable virtual timer even if the guest is not using it commit 688bc577ac42ae3d07c889a1f0a72f0b23763d58 upstream. When running a guest with the architected timer disabled (with QEMU and the kernel_irqchip=off option, for example), it is important to make sure the timer gets turned off. Otherwise, the guest may try to enable it anyway, leading to a screaming HW interrupt. The fix is to unconditionally turn off the virtual timer on guest exit. Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 2ab32d6d34b15a6e058507ec387b3435774258ed Author: Jason Wang Date: Tue Sep 15 14:41:56 2015 +0800 kvm: fix double free for fast mmio eventfd commit eefd6b06b17c5478e7c24bea6f64beaa2c431ca6 upstream. We register wildcard mmio eventfd on two buses, once for KVM_MMIO_BUS and once on KVM_FAST_MMIO_BUS but with a single iodev instance. This will lead to an issue: kvm_io_bus_destroy() knows nothing about the devices on two buses pointing to a single dev. Which will lead to double free[1] during exit. Fix this by allocating two instances of iodevs then registering one on KVM_MMIO_BUS and another on KVM_FAST_MMIO_BUS. CPU: 1 PID: 2894 Comm: qemu-system-x86 Not tainted 3.19.0-26-generic #28-Ubuntu Hardware name: LENOVO 2356BG6/2356BG6, BIOS G7ET96WW (2.56 ) 09/12/2013 task: ffff88009ae0c4b0 ti: ffff88020e7f0000 task.ti: ffff88020e7f0000 RIP: 0010:[] [] ioeventfd_release+0x28/0x60 [kvm] RSP: 0018:ffff88020e7f3bc8 EFLAGS: 00010292 RAX: dead000000200200 RBX: ffff8801ec19c900 RCX: 000000018200016d RDX: ffff8801ec19cf80 RSI: ffffea0008bf1d40 RDI: ffff8801ec19c900 RBP: ffff88020e7f3bd8 R08: 000000002fc75a01 R09: 000000018200016d R10: ffffffffc07df6ae R11: ffff88022fc75a98 R12: ffff88021e7cc000 R13: ffff88021e7cca48 R14: ffff88021e7cca50 R15: ffff8801ec19c880 FS: 00007fc1ee3e6700(0000) GS:ffff88023e240000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8f389d8000 CR3: 000000023dc13000 CR4: 00000000001427e0 Stack: ffff88021e7cc000 0000000000000000 ffff88020e7f3be8 ffffffffc07e2622 ffff88020e7f3c38 ffffffffc07df69a ffff880232524160 ffff88020e792d80 0000000000000000 ffff880219b78c00 0000000000000008 ffff8802321686a8 Call Trace: [] ioeventfd_destructor+0x12/0x20 [kvm] [] kvm_put_kvm+0xca/0x210 [kvm] [] kvm_vcpu_release+0x18/0x20 [kvm] [] __fput+0xe7/0x250 [] ____fput+0xe/0x10 [] task_work_run+0xd4/0xf0 [] do_exit+0x368/0xa50 [] ? recalc_sigpending+0x1f/0x60 [] do_group_exit+0x45/0xb0 [] get_signal+0x291/0x750 [] do_signal+0x28/0xab0 [] ? do_futex+0xdb/0x5d0 [] ? __wake_up_locked_key+0x18/0x20 [] ? SyS_futex+0x76/0x170 [] do_notify_resume+0x69/0xb0 [] int_signal+0x12/0x17 Code: 5d c3 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb 48 83 ec 08 48 8b 7f 20 e8 06 d6 a5 c0 48 8b 43 08 48 8b 13 48 89 df 48 89 42 08 <48> 89 10 48 b8 00 01 10 00 00 RIP [] ioeventfd_release+0x28/0x60 [kvm] RSP Cc: Gleb Natapov Cc: Paolo Bonzini Signed-off-by: Jason Wang Reviewed-by: Cornelia Huck Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 141bdd6ab3f68dee0941979765a698e6a9971111 Author: Jason Wang Date: Tue Sep 15 14:41:55 2015 +0800 kvm: factor out core eventfd assign/deassign logic commit 85da11ca587c8eb73993a1b503052391a73586f9 upstream. This patch factors out core eventfd assign/deassign logic and leaves the argument checking and bus index selection to callers. Cc: Gleb Natapov Cc: Paolo Bonzini Signed-off-by: Jason Wang Reviewed-by: Cornelia Huck Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 9efaf0e7a4c97320044a4fa43b411e269bb2a78f Author: Jason Wang Date: Tue Sep 15 14:41:57 2015 +0800 kvm: fix zero length mmio searching commit 8f4216c7d28976f7ec1b2bcbfa0a9f787133c45e upstream. Currently, if we had a zero length mmio eventfd assigned on KVM_MMIO_BUS. It will never be found by kvm_io_bus_cmp() since it always compares the kvm_io_range() with the length that guest wrote. This will cause e.g for vhost, kick will be trapped by qemu userspace instead of vhost. Fixing this by using zero length if an iodevice is zero length. Cc: Gleb Natapov Cc: Paolo Bonzini Signed-off-by: Jason Wang Reviewed-by: Cornelia Huck Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 0986ae9a1160edb74b0b75f591296f508e44f8e0 Author: Jason Wang Date: Tue Sep 15 14:41:54 2015 +0800 kvm: don't try to register to KVM_FAST_MMIO_BUS for non mmio eventfd commit 8453fecbecae26edb3f278627376caab05d9a88d upstream. We only want zero length mmio eventfd to be registered on KVM_FAST_MMIO_BUS. So check this explicitly when arg->len is zero to make sure this. Cc: Gleb Natapov Cc: Paolo Bonzini Signed-off-by: Jason Wang Reviewed-by: Cornelia Huck Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit f9f83f3cfce00b9b862620f77b2809d13771a37b Author: Wanpeng Li Date: Wed Sep 16 19:31:11 2015 +0800 KVM: vmx: fix VPID is 0000H in non-root operation commit 04bb92e4b4cf06a66889d37b892b78f926faa9d4 upstream. Reference SDM 28.1: The current VPID is 0000H in the following situations: - Outside VMX operation. (This includes operation in system-management mode under the default treatment of SMIs and SMM with VMX operation; see Section 34.14.) - In VMX root operation. - In VMX non-root operation when the “enable VPID” VM-execution control is 0. The VPID should never be 0000H in non-root operation when "enable VPID" VM-execution control is 1. However, commit 34a1cd60 ("kvm: x86: vmx: move some vmx setting from vmx_init() to hardware_setup()") remove the codes which reserve 0000H for VMX root operation. This patch fix it by again reserving 0000H for VMX root operation. Fixes: 34a1cd60d17f62c1f077c1478a6c2ca8c3d17af4 Reported-by: Wincy Van Signed-off-by: Wanpeng Li Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 91e4921b5e8b189723916f616664f809d15f3025 Author: Marek Majtyka Date: Wed Sep 16 12:04:55 2015 +0200 arm: KVM: Fix incorrect device to IPA mapping commit ca09f02f122b2ecb0f5ddfc5fd47b29ed657d4fd upstream. A critical bug has been found in device memory stage1 translation for VMs with more then 4GB of address space. Once vm_pgoff size is smaller then pa (which is true for LPAE case, u32 and u64 respectively) some more significant bits of pa may be lost as a shift operation is performed on u32 and later cast onto u64. Example: vm_pgoff(u32)=0x00210030, PAGE_SHIFT=12 expected pa(u64): 0x0000002010030000 produced pa(u64): 0x0000000010030000 The fix is to change the order of operations (casting first onto phys_addr_t and then shifting). Reviewed-by: Marc Zyngier [maz: fixed changelog and patch formatting] Signed-off-by: Marek Majtyka Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman