commit 1c02865136fee1d10d434dc9e3616c8e39905e9b Author: Greg Kroah-Hartman Date: Mon Nov 9 14:37:56 2015 -0800 Linux 4.2.6 commit 14337b1542a958346db1a06948c26091a650265d Author: Greg Kroah-Hartman Date: Fri Nov 6 11:07:07 2015 -0800 xen: fix backport of previous kexec patch Fixes the backport of 0b34a166f291d255755be46e43ed5497cdd194f2 upstream Commit 0b34a166f291d255755be46e43ed5497cdd194f2 "x86/xen: Support kexec/kdump in HVM guests by doing a soft reset" has been added to the 4.2-stable tree" needed to correct the CONFIG variable, as CONFIG_KEXEC_CORE only showed up in 4.3. Reported-by: David Vrabel Reported-by: Luis Henriques Signed-off-by: Greg Kroah-Hartman commit 4f2b300b74c6a9c99c7e8cf9f2d46bc3cab67e0e Author: Mika Westerberg Date: Mon Aug 17 16:03:17 2015 +0300 pinctrl: baytrail: Use raw_spinlock for locking commit 78e1c896932df5b8bcdff7bf5417d8e72a4d0d6b upstream. The Intel Baytrail pinctrl driver implements irqchip callbacks which are called with desc->lock raw_spinlock held. In mainline this is fine because spinlock resolves to raw_spinlock. However, running the same code in -rt we get: BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917 in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/0 Preemption disabled at:[] cpu_startup_entry+0x17f/0x480 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.5-rt5 #13 ... Call Trace: [] dump_stack+0x4a/0x61 [] ___might_sleep+0xe7/0x170 [] rt_spin_lock+0x1f/0x50 [] byt_gpio_clear_triggering+0x38/0x60 [] byt_irq_mask+0x11/0x20 [] handle_level_irq+0x83/0x150 [] generic_handle_irq+0x27/0x40 [] byt_gpio_irq_handler+0x7f/0xc0 [] handle_irq+0xaa/0x190 ... This is because in -rt spinlocks are preemptible so taking the driver private spinlock in irqchip callbacks causes might_sleep() to trigger. In order to keep -rt happy but at the same time make sure that register accesses get serialized, convert the driver to use raw_spinlock instead. Also shorten the critical section a bit in few places. Suggested-by: Linus Walleij Signed-off-by: Mika Westerberg Signed-off-by: Linus Walleij Cc: Lucas De Marchi Signed-off-by: Greg Kroah-Hartman commit fd35a6831470f2a238b51f8c940a17c9f9b25fc4 Author: Mika Westerberg Date: Tue Aug 4 15:03:14 2015 +0300 pinctrl: baytrail: Serialize all register access commit 39ce8150a079e3ae6ed9abf26d7918a558ef7c19 upstream. There is a hardware issue in Intel Baytrail where concurrent GPIO register access might result reads of 0xffffffff and writes might get dropped completely. Prevent this from happening by taking the serializing lock in all places where it is possible that more than one thread might be accessing the hardware concurrently. Signed-off-by: Mika Westerberg Signed-off-by: Linus Walleij Cc: Lucas De Marchi Signed-off-by: Greg Kroah-Hartman commit eda9ff7378eafa57603efc19a0312ef5b2142124 Author: Minchan Kim Date: Thu Oct 22 13:32:19 2015 -0700 thp: use is_zero_pfn() only after pte_present() check commit 47aee4d8e314384807e98b67ade07f6da476aa75 upstream. Use is_zero_pfn() on pteval only after pte_present() check on pteval (It might be better idea to introduce is_zero_pte() which checks pte_present() first). Otherwise when working on a swap or migration entry and if pte_pfn's result is equal to zero_pfn by chance, we lose user's data in __collapse_huge_page_copy(). So if you're unlucky, the application segfaults and finally you could see below message on exit: BUG: Bad rss-counter state mm:ffff88007f099300 idx:2 val:3 Fixes: ca0984caa823 ("mm: incorporate zero pages into transparent huge pages") Signed-off-by: Minchan Kim Reviewed-by: Andrea Arcangeli Acked-by: Kirill A. Shutemov Cc: Mel Gorman Acked-by: Vlastimil Babka Cc: Hugh Dickins Cc: Rik van Riel Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 683b2b86aceed0df49641a1c34d56da7aa104823 Author: Thomas Hellstrom Date: Mon Sep 14 01:13:11 2015 -0700 drm/vmwgfx: Fix up user_dmabuf refcounting commit 54c12bc374408faddbff75dbf1a6167c19af39c4 upstream. If user space calls unreference on a user_dmabuf it will typically kill the struct ttm_base_object member which is responsible for the user-space visibility. However the dmabuf part may still be alive and refcounted. In some situations, like for shared guest-backed surface referencing/opening, the driver may try to reference the struct ttm_base_object member again, causing an immediate kernel warning and a later kernel NULL pointer dereference. Fix this by always maintaining a reference on the struct ttm_base_object member, in situations where it might subsequently be referenced. Signed-off-by: Thomas Hellstrom Reviewed-by: Brian Paul Reviewed-by: Sinclair Yeh Signed-off-by: Greg Kroah-Hartman commit 314679759449db760dabe09127ac1ed348e43798 Author: Keith Busch Date: Thu Oct 15 13:38:48 2015 -0600 NVMe: Fix memory leak on retried commands commit 0dfc70c33409afc232ef0b9ec210535dfbf9bc61 upstream. Resources are reallocated for requeued commands, so unmap and release the iod for the failed command. It's a pretty bad memory leak and causes a kernel hang if you remove a drive because of a busy dma pool. You'll get messages spewing like this: nvme 0000:xx:xx.x: dma_pool_destroy prp list 256, ffff880420dec000 busy and lock up pci and the driver since removal never completes while holding a lock. Signed-off-by: Keith Busch Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 5ce538743aafc5aef4775ae6e8aed57e23d5e40b Author: Will Deacon Date: Thu Oct 15 13:55:53 2015 +0100 arm64: compat: fix stxr failure case in SWP emulation commit 589cb22bbedacf325951014c07a35a2b01ca57f6 upstream. If the STXR instruction fails in the SWP emulation code, we leave *data overwritten with the loaded value, therefore corrupting the data written by a subsequent, successful attempt. This patch re-jigs the code so that we only write back to *data once we know that the update has happened. Fixes: bd35a4adc413 ("arm64: Port SWP/SWPB emulation support from arm") Reported-by: Shengjiu Wang Reported-by: Vladimir Murzin Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit a7e19859f9fd6eb9e5a11e5645fe42082df40d8a Author: Srinivas Pandruvada Date: Thu Oct 15 12:34:21 2015 -0700 cpufreq: intel_pstate: Fix divide by zero on Knights Landing (KNL) commit 8e601a9f97a00bab031980de34f9a81891c1f82f upstream. This is a workaround for KNL platform, where in some cases MPERF counter will not have updated value before next read of MSR_IA32_MPERF. In this case divide by zero will occur. This change ignores current sample for busy calculation in this case. Fixes: b34ef932d79a (intel_pstate: Knights Landing support) Signed-off-by: Srinivas Pandruvada Acked-by: Kristen Carlson Accardi Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 784e618742264266c0501cf5db0c9244d7359cff Author: Luca Abeni Date: Fri Oct 16 10:06:21 2015 +0200 sched/deadline: Fix migration of SCHED_DEADLINE tasks commit 5aa5050787f449e7eaef2c5ec93c7b357aa7dcdc upstream. Commit: 9d5142624256 ("sched/deadline: Reduce rq lock contention by eliminating locking of non-feasible target") broke select_task_rq_dl() and find_lock_later_rq(), because it introduced a comparison between the local task's deadline and dl.earliest_dl.curr of the remote queue. However, if the remote runqueue does not contain any SCHED_DEADLINE task its earliest_dl.curr is 0 (always smaller than the deadline of the local task) and the remote runqueue is not selected for pushing. As a result, if an application creates multiple SCHED_DEADLINE threads, they will never be pushed to runqueues that do not already contain SCHED_DEADLINE tasks. This patch fixes the issue by checking if dl.dl_nr_running == 0. Signed-off-by: Luca Abeni Signed-off-by: Peter Zijlstra (Intel) Cc: Juri Lelli Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Wanpeng Li Fixes: 9d5142624256 ("sched/deadline: Reduce rq lock contention by eliminating locking of non-feasible target") Link: http://lkml.kernel.org/r/1444982781-15608-1-git-send-email-luca.abeni@unitn.it Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit bc1562f965b005090f7ac4e9e047e63eda47ecc9 Author: Doron Tsur Date: Sun Oct 11 15:58:17 2015 +0300 IB/cm: Fix rb-tree duplicate free and use-after-free commit 0ca81a2840f77855bbad1b9f172c545c4dc9e6a4 upstream. ib_send_cm_sidr_rep could sometimes erase the node from the sidr (depending on errors in the process). Since ib_send_cm_sidr_rep is called both from cm_sidr_req_handler and cm_destroy_id, cm_id_priv could be either erased from the rb_tree twice or not erased at all. Fixing that by making sure it's erased only once before freeing cm_id_priv. Fixes: a977049dacde ('[PATCH] IB: Add the kernel CM implementation') Signed-off-by: Doron Tsur Signed-off-by: Matan Barak Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 39caa731fbb5bfb5cf376a18dcc63a3a0a69ee27 Author: Junichi Nomura Date: Wed Oct 14 05:02:15 2015 +0000 blk-mq: fix use-after-free in blk_mq_free_tag_set() commit f42d79ab67322e51b92dd7aa965e310c71352a64 upstream. tags is freed in blk_mq_free_rq_map() and should not be used after that. The problem doesn't manifest if CONFIG_CPUMASK_OFFSTACK is false because free_cpumask_var() is nop. tags->cpumask is allocated in blk_mq_init_tags() so it's natural to free cpumask in its counter part, blk_mq_free_tags(). Fixes: f26cdc8536ad ("blk-mq: Shared tag enhancements") Signed-off-by: Jun'ichi Nomura Cc: Keith Busch Reviewed-by: Jeff Moyer Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit ce446155fcad2baa03acd62199f6655170e09de7 Author: Richard Weinberger Date: Sun Aug 9 22:26:33 2015 +0200 um: Fix kernel mode fault condition commit 56b88a3bf97a39d3f4f010509917b76a865a6dc8 upstream. We have to exclude memory locations <= PAGE_SIZE from the condition and let the kernel mode fault path catch it. Otherwise a kernel NULL pointer exception will be reported as a kernel user space access. Fixes: d2313084e2c (um: Catch unprotected user memory access) Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit fec1757674de2c48bb8b4365785f6317d6e0915b Author: Sudip Mukherjee Date: Sat Oct 17 08:08:56 2015 +0900 thermal: exynos: Fix register read in TMU commit b28fec1324bf8f5010d2c3c5d57db4115bda66d4 upstream. The value of emul_con was getting overwritten if the selected soc is SOC_ARCH_EXYNOS5260. And so as a result we were reading from the wrong register in the case of SOC_ARCH_EXYNOS5260. Fixes: 488c7455d74c ("thermal: exynos: Add the support for Exynos5433 TMU") Signed-off-by: Sudip Mukherjee Reviewed-by: Krzysztof Kozlowski Reviewed-by: Chanwoo Choi Acked-by: Lukasz Majewski Signed-off-by: Krzysztof Kozlowski Signed-off-by: Kukjin Kim Signed-off-by: Greg Kroah-Hartman commit 1ce8b6bd3f9f77c49908e9391ebc72114a65fc97 Author: Sudip Mukherjee Date: Wed Sep 2 12:33:53 2015 +0530 kvm: irqchip: fix memory leak commit ba60c41ae392b473a1897faa0b8739fcb8759d69 upstream. We were taking the exit path after checking ue->flags and return value of setup_routing_entry(), but 'e' was not freed incase of a failure. Signed-off-by: Sudip Mukherjee Signed-off-by: Paolo Bonzini Cc: William Dauchy Signed-off-by: Greg Kroah-Hartman commit d61504b9fd2de498b0412abac8560c451a858f08 Author: Christian Engelmayer Date: Wed Oct 21 00:50:06 2015 +0200 btrfs: fix possible leak in btrfs_ioctl_balance() commit 0f89abf56abbd0e1c6e3cef9813e6d9f05383c1e upstream. Commit 8eb934591f8b ("btrfs: check unsupported filters in balance arguments") adds a jump to exit label out_bargs in case the argument check fails. At this point in addition to the bargs memory, the memory for struct btrfs_balance_control has already been allocated. Ownership of bctl is passed to btrfs_balance() in the good case, thus the memory is not freed due to the introduced jump. Make sure that the memory gets freed in any case as necessary. Detected by Coverity CID 1328378. Signed-off-by: Christian Engelmayer Reviewed-by: David Sterba Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit e7bbf66da1b3be2626965afdcdac9bc44d26f485 Author: Nikolay Borisov Date: Fri Oct 16 09:40:28 2015 +0300 netfilter: ipset: Fix sleeping memory allocation in atomic context commit 00db674bedd68ff8b5afae9030ff5e04d45d1b4a upstream. Commit 00590fdd5be0 introduced RCU locking in list type and in doing so introduced a memory allocation in list_set_add, which is done in an atomic context, due to the fact that ipset rcu list modifications are serialised with a spin lock. The reason why we can't use a mutex is that in addition to modifying the list with ipset commands, it's also being modified when a particular ipset rule timeout expires aka garbage collection. This gc is triggered from set_cleanup_entries, which in turn is invoked from a timer thus requiring the lock to be bh-safe. Concretely the following call chain can lead to "sleeping function called in atomic context" splat: call_ad -> list_set_uadt -> list_set_uadd -> kzalloc(, GFP_KERNEL). And since GFP_KERNEL allows initiating direct reclaim thus potentially sleeping in the allocation path. To fix the issue change the allocation type to GFP_ATOMIC, to correctly reflect that it is occuring in an atomic context. Fixes: 00590fdd5be0 ("netfilter: ipset: Introduce RCU locking in list type") Signed-off-by: Nikolay Borisov Acked-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 30be9bc4ae69a894b38cbcbb5d1bdf99561b9e13 Author: Dāvis Mosāns Date: Fri Aug 21 07:29:22 2015 +0300 mvsas: Fix NULL pointer dereference in mvs_slot_task_free commit 2280521719e81919283b82902ac24058f87dfc1b upstream. When pci_pool_alloc fails in mvs_task_prep then task->lldd_task stays NULL but it's later used in mvs_abort_task as slot which is passed to mvs_slot_task_free causing NULL pointer dereference. Just return from mvs_slot_task_free when passed with NULL slot. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101891 Signed-off-by: Dāvis Mosāns Reviewed-by: Tomas Henzl Reviewed-by: Johannes Thumshirn Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit f3b1ffbea8c8f30134d248bb24e052ac68ac0273 Author: Lucas Stach Date: Sun Oct 25 16:39:12 2015 +0100 irqchip/tegra: Propagate IRQ type setting to parent commit 209da39154837ec1b69fb34f438041939911e4b4 upstream. The LIC doesn't deal with the different types of interrupts itself but needs to forward calls to set the appropriate type to its parent IRQ controller. Without this fix all IRQs routed through the LIC will stay at the initial EDGE type, while most of them should actually be level triggered. Fixes: 1eec582158e2 "irqchip: tegra: Add Tegra210 support" Signed-off-by: Lucas Stach Cc: Stephen Warren Cc: Thierry Reding Cc: Alexandre Courbot Cc: Jason Cooper Cc: Marc Zyngier Link: http://lkml.kernel.org/r/1445787552-13062-1-git-send-email-dev@lynxeye.de Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 362e91b58e621e61ebc05c0864b2cf45e91dd6e7 Author: Seth Jennings Date: Wed Aug 5 13:16:01 2015 -0500 EDAC, sb_edac: Fix TAD presence check for sbridge_mci_bind_devs() commit 2900ea609616c2651dec65312beeb2a6e536bc50 upstream. In commit 7d375bffa524 ("sb_edac: Fix support for systems with two home agents per socket") NUM_CHANNELS was changed to 8 and the channel space was renumerated to handle EN, EP, and EX configurations. The *_mci_bind_devs() functions - except for sbridge_mci_bind_devs() - got a new device presence check in the form of saw_chan_mask. However, sbridge_mci_bind_devs() still uses the NUM_CHANNELS for loop. With the increase in NUM_CHANNELS, this loop fails at index 4 since SB only has 4 TADs. This results in the following error on SB machines: EDAC sbridge: Some needed devices are missing EDAC sbridge: Couldn't find mci handler EDAC sbridge: Couldn't find mci handle This patch adapts the saw_chan_mask logic for sbridge_mci_bind_devs() as well. After this patch: EDAC MC0: Giving out device to module sbridge_edac.c controller Sandy Bridge Socket#0: DEV 0000:3f:0e.0 (POLLED) EDAC MC1: Giving out device to module sbridge_edac.c controller Sandy Bridge Socket#1: DEV 0000:7f:0e.0 (POLLED) Signed-off-by: Seth Jennings Acked-by: Aristeu Rozanski Acked-by: Tony Luck Tested-by: Borislav Petkov Cc: Mauro Carvalho Chehab Cc: linux-edac Link: http://lkml.kernel.org/r/1438798561-10180-1-git-send-email-sjenning@redhat.com Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman commit 48f93eaae7ba01f1e751436715cbb586d2abff65 Author: NeilBrown Date: Sat Oct 31 11:00:56 2015 +1100 Revert "md: allow a partially recovered device to be hot-added to an array." commit d01552a76d71f9879af448e9142389ee9be6e95b upstream. This reverts commit 7eb418851f3278de67126ea0c427641ab4792c57. This commit is poorly justified, I can find not discusison in email, and it clearly causes a problem. If a device which is being recovered fails and is subsequently re-added to an array, there could easily have been changes to the array *before* the point where the recovery was up to. So the recovery must start again from the beginning. If a spare is being recovered and fails, then when it is re-added we really should do a bitmap-based recovery up to the recovery-offset, and then a full recovery from there. Before this reversion, we only did the "full recovery from there" which is not corect. After this reversion with will do a full recovery from the start, which is safer but not ideal. It will be left to a future patch to arrange the two different styles of recovery. Reported-and-tested-by: Nate Dailey Signed-off-by: NeilBrown Fixes: 7eb418851f32 ("md: allow a partially recovered device to be hot-added to an array.") Signed-off-by: Greg Kroah-Hartman commit 50128d1e5788213986e3ac34d58f0b0de06450d5 Author: Roman Gushchin Date: Sat Oct 31 10:53:50 2015 +1100 md/raid5: fix locking in handle_stripe_clean_event() commit b8a9d66d043ffac116100775a469f05f5158c16f upstream. After commit 566c09c53455 ("raid5: relieve lock contention in get_active_stripe()") __find_stripe() is called under conf->hash_locks + hash. But handle_stripe_clean_event() calls remove_hash() under conf->device_lock. Under some cirscumstances the hash chain can be circuited, and we get an infinite loop with disabled interrupts and locked hash lock in __find_stripe(). This leads to hard lockup on multiple CPUs and following system crash. I was able to reproduce this behavior on raid6 over 6 ssd disks. The devices_handle_discard_safely option should be set to enable trim support. The following script was used: for i in `seq 1 32`; do dd if=/dev/zero of=large$i bs=10M count=100 & done neilb: original was against a 3.x kernel. I forward-ported to 4.3-rc. This verison is suitable for any kernel since Commit: 59fc630b8b5f ("RAID5: batch adjacent full stripe write") (v4.1+). I'll post a version for earlier kernels to stable. Signed-off-by: Roman Gushchin Fixes: 566c09c53455 ("raid5: relieve lock contention in get_active_stripe()") Signed-off-by: NeilBrown Cc: Shaohua Li Signed-off-by: Greg Kroah-Hartman commit a82acc61f99e6f24444e2a4b5ed12928bf68a50e Author: Jes Sorensen Date: Tue Oct 20 12:09:13 2015 -0400 md/raid10: submit_bio_wait() returns 0 on success commit 681ab4696062f5aa939c9e04d058732306a97176 upstream. This was introduced with 9e882242c6193ae6f416f2d8d8db0d9126bd996b which changed the return value of submit_bio_wait() to return != 0 on error, but didn't update the caller accordingly. Fixes: 9e882242c6 ("block: Add submit_bio_wait(), remove from md") Reported-by: Bill Kuzeja Signed-off-by: Jes Sorensen Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 9b7c37247abf6f7f99bb9c6e4590d7f201a91cd4 Author: Jes Sorensen Date: Tue Oct 20 12:09:12 2015 -0400 md/raid1: submit_bio_wait() returns 0 on success commit 203d27b0226a05202438ddb39ef0ef1acb14a759 upstream. This was introduced with 9e882242c6193ae6f416f2d8d8db0d9126bd996b which changed the return value of submit_bio_wait() to return != 0 on error, but didn't update the caller accordingly. Fixes: 9e882242c6 ("block: Add submit_bio_wait(), remove from md") Reported-by: Bill Kuzeja Signed-off-by: Jes Sorensen Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 4dc153b8f0b5bda19f930ef84bb8d4be5fff605a Author: Herbert Xu Date: Mon Oct 19 18:23:57 2015 +0800 crypto: api - Only abort operations on fatal signal commit 3fc89adb9fa4beff31374a4bf50b3d099d88ae83 upstream. Currently a number of Crypto API operations may fail when a signal occurs. This causes nasty problems as the caller of those operations are often not in a good position to restart the operation. In fact there is currently no need for those operations to be interrupted by user signals at all. All we need is for them to be killable. This patch replaces the relevant calls of signal_pending with fatal_signal_pending, and wait_for_completion_interruptible with wait_for_completion_killable, respectively. Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit a8c51f9b2df0d98f2532148ebd620f27ad61d531 Author: Hans de Goede Date: Mon Oct 26 01:50:28 2015 -0700 Input: alps - only the Dell Latitude D420/430/620/630 have separate stick button bits commit 195562194aad3a0a3915941077f283bcc6347b9b upstream. commit 92bac83dd79e ("Input: alps - non interleaved V2 dualpoint has separate stick button bits") assumes that all alps v2 non-interleaved dual point setups have the separate stick button bits. Later we limited this to Dell laptops only because of reports that this broke things on non Dell laptops. Now it turns out that this breaks things on the Dell Latitude D600 too. So it seems that only the Dell Latitude D420/430/620/630, which all share the same touchpad / stick combo, have these separate bits. This patch limits the checking of the separate bits to only these models fixing regressions with other models. Reported-and-tested-by: Larry Finger Tested-by: Hans de Goede Signed-off-by: Hans de Goede Acked-By: Pali Rohár Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 3f9789e4d67c1f5035f7b642288c32025f4e06ed Author: Miklos Szeredi Date: Mon Oct 12 15:56:20 2015 +0200 ovl: fix open in stacked overlay commit 1c8a47df36d72ace8cf78eb6c228aa0f8027d3c2 upstream. If two overlayfs filesystems are stacked on top of each other, then we need recursion in ovl_d_select_inode(). I guess d_backing_inode() is supposed to do that. But currently it doesn't and that functionality is open coded in vfs_open(). This is now copied into ovl_d_select_inode() to fix this regression. Reported-by: Alban Crequy Signed-off-by: Miklos Szeredi Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay...") Cc: David Howells Signed-off-by: Greg Kroah-Hartman commit 64aceaeb1c141c8a03f9945614686f6491d328aa Author: David Howells Date: Fri Sep 18 11:45:22 2015 +0100 ovl: fix dentry reference leak commit ab79efab0a0ba01a74df782eb7fa44b044dae8b5 upstream. In ovl_copy_up_locked(), newdentry is leaked if the function exits through out_cleanup as this just to out after calling ovl_cleanup() - which doesn't actually release the ref on newdentry. The out_cleanup segment should instead exit through out2 as certainly newdentry leaks - and possibly upper does also, though this isn't caught given the catch of newdentry. Without this fix, something like the following is seen: BUG: Dentry ffff880023e9eb20{i=f861,n=#ffff880023e82d90} still in use (1) [unmount of tmpfs tmpfs] BUG: Dentry ffff880023ece640{i=0,n=bigfile} still in use (1) [unmount of tmpfs tmpfs] when unmounting the upper layer after an error occurred in copyup. An error can be induced by creating a big file in a lower layer with something like: dd if=/dev/zero of=/lower/a/bigfile bs=65536 count=1 seek=$((0xf000)) to create a large file (4.1G). Overlay an upper layer that is too small (on tmpfs might do) and then induce a copy up by opening it writably. Reported-by: Ulrich Obergfell Signed-off-by: David Howells Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit c631a0bb36d912fe4d649ce9e47670d0319a49ee Author: David Howells Date: Fri Sep 18 11:45:12 2015 +0100 ovl: use O_LARGEFILE in ovl_copy_up() commit 0480334fa60488d12ae101a02d7d9e1a3d03d7dd upstream. Open the lower file with O_LARGEFILE in ovl_copy_up(). Pass O_LARGEFILE unconditionally in ovl_copy_up_data() as it's purely for catching 32-bit userspace dealing with a file large enough that it'll be mishandled if the application isn't aware that there might be an integer overflow. Inside the kernel, there shouldn't be any problems. Reported-by: Ulrich Obergfell Signed-off-by: David Howells Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 5e3e1d57d06c1fe68516fd05874fa310c3f19a2c Author: Konstantin Khlebnikov Date: Mon Aug 24 15:57:19 2015 +0300 ovl: free lower_mnt array in ovl_put_super commit 5ffdbe8bf1e485026e1c7e4714d2841553cf0b40 upstream. This fixes memory leak after umount. Kmemleak report: unreferenced object 0xffff8800ba791010 (size 8): comm "mount", pid 2394, jiffies 4294996294 (age 53.920s) hex dump (first 8 bytes): 20 1c 13 02 00 88 ff ff ....... backtrace: [] create_object+0x124/0x2c0 [] kmemleak_alloc+0x7b/0xc0 [] __kmalloc+0x106/0x340 [] ovl_fill_super+0x55c/0x9b0 [overlay] [] mount_nodev+0x54/0xa0 [] ovl_mount+0x18/0x20 [overlay] [] mount_fs+0x43/0x170 [] vfs_kern_mount+0x74/0x170 [] do_mount+0x22d/0xdf0 [] SyS_mount+0x7b/0xc0 [] entry_SYSCALL_64_fastpath+0x12/0x76 [] 0xffffffffffffffff Signed-off-by: Konstantin Khlebnikov Signed-off-by: Miklos Szeredi Fixes: dd662667e6d3 ("ovl: add mutli-layer infrastructure") Signed-off-by: Greg Kroah-Hartman commit 7f650510ccebd647c99da484d473199b16d58f7a Author: Konstantin Khlebnikov Date: Mon Aug 24 15:57:18 2015 +0300 ovl: free stack of paths in ovl_fill_super commit 0f95502ad84874b3c05fc7cdd9d4d9d5cddf7859 upstream. This fixes small memory leak after mount. Kmemleak report: unreferenced object 0xffff88003683fe00 (size 16): comm "mount", pid 2029, jiffies 4294909563 (age 33.380s) hex dump (first 16 bytes): 20 27 1f bb 00 88 ff ff 40 4b 0f 36 02 88 ff ff '......@K.6.... backtrace: [] create_object+0x124/0x2c0 [] kmemleak_alloc+0x7b/0xc0 [] __kmalloc+0x106/0x340 [] ovl_fill_super+0x389/0x9a0 [overlay] [] mount_nodev+0x54/0xa0 [] ovl_mount+0x18/0x20 [overlay] [] mount_fs+0x43/0x170 [] vfs_kern_mount+0x74/0x170 [] do_mount+0x22d/0xdf0 [] SyS_mount+0x7b/0xc0 [] entry_SYSCALL_64_fastpath+0x12/0x76 [] 0xffffffffffffffff Signed-off-by: Konstantin Khlebnikov Signed-off-by: Miklos Szeredi Fixes: a78d9f0d5d5c ("ovl: support multiple lower layers") Signed-off-by: Greg Kroah-Hartman commit 3c41d05f5160b2faf4b1d7956b6a015dcfd349c3 Author: Sasha Levin Date: Wed Oct 7 11:03:28 2015 -0500 PCI: Prevent out of bounds access in numa_node override commit 1266963170f576d4d08e6310b6963e26d3ff9d1e upstream. 63692df103e9 ("PCI: Allow numa_node override via sysfs") didn't check that the numa node provided by userspace is valid. Passing a node number too high would attempt to access invalid memory and trigger a kernel panic. Fixes: 63692df103e9 ("PCI: Allow numa_node override via sysfs") Signed-off-by: Sasha Levin Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit a5da2bfc2a0163c7e3a856a2f5dc56a284558e72 Author: Peter Zijlstra Date: Thu Aug 20 10:34:59 2015 +0930 module: Fix locking in symbol_put_addr() commit 275d7d44d802ef271a42dc87ac091a495ba72fc5 upstream. Poma (on the way to another bug) reported an assertion triggering: [] module_assert_mutex_or_preempt+0x49/0x90 [] __module_address+0x32/0x150 [] __module_text_address+0x16/0x70 [] symbol_put_addr+0x29/0x40 [] dvb_frontend_detach+0x7d/0x90 [dvb_core] Laura Abbott produced a patch which lead us to inspect symbol_put_addr(). This function has a comment claiming it doesn't need to disable preemption around the module lookup because it holds a reference to the module it wants to find, which therefore cannot go away. This is wrong (and a false optimization too, preempt_disable() is really rather cheap, and I doubt any of this is on uber critical paths, otherwise it would've retained a pointer to the actual module anyway and avoided the second lookup). While its true that the module cannot go away while we hold a reference on it, the data structure we do the lookup in very much _CAN_ change while we do the lookup. Therefore fix the comment and add the required preempt_disable(). Reported-by: poma Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Rusty Russell Fixes: a6e6abd575fc ("module: remove module_text_address()") Signed-off-by: Greg Kroah-Hartman commit 55b31efcf3beca658566d35365329d3cbb44044f Author: Cathy Avery Date: Fri Oct 2 09:35:01 2015 -0400 xen-blkfront: check for null drvdata in blkback_changed (XenbusStateClosing) commit a54c8f0f2d7df525ff997e2afe71866a1a013064 upstream. xen-blkfront will crash if the check to talk_to_blkback() in blkback_changed()(XenbusStateInitWait) returns an error. The driver data is freed and info is set to NULL. Later during the close process via talk_to_blkback's call to xenbus_dev_fatal() the null pointer is passed to and dereference in blkfront_closing. Signed-off-by: Cathy Avery Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 9addc07f2c7a7e0ccb9f25d4aae36497c35c1068 Author: Laura Abbott Date: Mon Oct 12 11:30:13 2015 +0300 xhci: Add spurious wakeup quirk for LynxPoint-LP controllers commit fd7cd061adcf5f7503515ba52b6a724642a839c8 upstream. We received several reports of systems rebooting and powering on after an attempted shutdown. Testing showed that setting XHCI_SPURIOUS_WAKEUP quirk in addition to the XHCI_SPURIOUS_REBOOT quirk allowed the system to shutdown as expected for LynxPoint-LP xHCI controllers. Set the quirk back. Note that the quirk was originally introduced for LynxPoint and LynxPoint-LP just for this same reason. See: commit 638298dc66ea ("xhci: Fix spurious wakeups after S5 on Haswell") It was later limited to only concern HP machines as it caused regression on some machines, see both bug and commit: Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171 commit 6962d914f317 ("xhci: Limit the spurious wakeup fix only to HP machines") Later it was discovered that the powering on after shutdown was limited to LynxPoint-LP (Haswell-ULT) and that some non-LP HP machine suffered from spontaneous resume from S3 (which should not be related to the SPURIOUS_WAKEUP quirk at all). An attempt to fix this then removed the SPURIOUS_WAKEUP flag usage completely. commit b45abacde3d5 ("xhci: no switching back on non-ULT Haswell") Current understanding is that LynxPoint-LP (Haswell ULT) machines need the SPURIOUS_WAKEUP quirk, otherwise they will restart, and plain Lynxpoint (Haswell) machines may _not_ have the quirk set otherwise they again will restart. Signed-off-by: Laura Abbott Cc: Takashi Iwai Cc: Oliver Neukum [Added more history to commit message -Mathias] Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit f4822076dda460b2636b327222c0ab29b1d0451b Author: Mathias Nyman Date: Mon Oct 12 11:30:12 2015 +0300 xhci: handle no ping response error properly commit 3b4739b8951d650becbcd855d7d6f18ac98a9a85 upstream. If a host fails to wake up a isochronous SuperSpeed device from U1/U2 in time for a isoch transfer it will generate a "No ping response error" Host will then move to the next transfer descriptor. Handle this case in the same way as missed service errors, tag the current TD as skipped and handle it on the next transfer event. Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 9dd5c1324e679ca886861aad80f079a540841212 Author: Scot Doyle Date: Fri Oct 9 15:08:10 2015 +0000 fbcon: initialize blink interval before calling fb_set_par commit f235f664a8afabccf863a5dee4777d2d7b676fda upstream. Since commit 27a4c827c34ac4256a190cc9d24607f953c1c459 fbcon: use the cursor blink interval provided by vt a PPC64LE kernel fails to boot when fbcon_add_cursor_timer uses an uninitialized ops->cur_blink_jiffies. Prevent by initializing in fbcon_init before the call to info->fbops->fb_set_par. Reported-and-tested-by: Alistair Popple Signed-off-by: Scot Doyle Signed-off-by: Greg Kroah-Hartman commit cf411ffe50103f1b680abaf2ab3339618ec86d56 Author: Russell King Date: Tue Oct 20 11:49:44 2015 +0100 clkdev: fix clk_add_alias() with a NULL alias device name commit 625faa6a720d26fc0db9e20b48dc0dfe4c8d8ddf upstream. clk_add_alias() was not correctly handling the case where alias_dev_name was NULL: rather than producing an entry with a NULL dev_id pointer, it would produce a device name of (null). Fix this. Fixes: 2568999835d7 ("clkdev: add clkdev_create() helper") Reported-by: Aaro Koskinen Tested-by: Aaro Koskinen Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 9db937b36ee1d068ba27b37e5ff11c7c825eed97 Author: Hezi Shahmoon Date: Tue Oct 20 16:32:24 2015 +0200 i2c: mv64xxx: really allow I2C offloading commit 0729a04977d497cf66234fd7f900ddcec3ef1c52 upstream. Commit 00d8689b85a7 ("i2c: mv64xxx: rework offload support to fix several problems") completely reworked the offload support, but left a debugging-related "return false" at the beginning of the mv64xxx_i2c_can_offload() function. This has the unfortunate consequence that offloading is in fact never used, which wasn't really the intention. This commit fixes that problem by removing the bogus "return false". Fixes: 00d8689b85a7 ("i2c: mv64xxx: rework offload support to fix several problems") Signed-off-by: Hezi Shahmoon [Thomas: reworked commit log and title.] Signed-off-by: Thomas Petazzoni Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 6935d590e9d772da50d61b2c25ec2e8e807b02e4 Author: Bjørn Mork Date: Thu Oct 22 14:24:24 2015 +0200 USB: qcserial: add Sierra Wireless MC74xx/EM74xx commit f504ab1888026d15b5be8f9c262bf4ae9cacd177 upstream. New device IDs shamelessly lifted from the vendor driver. Signed-off-by: Bjørn Mork Acked-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 60288b005cd8eedc24e736db5068eb24c7422a7f Author: Frederic Danis Date: Fri Oct 9 17:14:56 2015 +0200 Revert "serial: 8250_dma: don't bother DMA with small transfers" commit f967fc8f165fadb72166f2bd4785094b3ca21307 upstream. This reverts commit 9119fba0cfeda6d415c9f068df66838a104b87cb. This commit prevents from sending "big" file using Bluetooth. When sending a lot of data quickly through the Bluetooth interface, and after a variable amount of data sent, transfer fails with error: kernel: [ 415.247453] Bluetooth: hci0 hardware error 0x00 Found on T100TA. After reverting this commit, send works fine for any file size. Signed-off-by: Frederic Danis Fixes: 9119fba0cfed (serial: 8250_dma: don't bother DMA with small transfers) Reviewed-by: Heikki Krogerus Acked-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit f2a990e96966e1be8233fe1e285d00882a6708bc Author: Arnd Bergmann Date: Tue Oct 6 22:29:48 2015 +0200 nvme: fix 32-bit build warning commit 835da3f99d329b1160a1f7fc82c7ac81163d63d0 upstream. Compiling the nvme driver on 32-bit warns about a cast from a __u64 variable to a pointer: drivers/block/nvme-core.c: In function 'nvme_submit_io': drivers/block/nvme-core.c:1847:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] (void __user *)io.addr, length, NULL, 0); The cast here is intentional and safe, so we can shut up the gcc warning by adding an intermediate cast to 'uintptr_t'. I had previously submitted a patch to fix this problem in the nvme driver, but it was accepted on the same day that two new warnings got added. For clarification, I also change the third instance of this cast to use uintptr_t instead of unsigned long now. Signed-off-by: Arnd Bergmann Fixes: d29ec8241c10e ("nvme: submit internal commands through the block layer") Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 2b1033516c578caaf96354d338ea7e6ce3143afd Author: Mike Snitzer Date: Thu Oct 22 10:56:40 2015 -0400 dm btree: fix leak of bufio-backed block in btree_split_beneath error path commit 4dcb8b57df3593dcb20481d9d6cf79d1dc1534be upstream. btree_split_beneath()'s error path had an outstanding FIXME that speaks directly to the potential for _not_ cleaning up a previously allocated bufio-backed block. Fix this by releasing the previously allocated bufio block using unlock_block(). Reported-by: Mikulas Patocka Signed-off-by: Mike Snitzer Acked-by: Joe Thornber Signed-off-by: Greg Kroah-Hartman commit 4ef0750436f944f4c34a3ef513853ad3e6664e8f Author: Joe Thornber Date: Thu Oct 22 18:10:55 2015 +0100 dm cache: the CLEAN_SHUTDOWN flag was not being set commit 3201ac452e84a8a368197d648c9b7011e061804a upstream. If the CLEAN_SHUTDOWN flag is not set when a cache is loaded then all cache blocks are marked as dirty and a full writeback occurs. __commit_transaction() is responsible for setting/clearing CLEAN_SHUTDOWN (based the flags_mutator that is passed in). Fix this issue, of the cache's on-disk flags being wrong, by making sure __commit_transaction() does not reset the flags after the mutator has altered the flags in preparation for them being serialized to disk. before: sb_flags = mutator(le32_to_cpu(disk_super->flags)); disk_super->flags = cpu_to_le32(sb_flags); disk_super->flags = cpu_to_le32(cmd->flags); after: disk_super->flags = cpu_to_le32(cmd->flags); sb_flags = mutator(le32_to_cpu(disk_super->flags)); disk_super->flags = cpu_to_le32(sb_flags); Reported-by: Bogdan Vasiliev Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 88f4adbc2bc1f2f64a7acc1311f3e2be72650e4b Author: Joe Thornber Date: Wed Oct 21 18:36:49 2015 +0100 dm btree remove: fix a bug when rebalancing nodes after removal commit 2871c69e025e8bc507651d5a9cf81a8a7da9d24b upstream. Commit 4c7e309340ff ("dm btree remove: fix bug in redistribute3") wasn't a complete fix for redistribute3(). The redistribute3 function takes 3 btree nodes and shares out the entries evenly between them. If the three nodes in total contained (MAX_ENTRIES * 3) - 1 entries between them then this was erroneously getting rebalanced as (MAX_ENTRIES - 1) on the left and right, and (MAX_ENTRIES + 1) in the center. Fix this issue by being more careful about calculating the target number of entries for the left and right nodes. Unit tested in userspace using this program: https://github.com/jthornber/redistribute3-test/blob/master/redistribute3_t.c Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 79ad2fa812eb2bed378925b35a162cacdc45cc02 Author: Tejun Heo Date: Tue Sep 8 12:20:22 2015 -0400 block: don't release bdi while request_queue has live references commit b02176f30cd30acccd3b633ab7d9aed8b5da52ff upstream. bdi's are initialized in two steps, bdi_init() and bdi_register(), but destroyed in a single step by bdi_destroy() which, for a bdi embedded in a request_queue, is called during blk_cleanup_queue() which makes the queue invisible and starts the draining of remaining usages. A request_queue's user can access the congestion state of the embedded bdi as long as it holds a reference to the queue. As such, it may access the congested state of a queue which finished blk_cleanup_queue() but hasn't reached blk_release_queue() yet. Because the congested state was embedded in backing_dev_info which in turn is embedded in request_queue, accessing the congested state after bdi_destroy() was called was fine. The bdi was destroyed but the memory region for the congested state remained accessible till the queue got released. a13f35e87140 ("writeback: don't embed root bdi_writeback_congested in bdi_writeback") changed the situation. Now, the root congested state which is expected to be pinned while request_queue remains accessible is separately reference counted and the base ref is put during bdi_destroy(). This means that the root congested state may go away prematurely while the queue is between bdi_dstroy() and blk_cleanup_queue(), which was detected by Andrey's KASAN tests. The root cause of this problem is that bdi doesn't distinguish the two steps of destruction, unregistration and release, and now the root congested state actually requires a separate release step. To fix the issue, this patch separates out bdi_unregister() and bdi_exit() from bdi_destroy(). bdi_unregister() is called from blk_cleanup_queue() and bdi_exit() from blk_release_queue(). bdi_destroy() is now just a simple wrapper calling the two steps back-to-back. While at it, the prototype of bdi_destroy() is moved right below bdi_setup_and_register() so that the counterpart operations are located together. Signed-off-by: Tejun Heo Fixes: a13f35e87140 ("writeback: don't embed root bdi_writeback_congested in bdi_writeback") Reported-and-tested-by: Andrey Konovalov Link: http://lkml.kernel.org/g/CAAeHK+zUJ74Zn17=rOyxacHU18SgCfC6bsYW=6kCY5GXJBwGfQ@mail.gmail.com Reviewed-by: Jan Kara Reviewed-by: Jeff Moyer Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 8005fd9888c0629857a8a5f5843ceaaf38161de9 Author: Lorenzo Pieralisi Date: Tue Oct 27 17:29:10 2015 +0000 arm64: kernel: fix tcr_el1.t0sz restore on systems with extended idmap commit e13d918a19a7b6cba62b32884f5e336e764c2cc6 upstream. Commit dd006da21646 ("arm64: mm: increase VA range of identity map") introduced a mechanism to extend the virtual memory map range to support arm64 systems with system RAM located at very high offset, where the identity mapping used to enable/disable the MMU requires additional translation levels to map the physical memory at an equal virtual offset. The kernel detects at boot time the tcr_el1.t0sz value required by the identity mapping and sets-up the tcr_el1.t0sz register field accordingly, any time the identity map is required in the kernel (ie when enabling the MMU). After enabling the MMU, in the cold boot path the kernel resets the tcr_el1.t0sz to its default value (ie the actual configuration value for the system virtual address space) so that after enabling the MMU the memory space translated by ttbr0_el1 is restored as expected. Commit dd006da21646 ("arm64: mm: increase VA range of identity map") also added code to set-up the tcr_el1.t0sz value when the kernel resumes from low-power states with the MMU off through cpu_resume() in order to effectively use the identity mapping to enable the MMU but failed to add the code required to restore the tcr_el1.t0sz to its default value, when the core returns to the kernel with the MMU enabled, so that the kernel might end up running with tcr_el1.t0sz value set-up for the identity mapping which can be lower than the value required by the actual virtual address space, resulting in an erroneous set-up. This patchs adds code in the resume path that restores the tcr_el1.t0sz default value upon core resume, mirroring this way the cold boot path behaviour therefore fixing the issue. Cc: Catalin Marinas Fixes: dd006da21646 ("arm64: mm: increase VA range of identity map") Acked-by: Ard Biesheuvel Signed-off-by: Lorenzo Pieralisi Signed-off-by: James Morse Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 4e89852b460e6fad80c032f30498f056e58b1f68 Author: Will Deacon Date: Wed Oct 28 16:56:13 2015 +0000 Revert "ARM64: unwind: Fix PC calculation" commit 9702970c7bd3e2d6fecb642a190269131d4ac16c upstream. This reverts commit e306dfd06fcb44d21c80acb8e5a88d55f3d1cf63. With this patch applied, we were the only architecture making this sort of adjustment to the PC calculation in the unwinder. This causes problems for ftrace, where the PC values are matched against the contents of the stack frames in the callchain and fail to match any records after the address adjustment. Whilst there has been some effort to change ftrace to workaround this, those patches are not yet ready for mainline and, since we're the odd architecture in this regard, let's just step in line with other architectures (like arch/arm/) for now. Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 31fb4a778f3f527b300bc7ce8ed7cde22e5eb501 Author: H. Nikolaus Schaller Date: Wed Oct 28 19:00:26 2015 +0100 ARM: 8449/1: fix bug in vdsomunge swab32 macro commit 38850d786a799c3ff2de0dc1980902c3263698dc upstream. Commit 8a603f91cc48 ("ARM: 8445/1: fix vdsomunge not to depend on glibc specific byteswap.h") unfortunately introduced a bug created but not found during discussion and patch simplification. Reported-by: Efraim Yawitz Signed-off-by: H. Nikolaus Schaller Fixes: 8a603f91cc48 ("ARM: 8445/1: fix vdsomunge not to depend on glibc specific byteswap.h") Signed-off-by: Nathan Lynch Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 1f3b5582890619c31c52965b8dab234e60fdbe8e Author: H. Nikolaus Schaller Date: Fri Oct 16 22:19:06 2015 +0100 ARM: 8445/1: fix vdsomunge not to depend on glibc specific byteswap.h commit 8a603f91cc4848ab1a0458bc065aa9f64322e123 upstream. If the host toolchain is not glibc based then the arm kernel build fails with HOSTCC arch/arm/vdso/vdsomunge arch/arm/vdso/vdsomunge.c:48:22: fatal error: byteswap.h: No such file or directory Observed: with omap2plus_defconfig and compile on Mac OS X with arm ELF cross-compiler. Reason: byteswap.h is a glibc only header. Solution: replace by private byte-swapping macros (taken from arch/mips/boot/elf2ecoff.c and kindly improved by Russell King) Tested to compile on Mac OS X 10.9.5 host. Signed-off-by: H. Nikolaus Schaller Signed-off-by: Nathan Lynch Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit b84e93d8386e55bcc29809ace4115811962253ab Author: Aaro Koskinen Date: Mon Oct 26 20:23:53 2015 +0200 ARM: OMAP1: fix incorrect INT_DMA_LCD commit 1bd5dfe41b994a6e793363894befef76626965a9 upstream. Commit 685e2d08c54b ("ARM: OMAP1: Change interrupt numbering for sparse IRQ") turned on SPARSE_IRQ on OMAP1, but forgot to change the number of INT_DMA_LCD. This broke the boot at least on Nokia 770, where the device hangs during framebuffer initialization. Fix by defining INT_DMA_LCD like the other interrupts. Fixes: 685e2d08c54b ("ARM: OMAP1: Change interrupt numbering for sparse IRQ") Signed-off-by: Aaro Koskinen Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 91295d8f1bd685a07d02d28f9c68944563798c3e Author: Linus Walleij Date: Tue Oct 13 19:46:54 2015 +0200 ARM: ux500: modify initial levelshifter status commit 83bf6b13834d9c926905e45cdfda23fe218fc598 upstream. commit 1d8aca9df612f5751892fb2642d72536f2f48fd0 "ARM: ux500: fix MMC/SD card regression" fixed broken the level shifter: it should be default ON but became default OFF. Fixes: 1d8aca9df612 "ARM: ux500: fix MMC/SD card regression" Reported-and-tested-by: Ulf Hansson Signed-off-by: Linus Walleij Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit c729a88ec197a135d1d5d9632d790f9a8672caaa Author: Tomi Valkeinen Date: Fri Sep 25 16:02:03 2015 +0300 ARM: dts: am57xx-beagle-x15: set VDD_SD to always-on commit 7e381ec6a36aa44f15fc1a76e6efb9e2cd942e61 upstream. LDO1 regulator (VDD_SD) is connected to SoC's vddshv8. vddshv8 needs to be kept always powered (see commit 5a0f93c6576a ("ARM: dts: Add am57xx-beagle-x15"), but at the moment VDD_SD is enabled/disabled depending on whether an SD card is inserted or not. This patch sets LDO1 regulator to always-on. This patch has a side effect of fixing another issue, HDMI DDC not working when SD card is not inserted: Why this happens is that the tpd12s015 (HDMI level shifter/ESD protection chip) has LS_OE GPIO input, which needs to be enabled for the HDMI DDC to work. LS_OE comes from gpio6_28. The pin that provides gpio6_28 is powered by vddshv8, and vddshv8 comes from VDD_SD. So when SD card is not inserted, VDD_SD is disabled, and LS_OE stays off. The proper fix for the HDMI DDC issue would be to maybe have the pinctrl framework manage the pin specific power. Apparently this fixes also a third issue (copy paste from Kishon's patch): ldo1_reg in addition to being connected to the io lines is also connected to the card detect line. On card removal, omap_hsmmc driver does a regulator_disable causing card detect line to be pulled down. This raises a card insertion interrupt and once the MMC core detects there is no card inserted, it does a regulator disable which again raises a card insertion interrupt. This happens in a loop causing infinite MMC interrupts. Fixes: 5a0f93c6576a ("ARM: dts: Add am57xx-beagle-x15") Cc: Kishon Vijay Abraham I Signed-off-by: Tomi Valkeinen Reported-by: Louis McCarthy Acked-by: Nishanth Menon Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit ec5eb41be2f1183357ef23fbf268b7b203da02b8 Author: Fabio Estevam Date: Thu Sep 24 16:18:12 2015 -0300 ARM: dts: imx7d: Fix UART2 base address commit 178b2d09afc05a46f68b190c6594f3a429bc2385 upstream. The UART2 memory space starts at address 0x30890000 (UART2_URXD). Fix it so that UART2 can be used. Signed-off-by: Fabio Estevam Fixes: 949673450291 ("ARM: dts: add imx7d soc dtsi file") Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 64563f7547b4bb79153a3b43506d3351d9956f83 Author: Alim Akhtar Date: Tue Oct 13 04:32:53 2015 +0900 ARM: dts: Fix audio card detection on Peach boards commit b8bb9baad27e455c467e8fac47eebadbe765c18f upstream. Since commit 2fad972d45c4 ("ARM: dts: Add mclk entry for Peach boards"), sound card detection is broken on peach boards and gives below errors: [ 3.630457] max98090 7-0010: MAX98091 REVID=0x51 [ 3.634233] max98090 7-0010: use default 2.8v micbias [ 3.640985] snow-audio sound: HiFi <-> 3830000.i2s mapping ok [ 3.645307] max98090 7-0010: Invalid master clock frequency [ 3.650824] snow-audio sound: ASoC: Peach-Pi-I2S-MAX98091 late_probe() failed: -22 [ 3.658914] snow-audio sound: snd_soc_register_card failed (-22) [ 3.664366] snow-audio: probe of sound failed with error -22 This patch adds missing assigned-clocks and assigned-clock-parents for pmu_system_controller node which is used as "mclk" for audio codec. Fixes: 2fad972d45c4 ("ARM: dts: Add mclk entry for Peach boards") Signed-off-by: Alim Akhtar Reviewed-by: Krzysztof Kozlowski Signed-off-by: Kukjin Kim Signed-off-by: Greg Kroah-Hartman commit c5e282280f0cb12bdee0d0c78455a73c4e12995b Author: Thomas Hebb Date: Thu Oct 1 21:00:00 2015 +0200 ARM: dts: berlin: change BG2Q's USB PHY compatible commit 1f744fd317dc55cadd7132c57c499e3117aea01d upstream. Currently, BG2Q shares a compatible with BG2. This is incorrect, since BG2 and BG2Q use different USB PLL dividers. In reality, BG2Q shares a divider with BG2CD. Change BG2Q's USB PHY compatible string to reflect that. Signed-off-by: Thomas Hebb Signed-off-by: Sebastian Hesselbarth Signed-off-by: Greg Kroah-Hartman commit 589414cc5f2a62734217d1dd840cb1866e0dc8fc Author: Marcin Wojtas Date: Thu Oct 15 03:17:08 2015 +0200 ARM: mvebu: correct a385-db-ap compatible string commit db347f1a5304d68c68c52f19971924b1e5842f3c upstream. This commit enables standby support on Armada 385 DB-AP board, because the PM initalization routine requires "marvell,armada380" compatible string for all Armada 38x-based platforms. Beside the compatible "marvell,armada38x" was wrong and should be fixed in the stable kernels too. [gregory.clement@free-electrons.com: add information, about the fixes] Fixes: e5ee12817e9ea ("ARM: mvebu: Add Armada 385 Access Point Development Board support") Signed-off-by: Marcin Wojtas Signed-off-by: Gregory CLEMENT Signed-off-by: Greg Kroah-Hartman commit 9290130f4942f1a0c5a417807692b72949774354 Author: Florian Fainelli Date: Sat Oct 3 13:03:47 2015 -0700 ARM: orion: Fix DSA platform device after mvmdio conversion commit d836ace65ee98d7079bc3c5afdbcc0e27dca20a3 upstream. DSA expects the host_dev pointer to be the device structure associated with the MDIO bus controller driver. First commit breaking that was c3a07134e6aa ("mv643xx_eth: convert to use the Marvell Orion MDIO driver"), and then, it got completely under the radar for a while. Reported-by: Frans van de Wiel Fixes: c3a07134e6aa ("mv643xx_eth: convert to use the Marvell Orion MDIO driver") Signed-off-by: Florian Fainelli Signed-off-by: Gregory CLEMENT Signed-off-by: Greg Kroah-Hartman commit 81d84be24eb405e21fae883f5fbc390021e05bda Author: Krzysztof Kozlowski Date: Tue Oct 13 04:32:49 2015 +0900 ARM: EXYNOS: Fix double of_node_put() when parsing child power domains commit 51a6256b00008a3c520f6f31bcd62cd15cb05960 upstream. On each next iteration of for_each_compatible_node() the reference counter for current device node is already decreased by the loop iterator. The manual call to of_node_get() is required only on loop break which is not happening here. The double of_node_get() (with enabled CONFIG_OF_DYNAMIC) lead to decreasing the counter below expected, initial value. Fixes: fe4034a3fad7 ("ARM: EXYNOS: Add missing of_node_put() when parsing power domains") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Kukjin Kim Signed-off-by: Greg Kroah-Hartman commit 442cdeddf4052789537b75c7bfa2db3a6308c1e6 Author: Ilya Dryomov Date: Sun Oct 11 19:38:00 2015 +0200 rbd: prevent kernel stack blow up on rbd map commit 6d69bb536bac0d403d83db1ca841444981b280cd upstream. Mapping an image with a long parent chain (e.g. image foo, whose parent is bar, whose parent is baz, etc) currently leads to a kernel stack overflow, due to the following recursion in the reply path: rbd_osd_req_callback() rbd_obj_request_complete() rbd_img_obj_callback() rbd_img_parent_read_callback() rbd_obj_request_complete() ... Limit the parent chain to 16 images, which is ~5K worth of stack. When the above recursion is eliminated, this limit can be lifted. Fixes: http://tracker.ceph.com/issues/12538 Signed-off-by: Ilya Dryomov Reviewed-by: Josh Durgin Signed-off-by: Greg Kroah-Hartman commit afbd0c41b3594241d08c43b6cbf6db042f4f4b78 Author: Ilya Dryomov Date: Sun Oct 11 19:38:00 2015 +0200 rbd: don't leak parent_spec in rbd_dev_probe_parent() commit 1f2c6651f69c14d0d3a9cfbda44ea101b02160ba upstream. Currently we leak parent_spec and trigger a "parent reference underflow" warning if rbd_dev_create() in rbd_dev_probe_parent() fails. The problem is we take the !parent out_err branch and that only drops refcounts; parent_spec that would've been freed had we called rbd_dev_unparent() remains and triggers rbd_warn() in rbd_dev_parent_put() - at that point we have parent_spec != NULL and parent_ref == 0, so counter ends up being -1 after the decrement. Redo rbd_dev_probe_parent() to fix this. Signed-off-by: Ilya Dryomov Reviewed-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit 960811cc41e99b9ac2d87f18aef2c3c94ea793bd Author: Ronny Hegewald Date: Thu Oct 15 18:50:46 2015 +0000 rbd: require stable pages if message data CRCs are enabled commit bae818ee1577c27356093901a0ea48f672eda514 upstream. rbd requires stable pages, as it performs a crc of the page data before they are send to the OSDs. But since kernel 3.9 (patch 1d1d1a767206fbe5d4c69493b7e6d2a8d08cc0a0 "mm: only enforce stable page writes if the backing device requires it") it is not assumed anymore that block devices require stable pages. This patch sets the necessary flag to get stable pages back for rbd. In a ceph installation that provides multiple ext4 formatted rbd devices "bad crc" messages appeared regularly (ca 1 message every 1-2 minutes on every OSD that provided the data for the rbd) in the OSD-logs before this patch. After this patch this messages are pretty much gone (only ca 1-2 / month / OSD). Signed-off-by: Ronny Hegewald [idryomov@gmail.com: require stable pages only in crc case, changelog] [idryomov@gmail.com: backport to 3.18-4.2: context] Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 249b5a7a20b1738d6038bbb400cb9b118c263823 Author: Dan Carpenter Date: Sat Aug 8 22:16:42 2015 +0300 iio: accel: sca3000: memory corruption in sca3000_read_first_n_hw_rb() commit eda7d0f38aaf50dbb2a2de15e8db386c4f6f65fc upstream. "num_read" is in byte units but we are write u16s so we end up write twice as much as intended. Signed-off-by: Dan Carpenter Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit f1cf6a8e4c46bc3e3914445d50455ec12cfef787 Author: Linus Walleij Date: Wed Sep 2 21:02:58 2015 +0200 iio: st_accel: fix interrupt handling on LIS3LV02 commit 61fd56309165d4790f99462d893b099f0b07312a upstream. This accelerometer accidentally either emits a DRDY signal or an IRQ signal. Accidentally I activated the IRQ signal as I thought it was analogous to the interrupt generator on other ST accelerometers. This was wrong. After this patch generic_buffer gives a nice stream of accelerometer readings. Fixes: 3acddf74f807778f "iio: st-sensors: add support for lis3lv02d accelerometer" Cc: Denis CIOCCA Signed-off-by: Linus Walleij Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 92964bc7a78a416d52d908539fe3ab9cded8ad8e Author: Alexandre Belloni Date: Wed Oct 7 13:10:54 2015 +0200 iio: mxs-lradc: Fix temperature offset commit b94e22805a2224061bb263a82b72e09544a5fbb3 upstream. 0° Kelvin is actually −273.15°C, not -272.15°C. Fix the temperature offset. Also improve the comment explaining the calculation. Reported-by: Janusz Użycki Signed-off-by: Alexandre Belloni Acked-by: Stefan Wahren Acked-by: Marek Vasut Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit eb746d202143cbbcc98d88beda07572c0a3dff28 Author: Alex Deucher Date: Wed Oct 28 14:26:32 2015 -0400 drm/radeon: move bl encoder assignment into bl init commit 4cee6a9057d5e13911f0cb6e143d11dc1a3245dd upstream. So that the bl encoder will be null if the GPU does not control the backlight. Reviewed-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 06ab4bbd6348b755028c84972a80baacdbb3c889 Author: Alex Deucher Date: Tue Oct 27 10:56:44 2015 -0400 drm/radeon: fix dpms when driver backlight control is disabled commit ae93580ee59c02395c1711d3e6b90546b8137b86 upstream. If driver backlight control is disabled, either by driver parameter or default per-asic setting, revert to the old behavior. Fixes a regression in commit: 4281f46ef839050d2ef60348f661eb463c21cc2e Reviewed-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit e42f26b7fa7c34a3d049b13a784ace0ee868b465 Author: Alex Deucher Date: Fri Oct 23 10:45:14 2015 -0400 drm/amdgpu: don't try to recreate sysfs entries on resume commit c86f5ebfbd147d1a228ab89ee1658e18939bd7ad upstream. Fixes an error on resume caused by: fa022a9b65d2886486a022fd66b20c823cd76ad9 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit fcf381425153371b94507ee4a5d0284616ac955d Author: Alex Deucher Date: Fri Oct 23 10:38:52 2015 -0400 drm/radeon: don't try to recreate sysfs entries on resume commit 49abb26651167c892393cd9f2ad23df429645ed9 upstream. Fixes a harmless error message caused by: 51a4726b04e880fdd9b4e0e58b13f70b0a68a7f5 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit b9c4ee9f163cbcba598e84956075453f7fd298ac Author: Chris Wilson Date: Tue Oct 13 14:22:26 2015 +0100 drm/i915: Deny wrapping an userptr into a framebuffer commit cc917ab43541db3ff66d0136042686d40a1b4c9a upstream. Pinning a userptr onto the hardware raises interesting questions about the lifetime of such a surface as the framebuffer extends that life beyond the client's address space. That is the hardware will need to keep scanning out from the backing storage even after the client wants to remap its address space. As the hardware pins the backing storage, the userptr becomes invalid and this raises a WARN when the clients tries to unmap its address space. The situation can be even more complicated when the buffer is passed between processes, between a client and display server, where the lifetime and hardware access is even more confusing. Deny it. Signed-off-by: Chris Wilson Cc: Daniel Vetter Cc: Tvrtko Ursulin Cc: Michał Winiarski Reviewed-by: Tvrtko Ursulin Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 3b41bea2e6ee89b191e99fa7f9e8a576a93edd45 Author: Ville Syrjälä Date: Wed Oct 7 22:08:24 2015 +0300 drm/i915: Restore lost DPLL register write on gen2-4 commit 8e7a65aa70bcc1235a44e40ae0da5056525fe081 upstream. We accidentally lost the initial DPLL register write in 1c4e02746147 drm/i915: Fix DVO 2x clock enable on 830M The "three times for luck" hack probably saved us from a total disaster. But anyway, bring the initial write back so that the code actually makes some sense. Reported-and-tested-by: Nick Bowler References: http://mid.gmane.org/CAN_QmVyMaArxYgEcVVsGvsMo7-6ohZr8HmF5VhkkL4i9KOmrhw@mail.gmail.com Cc: Nick Bowler Signed-off-by: Ville Syrjälä Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit af5ae108419917ebaeab64e59e1ae5db319a87c5 Author: Chris Wilson Date: Fri Aug 21 16:08:41 2015 +0100 drm/i915: Flush pipecontrol post-sync writes commit 40a24488f5250d63341e74b9994159afc4589606 upstream. In order to flush the results from in-batch pipecontrol writes (used for example in glQuery) before declaring the batch complete (and so declaring the query results coherent), we need to set the FlushEnable bit in our flushing pipecontrol. The FlushEnable bit "waits until all previous writes of immediate data from post-sync circles are complete before executing the next command". I get GPU hangs on byt without flushing these writes (running ue4). piglit has examples where the flush is required for correct rendering. Signed-off-by: Chris Wilson Reviewed-by: Ville Syrjälä Acked-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit bae606df3068a63d785a05542622a43156bdec5d Author: Alex Deucher Date: Mon Oct 19 15:54:21 2015 -0400 drm/amdgpu: add missing dpm check for KV dpm late init commit 677c884ff6370add1360e2b9558285355ebe2b36 upstream. Skip dpm late init if dpm is disabled. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 9b8fb2c38b4232516ef8d27373c9a8ea334b0ad5 Author: Alex Deucher Date: Mon Oct 19 09:30:42 2015 -0400 drm/radeon/dpm: don't add pwm attributes if DPM is disabled commit 2a7d44f47f53fa1be677f44c73d78b1bcf9c05d9 upstream. PWM fan control is only available with DPM. If DPM disabled, don't expose the PWM fan controls to avoid a crash. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92524 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 03cf3c9337feb72ef10b85a2fdba27b358bffa5b Author: Ilia Mirkin Date: Tue Oct 20 01:15:39 2015 -0400 drm/nouveau/gem: return only valid domain when there's only one commit 2a6c521bb41ce862e43db46f52e7681d33e8d771 upstream. On nv50+, we restrict the valid domains to just the one where the buffer was originally created. However after the buffer is evicted to system memory, we might move it back to a different domain that was not originally valid. When sharing the buffer and retrieving its GEM_INFO data, we still want the domain that will be valid for this buffer in a pushbuf, not the one where it currently happens to be. This resolves fdo#92504 and several others. These are due to suspend evicting all buffers, making it more likely that they temporarily end up in the wrong place. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92504 Signed-off-by: Ilia Mirkin Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit c7ee1f4f161b844c7388528f38fb3d7eb96d078f Author: Pawel Moll Date: Thu Oct 15 14:32:46 2015 +0100 bus: arm-ccn: Fix irq affinity setting on CPU migration commit a0bcbe969f564d1ec08658170dda72a1b7e9053a upstream. When PMU context is migrating between CPUs, interrupt affinity is set as well. Only this should not happen when the CCN interrupt is not being used at all (the driver is using a hrtimer tick instead). Fixed now. Signed-off-by: Pawel Moll Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 5b31ed54b8515c608d6bddc5277f74fbf36aa0b0 Author: Steven Rostedt (Red Hat) Date: Tue Oct 20 11:38:08 2015 -0400 tracing: Have stack tracer force RCU to be watching commit a2d7629048322ae62bff57f34f5f995e25ed234c upstream. The stack tracer was triggering the WARN_ON() in module.c: static void module_assert_mutex_or_preempt(void) { #ifdef CONFIG_LOCKDEP if (unlikely(!debug_locks)) return; WARN_ON(!rcu_read_lock_sched_held() && !lockdep_is_held(&module_mutex)); #endif } The reason is that the stack tracer traces all function calls, and some of those calls happen while exiting or entering user space and idle. Some of these functions are called after RCU had already stopped watching, as RCU does not watch userspace or idle CPUs. If a max stack is hit, then the save_stack_trace() is called, which will check module addresses and call module_assert_mutex_or_preempt(), and then trigger the warning. Sad part is, the warning itself will also do a stack trace and tigger the same warning. That probably should be fixed. The warning was added by 0be964be0d45 "module: Sanitize RCU usage and locking" but this bug has probably been around longer. But it's unlikely to cause much harm, but the new warning causes the system to lock up. Cc: Peter Zijlstra Cc:"Paul E. McKenney" Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 07f89e225aa566483b73f2c32057d0cfa1df4654 Author: Florian Westphal Date: Thu Oct 22 13:32:27 2015 -0700 fault-inject: fix inverted interval/probability values in printk commit bb387002693ed28b2bb0408c5dec65521b71e5f1 upstream. interval displays the probability and vice versa. Fixes: 6adc4a22f20bb ("fault-inject: add ratelimit option") Acked-by: Akinobu Mita Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4b5f17c9ca7c29d6650eb335b94d44864dc6fd76 Author: Jan Kara Date: Thu Oct 22 13:32:21 2015 -0700 mm: make sendfile(2) killable commit 296291cdd1629c308114504b850dc343eabc2782 upstream. Currently a simple program below issues a sendfile(2) system call which takes about 62 days to complete in my test KVM instance. int fd; off_t off = 0; fd = open("file", O_RDWR | O_TRUNC | O_SYNC | O_CREAT, 0644); ftruncate(fd, 2); lseek(fd, 0, SEEK_END); sendfile(fd, fd, &off, 0xfffffff); Now you should not ask kernel to do a stupid stuff like copying 256MB in 2-byte chunks and call fsync(2) after each chunk but if you do, sysadmin should have a way to stop you. We actually do have a check for fatal_signal_pending() in generic_perform_write() which triggers in this path however because we always succeed in writing something before the check is done, we return value > 0 from generic_perform_write() and thus the information about signal gets lost. Fix the problem by doing the signal check before writing anything. That way generic_perform_write() returns -EINTR, the error gets propagated up and the sendfile loop terminates early. Signed-off-by: Jan Kara Reported-by: Dmitry Vyukov Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1e801f3a2dbf3bfd85155526bc0acbc55e309627 Author: Werner Pawlitschko Date: Tue Oct 27 09:08:04 2015 +0900 x86/ioapic: Prevent NULL pointer dereference in setup_ioapic_dest() commit ababae44108b0e94b58eef6cb5bd830bd040a47f upstream. Commit 4857c91f0d19 changed the way how irq affinity is setup in setup_ioapic_dest() from using the core helper function to unconditionally calling the irq_set_affinity() callback of the underlying irq chip. That results in a NULL pointer dereference for the rare case where the underlying irq chip is lapic_chip which has no irq_set_affinity() callback. lapic_chip is occasionally used for the timer interrupt (irq 0). The fix is simple: Check the availability of the callback instead of calling it unconditionally. Fixes: 4857c91f0d19 "x86/ioapic: Force affinity setting in setup_ioapic_dest()" Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit f07476108d20bc143192d579bf468d0560ed5571 Author: Kővágó, Zoltán Date: Mon Oct 12 15:13:56 2015 +0100 x86/efi: Fix multiple GOP device support commit 8a53554e12e98d1759205afd7b8e9e2ea0936f48 upstream. When multiple GOP devices exists, but none of them implements ConOut, the code should just choose the first GOP (according to the comments). But currently 'fb_base' will refer to the last GOP, while other parameters to the first GOP, which will likely result in a garbled display. I can reliably reproduce this bug using my ASRock Z87M Extreme4 motherboard with CSM and integrated GPU disabled, and two PCIe video cards (NVidia GT640 and GTX980), booting from efi-stub (booting from grub works fine). On the primary display the ASRock logo remains and on the secondary screen it is garbled up completely. Signed-off-by: Kővágó, Zoltán Signed-off-by: Matt Fleming Cc: Linus Torvalds Cc: Matthew Garrett Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1444659236-24837-2-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit e15e7543965b0fc8155605b5da11fd0492750670 Author: Charles Keepax Date: Tue Oct 20 10:25:58 2015 +0100 ASoC: wm8904: Correct number of EQ registers commit 97aff2c03a1e4d343266adadb52313613efb027f upstream. There are 24 EQ registers not 25, I suspect this bug came about because the registers start at EQ1 not zero. The bug is relatively harmless as the extra register written is an unused one. Signed-off-by: Charles Keepax Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit af029bcfee56f826f32286bf81884d4c23dda0c1 Author: Charles Keepax Date: Wed Oct 14 13:31:24 2015 +0100 ASoC: Add info callback for SX_TLV controls commit 34198710f55b5f359f43e67d9a08fe5aadfbca1b upstream. SX_TLV controls are intended for situations where the register behind the control has some non-zero value indicating the minimum gain and then gains increasing from there and eventually overflowing through zero. Currently every CODEC implementing these controls specifies the minimum as the non-zero value for the minimum and the maximum as the number of gain settings available. This means when the info callback subtracts the minimum value from the maximum value to calculate the number of gain levels available it is actually under reporting the available levels. This patch fixes this issue by adding a new snd_soc_info_volsw_sx callback that does not subtract the minimum value. Fixes: 1d99f2436d0d ("ASoC: core: Rework SOC_DOUBLE_R_SX_TLV add SOC_SINGLE_SX_TLV") Signed-off-by: Charles Keepax Acked-by: Brian Austin Tested-by: Brian Austin Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 05dcab858f235822aee6e1268904183de75b1a5a Author: Takashi Iwai Date: Tue Oct 20 16:23:55 2015 +0200 ALSA: hda - Fix deadlock at error in building PCM commit d289619a219dd01e255d7b5e30f9171b25efea48 upstream. The HDA codec driver issues snd_hda_codec_reset() at the error path of PCM build. This was needed in the earlier code base, but the recent rewrite to use the standard bus binding made this a deadlock: modprobe D 0000000000000005 0 720 716 0x00000080 Call Trace: [] schedule+0x3e/0x90 [] schedule_preempt_disabled+0x15/0x20 [] __mutex_lock_slowpath+0xb5/0x120 [] mutex_lock+0x1b/0x30 [] device_release_driver+0x1b/0x30 [] bus_remove_device+0x105/0x180 [] device_del+0x139/0x260 [] snd_hdac_device_unregister+0x25/0x30 [snd_hda_core] [] snd_hda_codec_reset+0x2a/0x70 [snd_hda_codec] [] snd_hda_codec_build_pcms+0x18b/0x1b0 [snd_hda_codec] [] hda_codec_driver_probe+0xbe/0x140 [snd_hda_codec] [] driver_probe_device+0x1f4/0x460 [] __driver_attach+0x90/0xa0 [] bus_for_each_dev+0x64/0xa0 [] driver_attach+0x1e/0x20 [] bus_add_driver+0x1eb/0x280 [] driver_register+0x60/0xe0 [] __hda_codec_driver_register+0x5a/0x60 [snd_hda_codec] [] realtek_driver_init+0x1e/0x1000 [snd_hda_codec_realtek] [] do_one_initcall+0xb3/0x200 [] do_init_module+0x60/0x1f8 [] load_module+0x1653/0x1bd0 [] SYSC_finit_module+0x98/0xc0 [] SyS_finit_module+0xe/0x10 [] entry_SYSCALL_64_fastpath+0x16/0x75 The simple fix is just to remove this call, since we don't need to think about unbinding at there any longer. Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=948758 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d3fc4e09a8275a493c09d8de10b05d09503bd450 Author: David Henningsson Date: Tue Oct 13 10:10:18 2015 +0200 ALSA: hda - Fix inverted internal mic on Lenovo G50-80 commit e8d65a8d985271a102f07c7456da5b86c19ffe16 upstream. Add the appropriate quirk to indicate the Lenovo G50-80 has a stereo mic input where one channel has reverse polarity. Alsa-info available at: https://launchpadlibrarian.net/220846272/AlsaInfo.txt BugLink: https://bugs.launchpad.net/bugs/1504778 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7ee6875b47aa211b97d6aa3089c46ac5e1fec2a0 Author: Vinod Koul Date: Tue Oct 13 14:57:49 2015 +0530 ALSA: hdac: Explicitly add io.h commit 42f2bb1c494543084b764e1ca253c73db910daf2 upstream. Compiling the hdac extended core on arm fails with below error: sound/hda/ext/hdac_ext_bus.c: In function 'hdac_ext_writel': >> sound/hda/ext/hdac_ext_bus.c:29:2: error: implicit declaration of >> function +'writel' [-Werror=implicit-function-declaration] writel(value, addr); ^ sound/hda/ext/hdac_ext_bus.c: In function 'hdac_ext_readl': >> sound/hda/ext/hdac_ext_bus.c:34:2: error: implicit declaration of >> function +'readl' [-Werror=implicit-function-declaration] return readl(addr); This is fixed by explicitly including io.h Fixes: 99463b3a3994 - ('ALSA: hda: provide default bus io ops extended hdac') Reported-by: kbuild test robot Suggested-by: Mark Brown Signed-off-by: Vinod Koul Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c33464a445537acfa82d63eb3d3e84766a0c5b5c Author: Arnd Bergmann Date: Mon Oct 12 15:22:31 2015 +0200 KVM: arm: use GIC support unconditionally commit 4a5d69b73948d0e03cd38d77dc11edb2e707165f upstream. The vgic code on ARM is built for all configurations that enable KVM, but the parent_data field that it references is only present when CONFIG_IRQ_DOMAIN_HIERARCHY is set: virt/kvm/arm/vgic.c: In function 'kvm_vgic_map_phys_irq': virt/kvm/arm/vgic.c:1781:13: error: 'struct irq_data' has no member named 'parent_data' This flag is implied by the GIC driver, and indeed the VGIC code only makes sense if a GIC is present. This changes the CONFIG_KVM symbol to always select GIC, which avoids the issue. Fixes: 662d9715840 ("arm/arm64: KVM: Kill CONFIG_KVM_ARM_{VGIC,TIMER}") Signed-off-by: Arnd Bergmann Acked-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Greg Kroah-Hartman commit 1b952c690cc1878768cd8ecd95f782644332e485 Author: Antti Palosaari Date: Tue Oct 6 00:22:23 2015 -0300 rtl28xxu: fix control message flaws commit d18ca5b7ceca0e9674cb4bb2ed476b0fcbb23ba2 upstream. Add lock to prevent concurrent access for control message as control message function uses shared buffer. Without the lock there may be remote control polling which messes the buffer causing IO errors. Increase buffer size and add check for maximum supported message length. Link: https://bugzilla.kernel.org/show_bug.cgi?id=103391 Fixes: c56222a6b25c ("[media] rtl28xxu: move usb buffers to state") Signed-off-by: Antti Palosaari Signed-off-by: Greg Kroah-Hartman commit e9cd49802d4456868d6abde8fd2784959d3954e7 Author: Laura Abbott Date: Tue Sep 29 21:10:09 2015 -0300 si2168: Bounds check firmware commit 47810b4341ac9d2f558894bc5995e6fa2a1298f9 upstream. When reading the firmware and sending commands, the length must be bounds checked to avoid overrunning the size of the command buffer and smashing the stack if the firmware is not in the expected format: si2168 11-0064: found a 'Silicon Labs Si2168-B40' si2168 11-0064: downloading firmware from file 'dvb-demod-si2168-b40-01.fw' si2168 11-0064: firmware download failed -95 Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffffa085708f Add the proper check. Reported-by: Stuart Auchterlonie Reviewed-by: Antti Palosaari Signed-off-by: Laura Abbott Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 29a3e36836ba839cd46c36a0b0931064f01fc6c7 Author: Laura Abbott Date: Tue Sep 29 21:10:10 2015 -0300 si2157: Bounds check firmware commit a828d72df216c36e9c40b6c24dc4b17b6f7b5a76 upstream. When reading the firmware and sending commands, the length must be bounds checked to avoid overrunning the size of the command buffer and smashing the stack if the firmware is not in the expected format. Add the proper check. Signed-off-by: Laura Abbott Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit c8b0abcf958e1cfeeb8f289e6755aafab74806c6 Author: Antti Palosaari Date: Sat Oct 3 18:35:14 2015 -0300 m88ds3103: use own reg update_bits() implementation commit 56ea37da3b93dfe46cb5c3ee0ee4cc44229ece47 upstream. Device stopped to tuning some channels after regmap conversion. Reason is that regmap_update_bits() works a bit differently for partially volatile registers than old homemade routine. Return back to old routine in order to fix issue. Fixes: 478932b16052f5ded74685d096ae920cd17d6424 Reported-by: Mark Clarkstone Tested-by: Mark Clarkstone Signed-off-by: Antti Palosaari Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 8d03fee4c8589d6c722afa22e6f261d6e699edf6 Author: Dan Carpenter Date: Thu Oct 29 16:37:54 2015 +0300 drm: crtc: integer overflow in drm_property_create_blob() commit 9ac0934bbe52290e4e4c2a58ec41cab9b6ca8c96 upstream. The size here comes from the user via the ioctl, it is a number between 1-u32max so the addition here could overflow on 32 bit systems. Fixes: f453ba046074 ('DRM: add mode setting support') Signed-off-by: Dan Carpenter Reviewed-by: Daniel Stone Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit bc95f69741323ad97fefbad8a2b3f42ff5c230de Author: Maneet Singh Date: Thu Oct 8 10:10:24 2015 -0400 drm: Correct arguments to list_tail_add in create blob ioctl commit 8731b269f01e16193390c7276e70530366b8d626 upstream. Arguments passed to list_add_tail were reversed resulting in deletion of old blob property everytime the new one is added. Fixes commit e2f5d2ea479b9b2619965d43db70939589afe43a Author: Daniel Stone Date: Fri May 22 13:34:51 2015 +0100 drm/mode: Add user blob-creation ioctl Signed-off-by: Maneet Singh [seanpaul tweaked commit subject a little] Signed-off-by: Sean Paul Reviewed-by: Daniel Stone Reviewed-by: Jani Nikula Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 6766f494c5df4e3e2662635babf97734ef180eb3 Author: Adam Richter Date: Fri Oct 16 03:33:02 2015 -0700 drm: fix mutex leak in drm_dp_get_mst_branch_device commit 30730c7f5943b3beace1e29f7f1476e05de3da14 upstream. In Linux 4.3-rc5, there is an error case in drm_dp_get_branch_device that returns without releasing mgr->lock, resulting a spew of kernel messages about a kernel work function possibly having leaked a mutex and presumably more serious adverse consequences later. This patch changes the error to "goto out" to unlock the mutex before returning. [airlied: grabbed from drm-next as it fixes something we've seen] Signed-off-by: Adam J. Richter Signed-off-by: Daniel Vetter Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit c9270c4850214bbd0798c171fafef7520cafdfd5 Author: Vasant Hegde Date: Fri Oct 16 15:53:29 2015 +0530 powerpc/rtas: Validate rtas.entry before calling enter_rtas() commit 8832317f662c06f5c06e638f57bfe89a71c9b266 upstream. Currently we do not validate rtas.entry before calling enter_rtas(). This leads to a kernel oops when user space calls rtas system call on a powernv platform (see below). This patch adds code to validate rtas.entry before making enter_rtas() call. Oops: Exception in kernel mode, sig: 4 [#1] SMP NR_CPUS=1024 NUMA PowerNV task: c000000004294b80 ti: c0000007e1a78000 task.ti: c0000007e1a78000 NIP: 0000000000000000 LR: 0000000000009c14 CTR: c000000000423140 REGS: c0000007e1a7b920 TRAP: 0e40 Not tainted (3.18.17-340.el7_1.pkvm3_1_0.2400.1.ppc64le) MSR: 1000000000081000 CR: 00000000 XER: 00000000 CFAR: c000000000009c0c SOFTE: 0 NIP [0000000000000000] (null) LR [0000000000009c14] 0x9c14 Call Trace: [c0000007e1a7bba0] [c00000000041a7f4] avc_has_perm_noaudit+0x54/0x110 (unreliable) [c0000007e1a7bd80] [c00000000002ddc0] ppc_rtas+0x150/0x2d0 [c0000007e1a7be30] [c000000000009358] syscall_exit+0x0/0x98 Fixes: 55190f88789a ("powerpc: Add skeleton PowerNV platform") Reported-by: NAGESWARA R. SASTRY Signed-off-by: Vasant Hegde [mpe: Reword change log, trim oops, and add stable + fixes] Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit ec14245c8839c2c896828944b7ad91799290591e Author: Joerg Roedel Date: Tue Oct 20 14:59:36 2015 +0200 iommu/amd: Don't clear DTE flags when modifying it commit cbf3ccd09d683abf1cacd36e3640872ee912d99b upstream. During device assignment/deassignment the flags in the DTE get lost, which might cause spurious faults, for example when the device tries to access the system management range. Fix this by not clearing the flags with the rest of the DTE. Reported-by: G. Richard Bellamy Tested-by: G. Richard Bellamy Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit e57ed4a9ec1fd07524a54c2d70d474a2ac7dd642 Author: Jay Cornwall Date: Wed Sep 16 14:10:03 2015 -0500 iommu/amd: Fix BUG when faulting a PROT_NONE VMA commit d14f6fced5f9360edca5a1325ddb7077aab1203b upstream. handle_mm_fault indirectly triggers a BUG in do_numa_page when given a VMA without read/write/execute access. Check this condition in do_fault. do_fault -> handle_mm_fault -> handle_pte_fault -> do_numa_page mm/memory.c 3147 static int do_numa_page(struct mm_struct *mm, struct vm_area_struct *vma, .... 3159 /* A PROT_NONE fault should not end up here */ 3160 BUG_ON(!(vma->vm_flags & (VM_READ | VM_EXEC | VM_WRITE))); Signed-off-by: Jay Cornwall Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 0ffd54b0691964badb30740cb959c0d18f9df2b4 Author: Christian Zander Date: Wed Jun 10 09:41:45 2015 -0700 iommu/vt-d: fix range computation when making room for large pages commit ba2374fd2bf379f933773811fdb06cb6a5445f41 upstream. In preparation for the installation of a large page, any small page tables that may still exist in the target IOV address range are removed. However, if a scatter/gather list entry is large enough to fit more than one large page, the address space for any subsequent large pages is not cleared of conflicting small page tables. This can cause legitimate mapping requests to fail with errors of the form below, potentially followed by a series of IOMMU faults: ERROR: DMA PTE for vPFN 0xfde00 already set (to 7f83a4003 not 7e9e00083) In this example, a 4MiB scatter/gather list entry resulted in the successful installation of a large page @ vPFN 0xfdc00, followed by a failed attempt to install another large page @ vPFN 0xfde00, due to the presence of a pointer to a small page table @ 0x7f83a4000. To address this problem, compute the number of large pages that fit into a given scatter/gather list entry, and use it to derive the last vPFN covered by the large page(s). Signed-off-by: Christian Zander Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit de51735f573653dd48457a5b6685cb309bd28a93 Author: Luca Coelho Date: Tue Sep 22 09:44:39 2015 +0300 iwlwifi: pci: add a few more PCI subvendor IDs for the 7265 series commit f08f625876476b6c4a87834dc86e3b927f4697d2 upstream. Add 3 new subdevice IDs for the 0x095A device ID and 2 for the 0x095B device ID. Reported-by: Jeremy Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit 85a0a97160e50fa875e15ab29c11204b3065c014 Author: Andrei Otcheretianski Date: Wed Sep 30 12:26:23 2015 +0200 iwlwifi: mvm: flush fw_dump_wk when mvm fails to start commit dbf73d4a8bb8f4e1d1f3edd3be825692279e2ef3 upstream. FW dump may be triggered when running init ucode, for example due to a sysassert. In this case fw_dump_wk may run after mvm is freed, resulting in a kernel panic. Fix it by flushing the work. Fixes: 01b988a708af ("iwlwifi: mvm: allow to collect debug data when restart is disabled") Signed-off-by: Andrei Otcheretianski Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit 6bad4a2190270da0dcb6092c362b53e55a209353 Author: Arik Nemtsov Date: Wed Sep 30 11:19:55 2015 +0300 iwlwifi: mvm: init card correctly on ctkill exit check commit 1a3fe0b2b6778b7866e2b3f5c9a299d5e9bbd89c upstream. During the CT-kill exit flow, the card is powered up and partially initialized to check if the temperature is already low enough. Unfortunately the init bails early because the CT-kill flag is set. Make the code bail early only for HW RF-kill, as was intended by the author. CT-kill is self-imposed and is not really RF-kill. Fixes: 31b8b343e019 ("iwlwifi: fix RFkill while calibrating") Signed-off-by: Arik Nemtsov Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit d92a04a5c1fdf51adb136b80516de9a0e7f2d003 Author: Johannes Berg Date: Tue Sep 15 14:36:09 2015 +0200 iwlwifi: mvm: fix D3 firmware PN programming commit 2cf5eb3ab7bb7f2e3a70edcef236cd62c87db030 upstream. The code to send the RX PN data (for each TID) to the firmware has a devastating bug: it overwrites the data for TID 0 with all the TID data, leaving the remaining TIDs zeroed. This will allow replays to actually be accepted by the firmware, which could allow waking up the system. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit 1db9f3850873698406ef01fb4095b891da6ec56f Author: Johannes Berg Date: Tue Sep 15 09:58:53 2015 +0200 iwlwifi: mvm: fix D3 CCMP TX PN assignment commit 6645d5e441db9121793421d477255f4242b3dbf3 upstream. When going into/coming out of D3, the TX PN must be programmed into and restored from the firmware respectively. The restore was broken due to my previous commit to move PN assignment into the driver. Sending the PN to the firmware still worked since we now use the counter that's shared with mac80211, but accessing it through the mac80211 API makes no sense now. Fix this by reading/writing the counter directly. This actually simplifies the code since we don't need to round-trip through the key_seq structure. Fixes: ca8c0f4bede6 ("iwlwifi: mvm: move TX PN assignment for CCMP to the driver") Reported-by: Luca Coelho Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit ff41ab55a6a0f987982e37ab09f89b0f2bedb8d0 Author: Avraham Stern Date: Mon Aug 31 11:08:27 2015 +0300 iwlwifi: mvm: clear csa countdown when AP is stopped commit e9cb0327b26dd7ba43a3b7a05b4b62219decf42d upstream. The csa_countdown flag was not cleared when the AP is stopped. As a result, if the AP was stopped after csa_countdown had started, all the folowing channel switch commands would fail. Fix that by clearing the csa_countdown flag when the AP is stopped. Signed-off-by: Avraham Stern Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit a05ca56df38c795cf9ccc223767ea10d4c8bfb4f Author: Larry Finger Date: Fri Oct 2 11:44:30 2015 -0500 rtlwifi: rtl8821ae: Fix system lockups on boot commit 54328e64047a54b8fc2362c2e1f0fa16c90f739f upstream. In commit 1277fa2ab2f9 ("rtlwifi: Remove the clear interrupt routine from all drivers"), the code that cleared all interrupt enable bits before setting them was removed for all PCI drivers. This fixed an issue that caused TX to be blocked for 3-5 seconds. On some RTL8821AE units, this change causes soft lockups to occur on boot. For that reason, the portion of the earlier commit that applied to rtl8821ae is reverted. Kernels 4.1 and newer are affected. See http://marc.info/?l=linux-wireless&m=144373370103285&w=2 and https://bugzilla.opensuse.org/show_bug.cgi?id=944978 for two cases where this regression affected user systems. Note that this bug does not appear on any of the developer's setups. For those users whose systems are affected by the TX blockage, but do not lock up on boot, a module parameter is added to disable the interrupt clear Fixes: 1277fa2ab2f9 ("rtlwifi: Remove the clear interrupt routine from all drivers") Signed-off-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 74ca117328b38a74dd2a7c563200a8f1f2caa2b1 Author: Johannes Berg Date: Tue Sep 22 10:47:27 2015 +0200 iwlwifi: fix firmware filename for 3160 commit b5a48134f8af08f5243328f8a0b05fc5ae7cf343 upstream. The MODULE_FIRMWARE() for 3160 should be using the 7260 version as it's done in the device configuration struct instead of referencing IWL3160_UCODE_API_OK which doesn't even exist. Reported-by: Hauke Mehrtens Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit b33a7b4139431ecbdfc21fb41d1a6f9c6747deb1 Author: Johannes Berg Date: Tue Sep 15 14:36:09 2015 +0200 iwlwifi: dvm: fix D3 firmware PN programming commit 5bd166872d8f99f156fac191299d24f828bb2348 upstream. The code to send the RX PN data (for each TID) to the firmware has a devastating bug: it overwrites the data for TID 0 with all the TID data, leaving the remaining TIDs zeroed. This will allow replays to actually be accepted by the firmware, which could allow waking up the system. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit e8fcf6b75dce84d0966f3434dafce12e346bd180 Author: Chaotian Jing Date: Mon Oct 12 17:22:23 2015 +0800 mmc: core: Fix init_card in 52Mhz commit 08b137d90eec51b0e90c42e123ca8ceb118d233f upstream. Suppose that we got a data crc error, and it triggers the mmc_reset. mmc_reset will call mmc_send_status to see if HW reset was supported. before issue CMD13, it will do retune, and if EMMC was in HS400 mode, it will reduce frequency to 52Mhz firstly, then results in card init was doing at 52Mhz. The mmc_send_status was originally only done for mmc_test, should drop it. And, rename the "eMMC hardware reset" to "Reset test", as we would also be able to use the test for SD-cards. Signed-off-by: Chaotian Jing Suggested-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 376445b8dfae8a1a67146bde697e2182ebede645 Author: Felix Fietkau Date: Thu Sep 24 16:59:46 2015 +0200 ath9k: declare required extra tx headroom commit 029cd0370241641eb70235d205aa0b90c84dce44 upstream. ath9k inserts padding between the 802.11 header and the data area (to align it). Since it didn't declare this extra required headroom, this led to some nasty issues like randomly dropped packets in some setups. Signed-off-by: Felix Fietkau Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 718779e39c9f1d94164a5a62b7617b266b5d94c4 Author: Mohammed Shafi Shajakhan Date: Thu Oct 8 19:20:14 2015 +0530 mac80211: Fix hwflags debugfs file format commit 4633dfc32c0019bed2996de9bbdbe7f3b518a44e upstream. Commit 30686bf7f5b3 ("mac80211: convert HW flags to unsigned long bitmap") accidentally removed the newline delimiter from the hwflags debugfs file. Fix this by adding back the newline between the HW flags. Signed-off-by: Mohammed Shafi Shajakhan [fix commit log] Signed-off-by: Jouni Malinen Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman