commit a17f9bf1f7cd3412b9920577a7c0ec34cb81b233 Author: Greg Kroah-Hartman Date: Wed Feb 11 15:01:12 2015 +0800 Linux 3.18.7 commit 61cfce3e9a5de651613a0d01aecf2d08133f4bdd Author: Linus Torvalds Date: Mon Dec 15 14:46:06 2014 -0800 x86: mm: move mmap_sem unlock from mm_fault_error() to caller commit 7fb08eca45270d0ae86e1ad9d39c40b7a55d0190 upstream. This replaces four copies in various stages of mm_fault_error() handling with just a single one. It will also allow for more natural placement of the unlocking after some further cleanup. Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 299f45902ab03c0f8a58ef1c9a02567b180e1f80 Author: Steven Rostedt (Red Hat) Date: Fri Feb 6 14:18:19 2015 -0500 x86/tlb/trace: Do not trace on CPU that is offline commit 6c8465a82a605bc692304bab42703017dcfff013 upstream. When taking a CPU down for suspend and resume, a tracepoint may be called when the CPU has been designated offline. As tracepoints require RCU for protection, they must not be called if the current CPU is offline. Unfortunately, trace_tlb_flush() is called in this scenario as was noted by LOCKDEP: ... Disabling non-boot CPUs ... intel_pstate CPU 1 exiting =============================== smpboot: CPU 1 didn't die... [ INFO: suspicious RCU usage. ] 3.19.0-rc7-next-20150204.1-iniza-small #1 Not tainted ------------------------------- include/trace/events/tlb.h:35 suspicious rcu_dereference_check() usage! other info that might help us debug this: RCU used illegally from offline CPU! rcu_scheduler_active = 1, debug_locks = 0 no locks held by swapper/1/0. stack backtrace: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.19.0-rc7-next-20150204.1-iniza-small #1 Hardware name: SAMSUNG ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 0000000000000001 ffff88011a44fe18 ffffffff817e370d 0000000000000011 ffff88011a448290 ffff88011a44fe48 ffffffff810d6847 ffff8800c66b9600 0000000000000001 ffff88011a44c000 ffffffff81cb3900 ffff88011a44fe78 Call Trace: [] dump_stack+0x4c/0x65 [] lockdep_rcu_suspicious+0xe7/0x120 [] idle_task_exit+0x205/0x2c0 [] play_dead_common+0xe/0x50 [] native_play_dead+0x15/0x140 [] arch_cpu_idle_dead+0xf/0x20 [] cpu_startup_entry+0x37e/0x580 [] start_secondary+0x140/0x150 intel_pstate CPU 2 exiting ... By converting the tlb_flush tracepoint to a TRACE_EVENT_CONDITION where the condition is cpu_online(smp_processor_id()), we can avoid calling RCU protected code when the CPU is offline. Link: http://lkml.kernel.org/r/CA+icZUUGiGDoL5NU8RuxKzFjoLjEKRtUWx=JB8B9a0EQv-eGzQ@mail.gmail.com Fixes: d17d8f9dedb9 "x86/mm: Add tracepoints for TLB flushes" Reported-by: Sedat Dilek Tested-by: Sedat Dilek Suggested-by: Paul E. McKenney Acked-by: Paul E. McKenney Acked-by: Dave Hansen Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 409b0c0169147e8e392886ca441cc95e314b5faf Author: Steven Rostedt (Red Hat) Date: Fri Feb 6 14:30:50 2015 -0500 tracing: Add condition check to RCU lockdep checks commit a05d59a5673339ef6936d6940cdf68172ce75b9f upstream. The trace_tlb_flush() tracepoint can be called when a CPU is going offline. When a CPU is offline, RCU is no longer watching that CPU and since the tracepoint is protected by RCU, it must not be called. To prevent the tlb_flush tracepoint from being called when the CPU is offline, it was converted to a TRACE_EVENT_CONDITION where the condition checks if the CPU is online before calling the tracepoint. Unfortunately, this was not enough to stop lockdep from complaining about it. Even though the RCU protected code of the tracepoint will never be called, the condition is hidden within the tracepoint, and even though the condition prevents RCU code from being called, the lockdep checks are outside the tracepoint (this is to test tracepoints even when they are not enabled). Even though tracepoints should be checked to be RCU safe when they are not enabled, the condition should still be considered when checking RCU. Link: http://lkml.kernel.org/r/CA+icZUUGiGDoL5NU8RuxKzFjoLjEKRtUWx=JB8B9a0EQv-eGzQ@mail.gmail.com Fixes: 3a630178fd5f "tracing: generate RCU warnings even when tracepoints are disabled" Acked-by: Dave Hansen Reported-by: Sedat Dilek Tested-by: Sedat Dilek Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit fef76eabdf6f5bd033de2353f27dccbeea60c066 Author: John Stultz Date: Wed Feb 4 16:45:26 2015 -0800 hrtimer: Fix incorrect tai offset calculation for non high-res timer systems commit 2d926c15d629a13914ce3e5f26354f6a0ac99e70 upstream. I noticed some CLOCK_TAI timer test failures on one of my less-frequently used configurations. And after digging in I found in 76f4108892d9 (Cleanup hrtimer accessors to the timekepeing state), the hrtimer_get_softirq_time tai offset calucation was incorrectly rewritten, as the tai offset we return shold be from CLOCK_MONOTONIC, and not CLOCK_REALTIME. This results in CLOCK_TAI timers expiring early on non-highres capable machines. This patch fixes the issue, calculating the tai time properly from the monotonic base. Signed-off-by: John Stultz Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1423097126-10236-1-git-send-email-john.stultz@linaro.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 1c3a363299b98f41fce0d7232ebf2b40db39d0a2 Author: Lai Jiangshan Date: Thu Jul 31 11:30:17 2014 +0800 smpboot: Add missing get_online_cpus() in smpboot_register_percpu_thread() commit 4bee96860a65c3a62d332edac331b3cf936ba3ad upstream. The following race exists in the smpboot percpu threads management: CPU0 CPU1 cpu_up(2) get_online_cpus(); smpboot_create_threads(2); smpboot_register_percpu_thread(); for_each_online_cpu(); __smpboot_create_thread(); __cpu_up(2); This results in a missing per cpu thread for the newly onlined cpu2 and in a NULL pointer dereference on a consecutive offline of that cpu. Proctect smpboot_register_percpu_thread() with get_online_cpus() to prevent that. [ tglx: Massaged changelog and removed the change in smpboot_unregister_percpu_thread() because that's an optimization and therefor not stable material. ] Signed-off-by: Lai Jiangshan Cc: Thomas Gleixner Cc: Rusty Russell Cc: Peter Zijlstra Cc: Srivatsa S. Bhat Cc: David Rientjes Link: http://lkml.kernel.org/r/1406777421-12830-1-git-send-email-laijs@cn.fujitsu.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit ff0d1886ef0210b5dbc08934340aaf029b59aea4 Author: Boris Ostrovsky Date: Tue Jan 27 21:21:09 2015 -0500 x86, microcode: Return error from driver init code when loader is disabled commit da63865a01c6384d459464e5165d95d4f04878d8 upstream. Commits 65cef1311d5d ("x86, microcode: Add a disable chicken bit") and a18a0f6850d4 ("x86, microcode: Don't initialize microcode code on paravirt") allow microcode driver skip initialization when microcode loading is not permitted. However, they don't prevent the driver from being loaded since the init code returns 0. If at some point later the driver gets unloaded this will result in an oops while trying to deregister the (never registered) device. To avoid this, make init code return an error on paravirt or when microcode loading is disabled. The driver will then never be loaded. Signed-off-by: Boris Ostrovsky Link: http://lkml.kernel.org/r/1422411669-25147-1-git-send-email-boris.ostrovsky@oracle.com Reported-by: James Digwall Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman commit 6ea9ca8008cf8261dbcd86f6d210f6aefe8d338a Author: Sylwester Nawrocki Date: Tue Feb 3 15:06:22 2015 +0100 ARM: dts: Fix I2S1, I2S2 compatible for exynos4 SoCs commit fddcd300732dad5b822d27de7aa78998dca43162 upstream. I2S1, I2S2 on Exynos4 SoC series have limited functionality compared to I2S0, "samsung,s3c6410-i2s" compatible should be used for them. Signed-off-by: Sylwester Nawrocki Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit dde496323a083335c309dbd7d7a4ccc1afa4b8f8 Author: Takashi Iwai Date: Tue Jan 13 10:53:20 2015 +0100 ALSA: ak411x: Fix stall in work callback commit 4161b4505f1690358ac0a9ee59845a7887336b21 upstream. When ak4114 work calls its callback and the callback invokes ak4114_reinit(), it stalls due to flush_delayed_work(). For avoiding this, control the reentrance by introducing a refcount. Also flush_delayed_work() is replaced with cancel_delayed_work_sync(). The exactly same bug is present in ak4113.c and fixed as well. Reported-by: Pavel Hofman Acked-by: Jaroslav Kysela Tested-by: Pavel Hofman Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 085d9e9eeac3a48b6abc5bcd4ba9c92629d5c31b Author: Eric Nelson Date: Fri Jan 30 14:07:55 2015 -0700 ASoC: sgtl5000: add delay before first I2C access commit 58cc9c9a175885bbf6bae3acf18233d0a8229a84 upstream. To quote from section 1.3.1 of the data sheet: The SGTL5000 has an internal reset that is deasserted 8 SYS_MCLK cycles after all power rails have been brought up. After this time, communication can start ... 1.0us represents 8 SYS_MCLK cycles at the minimum 8.0 MHz SYS_MCLK. Signed-off-by: Eric Nelson Reviewed-by: Fabio Estevam Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c0c9fe847aa4504d7f19fb9db7fbfc5ee0df8fd5 Author: Bo Shen Date: Tue Jan 20 15:43:16 2015 +0800 ASoC: atmel_ssc_dai: fix start event for I2S mode commit a43bd7e125143b875caae6d4f9938855b440faaf upstream. According to the I2S specification information as following: - WS = 0, channel 1 (left) - WS = 1, channel 2 (right) So, the start event should be TF/RF falling edge. Reported-by: Songjun Wu Signed-off-by: Bo Shen Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 31bf97f51154cc669513b329d395bcad37b9e213 Author: karl beldan Date: Thu Jan 29 11:10:22 2015 +0100 lib/checksum.c: fix build for generic csum_tcpudp_nofold commit 9ce357795ef208faa0d59894d9d119a7434e37f3 upstream. Fixed commit added from64to32 under _#ifndef do_csum_ but used it under _#ifndef csum_tcpudp_nofold_, breaking some builds (Fengguang's robot reported TILEGX's). Move from64to32 under the latter. Fixes: 150ae0e94634 ("lib/checksum.c: fix carry in csum_tcpudp_nofold") Reported-by: kbuild test robot Signed-off-by: Karl Beldan Cc: Eric Dumazet Cc: David S. Miller Signed-off-by: David S. Miller Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 1fb326794a28f6d1377d563fae6b31d9c0db2f54 Author: Mark Rutland Date: Fri Oct 24 14:56:40 2014 +0100 arm64: Fix up /proc/cpuinfo commit 44b82b7700d05a52cd983799d3ecde1a976b3bed upstream. Commit d7a49086f263164a (arm64: cpuinfo: print info for all CPUs) attempted to clean up /proc/cpuinfo, but due to concerns regarding further changes was reverted in commit 5e39977edf6500fd (Revert "arm64: cpuinfo: print info for all CPUs"). There are two major issues with the arm64 /proc/cpuinfo format currently: * The "Features" line describes (only) the 64-bit hwcaps, which is problematic for some 32-bit applications which attempt to parse it. As the same names are used for analogous ISA features (e.g. aes) despite these generally being architecturally unrelated, it is not possible to simply append the 64-bit and 32-bit hwcaps in a manner that might not be misleading to some applications. Various potential solutions have appeared in vendor kernels. Typically the format of the Features line varies depending on whether the task is 32-bit. * Information is only printed regarding a single CPU. This does not match the ARM format, and does not provide sufficient information in big.LITTLE systems where CPUs are heterogeneous. The CPU information printed is queried from the current CPU's registers, which is racy w.r.t. cross-cpu migration. This patch attempts to solve these issues. The following changes are made: * When a task with a LINUX32 personality attempts to read /proc/cpuinfo, the "Features" line contains the decoded 32-bit hwcaps, as with the arm port. Otherwise, the decoded 64-bit hwcaps are shown. This aligns with the behaviour of COMPAT_UTS_MACHINE and COMPAT_ELF_PLATFORM. In the absense of compat support, the Features line is empty. The set of hwcaps injected into a task's auxval are unaffected. * Properties are printed per-cpu, as with the ARM port. The per-cpu information is queried from pre-recorded cpu information (as used by the sanity checks). * As with the previous attempt at fixing up /proc/cpuinfo, the hardware field is removed. The only users so far are 32-bit applications tied to particular boards, so no portable applications should be affected, and this should prevent future tying to particular boards. The following differences remain: * No model_name is printed, as this cannot be queried from the hardware and cannot be provided in a stable fashion. Use of the CPU {implementor,variant,part,revision} fields is sufficient to identify a CPU and is portable across arm and arm64. * The following system-wide properties are not provided, as they are not possible to provide generally. Programs relying on these are already tied to particular (32-bit only) boards: - Hardware - Revision - Serial No software has yet been identified for which these remaining differences are problematic. Cc: Greg Hackmann Cc: Ian Campbell Cc: Serban Constantinescu Cc: Will Deacon Cc: cross-distro@lists.linaro.org Cc: linux-api@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Acked-by: Catalin Marinas Signed-off-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit e5e10c028918b58e16e8413560076e550fd9ab41 Author: Peter Kümmel Date: Tue Nov 4 12:01:59 2014 +0100 kconfig: Fix warning "‘jump’ may be used uninitialized" commit 2d560306096739e2251329ab5c16059311a151b0 upstream. Warning: In file included from scripts/kconfig/zconf.tab.c:2537:0: scripts/kconfig/menu.c: In function ‘get_symbol_str’: scripts/kconfig/menu.c:590:18: warning: ‘jump’ may be used uninitialized in this function [-Wmaybe-uninitialized] jump->offset = strlen(r->s); Simplifies the test logic because (head && local) means (jump != 0) and makes GCC happy when checking if the jump pointer was initialized. Signed-off-by: Peter Kümmel Signed-off-by: Michal Marek Cc: Sedat Dilek Signed-off-by: Greg Kroah-Hartman commit 4fb5076bf3be220b86b9971e92b68657a6eb9080 Author: Alex Deucher Date: Fri Jan 30 09:52:24 2015 -0500 drm/radeon: properly set vm fragment size for TN/RL commit a124d068bf5be6be2ff4b9fab77b1b7509107e68 upstream. Should be the same as cayman. We don't use VM by default on NI parts so this isn't critical. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 83108f22385e9f34761dc3a0c77bdc985a467e77 Author: Ilija Hadzic Date: Fri Jan 30 00:38:44 2015 -0500 drm/radeon: fix the crash in test functions commit 92b712b739811e4aa7c0e1af339d0098989ea024 upstream. radeon_copy_dma and radeon_copy_blit must be called with a valid reservation object. Otherwise a crash will be provoked. We borrow the object from vram BO. bug: https://bugs.freedesktop.org/show_bug.cgi?id=88464 Reviewed-by: Christian König Signed-off-by: Ilija Hadzic Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 624ddd1be9fcd6fd30ce5563e87dfd27ab920a68 Author: Ilija Hadzic Date: Fri Jan 30 00:38:43 2015 -0500 drm/radeon: fix the crash in benchmark functions commit 3f5e1b4f58b7b6480cccff4bf965436102db4346 upstream. radeon_copy_dma and radeon_copy_blit must be called with a valid reservation object. Otherwise a crash will be provoked. We borrow the object from destination BO. bug: https://bugs.freedesktop.org/show_bug.cgi?id=88464 Reviewed-by: Christian König Signed-off-by: Ilija Hadzic Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 7530584f8c7d2ded28dd72e0dbf17c2bff085107 Author: Christian König Date: Thu Jan 29 16:01:03 2015 +0100 drm/radeon: fix PLLs on RS880 and older v2 commit 72edd83cc9e5819ed1ee771519143d7594e059f0 upstream. This is a workaround for RS880 and older chips which seem to have an additional limit on the minimum PLL input frequency. v2: fix signed/unsigned warning bugs: https://bugzilla.kernel.org/show_bug.cgi?id=91861 https://bugzilla.kernel.org/show_bug.cgi?id=83461 Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 2a1398b3317fbc5d2efe1c0089dc56414286dc6b Author: Alex Deucher Date: Wed Jan 28 14:36:26 2015 -0500 drm/radeon: don't init gpuvm if accel is disabled (v3) commit 544143f9e01a60a93eb00ab4bfcb9bf4702a2a7d upstream. If acceleration is disabled, it does not make sense to init gpuvm since nothing will use it. Moreover, if radeon_vm_init() gets called it uses accel to try and clear the pde tables, etc. which results in a bug. v2: handle vm_fini as well v3: handle bo_open/close as well Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88786 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 7bb9e4a06e12583f1418b669dc45bb3ee84496c6 Author: Ryusuke Konishi Date: Thu Feb 5 12:25:20 2015 -0800 nilfs2: fix deadlock of segment constructor over I_SYNC flag commit 7ef3ff2fea8bf5e4a21cef47ad87710a3d0fdb52 upstream. Nilfs2 eventually hangs in a stress test with fsstress program. This issue was caused by the following deadlock over I_SYNC flag between nilfs_segctor_thread() and writeback_sb_inodes(): nilfs_segctor_thread() nilfs_segctor_thread_construct() nilfs_segctor_unlock() nilfs_dispose_list() iput() iput_final() evict() inode_wait_for_writeback() * wait for I_SYNC flag writeback_sb_inodes() * set I_SYNC flag on inode->i_state __writeback_single_inode() do_writepages() nilfs_writepages() nilfs_construct_dsync_segment() nilfs_segctor_sync() * wait for completion of segment constructor inode_sync_complete() * clear I_SYNC flag after __writeback_single_inode() completed writeback_sb_inodes() calls do_writepages() for dirty inodes after setting I_SYNC flag on inode->i_state. do_writepages() in turn calls nilfs_writepages(), which can run segment constructor and wait for its completion. On the other hand, segment constructor calls iput(), which can call evict() and wait for the I_SYNC flag on inode_wait_for_writeback(). Since segment constructor doesn't know when I_SYNC will be set, it cannot know whether iput() will block or not unless inode->i_nlink has a non-zero count. We can prevent evict() from being called in iput() by implementing sop->drop_inode(), but it's not preferable to leave inodes with i_nlink == 0 for long periods because it even defers file truncation and inode deallocation. So, this instead resolves the deadlock by calling iput() asynchronously with a workqueue for inodes with i_nlink == 0. Signed-off-by: Ryusuke Konishi Cc: Al Viro Tested-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 32a7d7c223484fd9b8c5143bdbb08d3146931f1a Author: Michal Hocko Date: Thu Feb 5 12:25:14 2015 -0800 memcg, shmem: fix shmem migration to use lrucare commit f5e03a4989e80a86f8b514659dca8539132e6e09 upstream. It has been reported that 965GM might trigger VM_BUG_ON_PAGE(!lrucare && PageLRU(oldpage), oldpage) in mem_cgroup_migrate when shmem wants to replace a swap cache page because of shmem_should_replace_page (the page is allocated from an inappropriate zone). shmem_replace_page expects that the oldpage is not on LRU list and calls mem_cgroup_migrate without lrucare. This is obviously incorrect because swapcache pages might be on the LRU list (e.g. swapin readahead page). Fix this by enabling lrucare for the migration in shmem_replace_page. Also clarify that lrucare should be used even if one of the pages might be on LRU list. The BUG_ON will trigger only when CONFIG_DEBUG_VM is enabled but even without that the migration code might leave the old page on an inappropriate memcg' LRU which is not that critical because the page would get removed with its last reference but it is still confusing. Fixes: 0a31bc97c80c ("mm: memcontrol: rewrite uncharge API") Signed-off-by: Michal Hocko Reported-by: Chris Wilson Reported-by: Dave Airlie Acked-by: Hugh Dickins Acked-by: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a01e1611c00e826b3a0f79c8c842f19593ffb71e Author: karl beldan Date: Wed Jan 28 10:58:11 2015 +0100 lib/checksum.c: fix carry in csum_tcpudp_nofold commit 150ae0e94634714b23919f0c333fee28a5b199d5 upstream. The carry from the 64->32bits folding was dropped, e.g with: saddr=0xFFFFFFFF daddr=0xFF0000FF len=0xFFFF proto=0 sum=1, csum_tcpudp_nofold returned 0 instead of 1. Signed-off-by: Karl Beldan Cc: Al Viro Cc: Eric Dumazet Cc: Arnd Bergmann Cc: Mike Frysinger Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 00034998ed036fb69523cb3addd878d855fb0718 Author: Shiraz Hashim Date: Thu Feb 5 12:25:06 2015 -0800 mm: pagewalk: call pte_hole() for VM_PFNMAP during walk_page_range commit 23aaed6659df9adfabe9c583e67a36b54e21df46 upstream. walk_page_range() silently skips vma having VM_PFNMAP set, which leads to undesirable behaviour at client end (who called walk_page_range). Userspace applications get the wrong data, so the effect is like just confusing users (if the applications just display the data) or sometimes killing the processes (if the applications do something with misunderstanding virtual addresses due to the wrong data.) For example for pagemap_read, when no callbacks are called against VM_PFNMAP vma, pagemap_read may prepare pagemap data for next virtual address range at wrong index. Eventually userspace may get wrong pagemap data for a task. Corresponding to a VM_PFNMAP marked vma region, kernel may report mappings from subsequent vma regions. User space in turn may account more pages (than really are) to the task. In my case I was using procmem, procrack (Android utility) which uses pagemap interface to account RSS pages of a task. Due to this bug it was giving a wrong picture for vmas (with VM_PFNMAP set). Fixes: a9ff785e4437 ("mm/pagewalk.c: walk_page_range should avoid VM_PFNMAP areas") Signed-off-by: Shiraz Hashim Acked-by: Naoya Horiguchi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d2d9e9edf939ea938921f0e6c7e3151a308d4411 Author: NeilBrown Date: Mon Feb 2 10:44:29 2015 +1100 md/raid5: fix another livelock caused by non-aligned writes. commit b1b02fe97f75b12ab34b2303bfd4e3526d903a58 upstream. If a non-page-aligned write is destined for a device which is missing/faulty, we can deadlock. As the target device is missing, a read-modify-write cycle is not possible. As the write is not for a full-page, a recontruct-write cycle is not possible. This should be handled by logic in fetch_block() which notices there is a non-R5_OVERWRITE write to a missing device, and so loads all blocks. However since commit 67f455486d2ea2, that code requires STRIPE_PREREAD_ACTIVE before it will active, and those circumstances never set STRIPE_PREREAD_ACTIVE. So: in handle_stripe_dirtying, if neither rmw or rcw was possible, set STRIPE_DELAYED, which will cause STRIPE_PREREAD_ACTIVE be set after a suitable delay. Fixes: 67f455486d2ea20b2d94d6adf5b9b783d079e321 Reported-by: Mikulas Patocka Tested-by: Heinz Mauelshagen Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 0e8422433e621f9df297bbe07e12b851679d3dbe Author: Sachin Prabhu Date: Thu Jan 15 12:22:04 2015 +0000 Complete oplock break jobs before closing file handle commit ca7df8e0bb2a5ec79691de8a1a4c0e611fe04e60 upstream. Commit c11f1df5003d534fd067f0168bfad7befffb3b5c requires writers to wait for any pending oplock break handler to complete before proceeding to write. This is done by waiting on bit CIFS_INODE_PENDING_OPLOCK_BREAK in cifsFileInfo->flags. This bit is cleared by the oplock break handler job queued on the workqueue once it has completed handling the oplock break allowing writers to proceed with writing to the file. While testing, it was noticed that the filehandle could be closed while there is a pending oplock break which results in the oplock break handler on the cifsiod workqueue being cancelled before it has had a chance to execute and clear the CIFS_INODE_PENDING_OPLOCK_BREAK bit. Any subsequent attempt to write to this file hangs waiting for the CIFS_INODE_PENDING_OPLOCK_BREAK bit to be cleared. We fix this by ensuring that we also clear the bit CIFS_INODE_PENDING_OPLOCK_BREAK when we remove the oplock break handler from the workqueue. The bug was found by Red Hat QA while testing using ltp's fsstress command. Signed-off-by: Sachin Prabhu Acked-by: Shirish Pargaonkar Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 714a56fcacf3ba084d71d77c5e3cbf580924d5ca Author: Will Deacon Date: Thu Jan 29 16:41:46 2015 +0100 ARM: 8299/1: mm: ensure local active ASID is marked as allocated on rollover commit 8e64806672466392acf19e14427d1c29df3e58b9 upstream. Commit e1a5848e3398 ("ARM: 7924/1: mm: don't bother with reserved ttbr0 when running with LPAE") removed the use of the reserved TTBR0 value for LPAE systems, since the ASID is held in the TTBR and can be updated atomicly with the pgd of the next mm. Unfortunately, this patch forgot to update flush_context, which deliberately avoids marking the local active ASID as allocated, since we used to switch via ASID zero and didn't need to allocate the ASID of the previous mm. The side-effect of this is that we can allocate the same ASID to the next mm and, between flushing the local TLB and updating TTBR0, we can perform speculative TLB fills for userspace nG mappings using the page table of the previous mm. The consequence of this is that the next mm can erroneously hit some mappings of the previous mm. Note that this was made significantly harder to hit by a391263cd84e ("ARM: 8203/1: mm: try to re-use old ASID assignments following a rollover") but is still theoretically possible. This patch fixes the problem by removing the code from flush_context that forces the allocated ASID to zero for the local CPU. Many thanks to the Broadcom guys for tracking this one down. Fixes: e1a5848e3398 ("ARM: 7924/1: mm: don't bother with reserved ttbr0 when running with LPAE") Reported-by: Raymond Ngun Tested-by: Raymond Ngun Reviewed-by: Gregory Fong Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 2e9560ee64b7e35fa4974b5af08568d64627589f Author: James Hogan Date: Fri Jan 30 15:40:20 2015 +0000 MIPS: traps: Fix inline asm ctc1 missing .set hardfloat commit d76e9b9fc5de7e8fc4fd0e72a94e8c723929ffea upstream. Commit 842dfc11ea9a ("MIPS: Fix build with binutils 2.24.51+") in v3.18 enabled -msoft-float and sprinkled ".set hardfloat" where necessary to use FP instructions. However it missed enable_restore_fp_context() which since v3.17 does a ctc1 with inline assembly, causing the following assembler errors on Mentor's 2014.05 toolchain: {standard input}: Assembler messages: {standard input}:2913: Error: opcode not supported on this processor: mips32r2 (mips32r2) `ctc1 $2,$31' scripts/Makefile.build:257: recipe for target 'arch/mips/kernel/traps.o' failed Fix that to use the new write_32bit_cp1_register() macro so that ".set hardfloat" is automatically added when -msoft-float is in use. Fixes 842dfc11ea9a ("MIPS: Fix build with binutils 2.24.51+") Signed-off-by: James Hogan Cc: Ralf Baechle Cc: Paul Burton Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9173/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 061aa85590933429b76a8ec88aa4dc28122af78e Author: James Hogan Date: Fri Jan 30 15:40:19 2015 +0000 MIPS: mipsregs.h: Add write_32bit_cp1_register() commit 5e32033e14ca9c7f7341cb383f5a05699b0b5382 upstream. Add a write_32bit_cp1_register() macro to compliment the read_32bit_cp1_register() macro. This is to abstract whether .set hardfloat needs to be used based on GAS_HAS_SET_HARDFLOAT. The implementation of _read_32bit_cp1_register() .sets mips1 due to failure of gas v2.19 to assemble cfc1 for Octeon (see commit 25c300030016 ("MIPS: Override assembler target architecture for octeon.")). I haven't copied this over to _write_32bit_cp1_register() as I'm uncertain whether it applies to ctc1 too, or whether anybody cares about that version of binutils any longer. Signed-off-by: James Hogan Cc: Ralf Baechle Cc: Paul Burton Cc: David Daney Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9172/ Signed-off-by: Ralf Baechle Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 69ab8e5c2c49f7703b48ad4f350f436b9b8e7afb Author: Hemmo Nieminen Date: Thu Jan 15 23:01:59 2015 +0200 MIPS: Fix kernel lockup or crash after CPU offline/online commit c7754e75100ed5e3068ac5085747f2bfc386c8d6 upstream. As printk() invocation can cause e.g. a TLB miss, printk() cannot be called before the exception handlers have been properly initialized. This can happen e.g. when netconsole has been loaded as a kernel module and the TLB table has been cleared when a CPU was offline. Call cpu_report() in start_secondary() only after the exception handlers have been initialized to fix this. Without the patch the kernel will randomly either lockup or crash after a CPU is onlined and the console driver is a module. Signed-off-by: Hemmo Nieminen Signed-off-by: Aaro Koskinen Cc: David Daney Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/8953/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit a88c24fa0985354f3d8fc13f08a6c847f0541804 Author: Aaro Koskinen Date: Thu Jan 15 23:01:58 2015 +0200 MIPS: OCTEON: fix kernel crash when offlining a CPU commit 63a87fe0d0de2ce126a8cec9a299a133cfd5658e upstream. octeon_cpu_disable() will unconditionally enable interrupts when called. We can assume that the routine is always called with interrupts disabled, so just delete the incorrect local_irq_disable/enable(). The patch fixes the following crash when offlining a CPU: [ 93.818785] ------------[ cut here ]------------ [ 93.823421] WARNING: CPU: 1 PID: 10 at kernel/smp.c:231 flush_smp_call_function_queue+0x1c4/0x1d0() [ 93.836215] Modules linked in: [ 93.839287] CPU: 1 PID: 10 Comm: migration/1 Not tainted 3.19.0-rc4-octeon-los_b5f0 #1 [ 93.847212] Stack : 0000000000000001 ffffffff81b2cf90 0000000000000004 ffffffff81630000 0000000000000000 0000000000000000 0000000000000000 000000000000004a 0000000000000006 ffffffff8117e550 0000000000000000 0000000000000000 ffffffff81b30000 ffffffff81b26808 8000000032c77748 ffffffff81627e07 ffffffff81595ec8 ffffffff81b26808 000000000000000a 0000000000000001 0000000000000001 0000000000000003 0000000010008ce1 ffffffff815030c8 8000000032cbbb38 ffffffff8113d42c 0000000010008ce1 ffffffff8117f36c 8000000032c77300 8000000032cbba50 0000000000000001 ffffffff81503984 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ffffffff81121668 0000000000000000 0000000000000000 ... [ 93.912819] Call Trace: [ 93.915273] [] show_stack+0x68/0x80 [ 93.920335] [] dump_stack+0x6c/0x90 [ 93.925395] [] warn_slowpath_common+0x94/0xd8 [ 93.931324] [] flush_smp_call_function_queue+0x1c4/0x1d0 [ 93.938208] [] hotplug_cfd+0xf0/0x108 [ 93.943444] [] notifier_call_chain+0x5c/0xb8 [ 93.949286] [] cpu_notify+0x24/0x60 [ 93.954348] [] take_cpu_down+0x38/0x58 [ 93.959670] [] multi_cpu_stop+0x154/0x180 [ 93.965250] [] cpu_stopper_thread+0xd8/0x160 [ 93.971093] [] smpboot_thread_fn+0x1ec/0x1f8 [ 93.976936] [] kthread+0xd4/0xf0 [ 93.981735] [] ret_from_kernel_thread+0x14/0x1c [ 93.987835] [ 93.989326] ---[ end trace c9e3815ee655bda9 ]--- [ 93.993951] Kernel bug detected[#1]: [ 93.997533] CPU: 1 PID: 10 Comm: migration/1 Tainted: G W 3.19.0-rc4-octeon-los_b5f0 #1 [ 94.006591] task: 8000000032c77300 ti: 8000000032cb8000 task.ti: 8000000032cb8000 [ 94.014081] $ 0 : 0000000000000000 0000000010000ce1 0000000000000001 ffffffff81620000 [ 94.022146] $ 4 : 8000000002c72ac0 0000000000000000 00000000000001a7 ffffffff813b06f0 [ 94.030210] $ 8 : ffffffff813b20d8 0000000000000000 0000000000000000 ffffffff81630000 [ 94.038275] $12 : 0000000000000087 0000000000000000 0000000000000086 0000000000000000 [ 94.046339] $16 : ffffffff81623168 0000000000000001 0000000000000000 0000000000000008 [ 94.054405] $20 : 0000000000000001 0000000000000001 0000000000000001 0000000000000003 [ 94.062470] $24 : 0000000000000038 ffffffff813b7f10 [ 94.070536] $28 : 8000000032cb8000 8000000032cbbc20 0000000010008ce1 ffffffff811bcaf4 [ 94.078601] Hi : 0000000000f188e8 [ 94.082179] Lo : d4fdf3b646c09d55 [ 94.085760] epc : ffffffff811bc9d0 irq_work_run_list+0x8/0xf8 [ 94.091686] Tainted: G W [ 94.095613] ra : ffffffff811bcaf4 irq_work_run+0x34/0x60 [ 94.101192] Status: 10000ce3 KX SX UX KERNEL EXL IE [ 94.106235] Cause : 40808034 [ 94.109119] PrId : 000d9301 (Cavium Octeon II) [ 94.113653] Modules linked in: [ 94.116721] Process migration/1 (pid: 10, threadinfo=8000000032cb8000, task=8000000032c77300, tls=0000000000000000) [ 94.127168] Stack : 8000000002c74c80 ffffffff811a4128 0000000000000001 ffffffff81635720 fffffffffffffff2 ffffffff8115bacc 80000000320fbce0 80000000320fbca4 80000000320fbc80 0000000000000002 0000000000000004 ffffffff8113d704 80000000320fbce0 ffffffff81501738 0000000000000003 ffffffff811b343c 8000000002c72aa0 8000000002c72aa8 ffffffff8159cae8 ffffffff8159caa0 ffffffff81650000 80000000320fbbf0 80000000320fbc80 ffffffff811b32e8 0000000000000000 ffffffff811b3768 ffffffff81622b80 ffffffff815148a8 8000000032c77300 8000000002c73e80 ffffffff815148a8 8000000032c77300 ffffffff81622b80 ffffffff815148a8 8000000032c77300 ffffffff81503f48 ffffffff8115ea0c ffffffff81620000 0000000000000000 ffffffff81174d64 ... [ 94.192771] Call Trace: [ 94.195222] [] irq_work_run_list+0x8/0xf8 [ 94.200802] [] irq_work_run+0x34/0x60 [ 94.206036] [] hotplug_cfd+0xf0/0x108 [ 94.211269] [] notifier_call_chain+0x5c/0xb8 [ 94.217111] [] cpu_notify+0x24/0x60 [ 94.222171] [] take_cpu_down+0x38/0x58 [ 94.227491] [] multi_cpu_stop+0x154/0x180 [ 94.233072] [] cpu_stopper_thread+0xd8/0x160 [ 94.238914] [] smpboot_thread_fn+0x1ec/0x1f8 [ 94.244757] [] kthread+0xd4/0xf0 [ 94.249555] [] ret_from_kernel_thread+0x14/0x1c [ 94.255654] [ 94.257146] Code: a2423c40 40026000 30420001 <00020336> dc820000 10400037 00000000 0000010f 0000010f [ 94.267183] ---[ end trace c9e3815ee655bdaa ]--- [ 94.271804] Fatal exception: panic in 5 seconds Reported-by: Hemmo Nieminen Signed-off-by: Aaro Koskinen Acked-by: David Daney Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/8952/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 83c9c2c5a8ea60d2b9d8f50f4c201cafc57527af Author: Felix Fietkau Date: Thu Jan 15 19:05:28 2015 +0100 MIPS: IRQ: Fix disable_irq on CPU IRQs commit a3e6c1eff54878506b2dddcc202df9cc8180facb upstream. If the irq_chip does not define .irq_disable, any call to disable_irq will defer disabling the IRQ until it fires while marked as disabled. This assumes that the handler function checks for this condition, which handle_percpu_irq does not. In this case, calling disable_irq leads to an IRQ storm, if the interrupt fires while disabled. This optimization is only useful when disabling the IRQ is slow, which is not true for the MIPS CPU IRQ. Disable this optimization by implementing .irq_disable and .irq_enable Signed-off-by: Felix Fietkau Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/8949/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit dbbd2788801872e41894c4d371bf1155a355d382 Author: David Daney Date: Tue Jan 6 10:42:23 2015 -0800 MIPS: Fix C0_Pagegrain[IEC] support. commit 9ead8632bbf454cfc709b6205dc9cd8582fb0d64 upstream. The following commits: 5890f70f15c52d (MIPS: Use dedicated exception handler if CPU supports RI/XI exceptions) 6575b1d4173eae (MIPS: kernel: cpu-probe: Detect unique RI/XI exceptions) break the kernel for *all* existing MIPS CPUs that implement the CP0_PageGrain[IEC] bit. They cause the TLB exception handlers to be generated without the legacy execute-inhibit handling, but never set the CP0_PageGrain[IEC] bit to activate the use of dedicated exception vectors for execute-inhibit exceptions. The result is that upon detection of an execute-inhibit violation, we loop forever in the TLB exception handlers instead of sending SIGSEGV to the task. If we are generating TLB exception handlers expecting separate vectors, we must also enable the CP0_PageGrain[IEC] feature. The bug was introduced in kernel version 3.17. Signed-off-by: David Daney Cc: Leonid Yegoshin Cc: linux-mips@linux-mips.org Patchwork: http://patchwork.linux-mips.org/patch/8880/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 458919c470d3316ab86f5de005bc37ca9ae32a86 Author: Brian King Date: Thu Jan 29 15:54:40 2015 -0600 sd: Fix max transfer length for 4k disks commit 3a9794d32984b67a6d8992226918618f0e51e5d5 upstream. The following patch fixes an issue observed with 4k sector disks where the max_hw_sectors attribute was getting set too large in sd_revalidate_disk. Since sdkp->max_xfer_blocks is in units of SCSI logical blocks and queue_max_hw_sectors is in units of 512 byte blocks, on a 4k sector disk, every time we went through sd_revalidate_disk, we were taking the current value of queue_max_hw_sectors and increasing it by a factor of 8. Fix this by only shifting sdkp->max_xfer_blocks. Signed-off-by: Brian King Reviewed-by: Paolo Bonzini Reviewed-by: Martin K. Petersen Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit 0ee291a9b487015768465cfbf90366a43941a685 Author: Robin Gong Date: Tue Feb 3 10:25:53 2015 +0800 spi: imx: use pio mode for i.mx6dl commit a02bb401f8ae264be782ee57d98bdd99f14c8022 upstream. For TKT238285 hardware issue which may cause txfifo store data twice can only be caught on i.mx6dl, we use pio mode instead of DMA mode on i.mx6dl. Fixes: f62caccd12c17e4 (spi: spi-imx: add DMA support) Signed-off-by: Robin Gong Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6fe528da404537cece61038adffe85181159f22f Author: Bhuvanchandra DV Date: Tue Jan 27 16:27:20 2015 +0530 spi: spi-fsl-dspi: Remove usage of devm_kzalloc commit 973fbce69ed8e79b5fe3ad19cfecb581a7ef8048 upstream. devm_* API was supposed to be used only in probe function call. Memory is allocated at 'probe' and free automatically at 'remove'. Usage of devm_* functions outside probe sometimes leads to memory leak. Avoid using devm_kzalloc in dspi_setup_transfer and use kzalloc instead. Also add the dspi_cleanup function to free the controller data upon cleanup. Acked-by: Stefan Agner Signed-off-by: Bhuvanchandra DV Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 96c55843d510ee907cf3a690696049e6834dea77 Author: Myron Stowe Date: Tue Feb 3 16:01:24 2015 -0700 PCI: Handle read-only BARs on AMD CS553x devices commit 06cf35f903aa6da0cc8d9f81e9bcd1f7e1b534bb upstream. Some AMD CS553x devices have read-only BARs because of a firmware or hardware defect. There's a workaround in quirk_cs5536_vsa(), but it no longer works after 36e8164882ca ("PCI: Restore detection of read-only BARs"). Prior to 36e8164882ca, we filled in res->start; afterwards we leave it zeroed out. The quirk only updated the size, so the driver tried to use a region starting at zero, which didn't work. Expand quirk_cs5536_vsa() to read the base addresses from the BARs and hard-code the sizes. On Nix's system BAR 2's read-only value is 0x6200. Prior to 36e8164882ca, we interpret that as a 512-byte BAR based on the lowest-order bit set. Per datasheet sec 5.6.1, that BAR (MFGPT) requires only 64 bytes; use that to avoid clearing any address bits if a platform uses only 64-byte alignment. [bhelgaas: changelog, reduce BAR 2 size to 64] Fixes: 36e8164882ca ("PCI: Restore detection of read-only BARs") Link: https://bugzilla.kernel.org/show_bug.cgi?id=85991#c4 Link: http://support.amd.com/TechDocs/31506_cs5535_databook.pdf Link: http://support.amd.com/TechDocs/33238G_cs5536_db.pdf Reported-and-tested-by: Nix Signed-off-by: Myron Stowe Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 42dcb705660528b22f6e071e8fdec2e5b7336b3c Author: Charlotte Richardson Date: Mon Feb 2 09:36:23 2015 -0600 PCI: Add NEC variants to Stratus ftServer PCIe DMI check commit 51ac3d2f0c505ca36ffc9715ffd518d756589ef8 upstream. NEC OEMs the same platforms as Stratus does, which have multiple devices on some PCIe buses under downstream ports. Link: https://bugzilla.kernel.org/show_bug.cgi?id=51331 Fixes: 1278998f8ff6 ("PCI: Work around Stratus ftServer broken PCIe hierarchy (fix DMI check)") Signed-off-by: Charlotte Richardson Signed-off-by: Bjorn Helgaas CC: Myron Stowe Signed-off-by: Greg Kroah-Hartman commit 0df05be2d81ba21663c611c50515b9e54a1372b3 Author: Lucas Stach Date: Tue Jan 27 10:24:53 2015 -0600 PCI: designware: Reject MSI-X IRQs commit 19c5392eb1c1e81188e898400c0e8258827eb160 upstream. The DesignWare PCIe MSI hardware does not support MSI-X IRQs. Setting those up failed as a side effect of a bug which was fixed by 91f8ae823f2b ("PCI: designware: Setup and clear exactly one MSI at a time"). Now that this bug is fixed, MSI-X IRQs need to be rejected explicitly; otherwise devices trying to use them may end up with incorrectly working interrupts. Fixes: 91f8ae823f2b ("PCI: designware: Setup and clear exactly one MSI at a time") Signed-off-by: Lucas Stach Signed-off-by: Bjorn Helgaas Acked-by: Jingoo Han Signed-off-by: Greg Kroah-Hartman commit 9a42a8a458c76c4583fcb5f8eaa336fd8157be20 Author: Sonic Zhang Date: Tue Jan 20 17:00:08 2015 +0800 gpio: mcp23s08: handle default gpio base commit b184c388f773f30b6c707d3d4599b2db80f4390c upstream. Create default gpio base if neither device node nor platform data is defined. Signed-off-by: Sonic Zhang Reviewed-by: Alexandre Courbot Tested-by: Antonio Fiol Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 64f2260ea24f94ecca7d8619e9c6d250ef9ff465 Author: Johan Hovold Date: Mon Jan 26 12:02:46 2015 +0100 gpio: sysfs: fix memory leak in gpiod_sysfs_set_active_low commit 49d2ca84e433dab854c7a866bc6add09cfab682d upstream. Fix memory leak in the gpio sysfs interface due to failure to drop reference to device returned by class_find_device when setting the gpio-line polarity. Fixes: 0769746183ca ("gpiolib: add support for changing value polarity in sysfs") Signed-off-by: Johan Hovold Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 22f837c860eb7e1d237f5ba91101805df37be1d7 Author: Johan Hovold Date: Mon Jan 26 12:02:45 2015 +0100 gpio: sysfs: fix memory leak in gpiod_export_link commit 0f303db08df0df9bd0966443ad6001e63960af16 upstream. Fix memory leak in the gpio sysfs interface due to failure to drop reference to device returned by class_find_device when creating a link. Fixes: a4177ee7f1a8 ("gpiolib: allow exported GPIO nodes to be named using sysfs links") Signed-off-by: Johan Hovold Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman