commit a34f0e8a2f8976f0bae4962edf2af4dd16cb85f7 Author: Greg Kroah-Hartman Date: Thu Dec 15 08:49:34 2016 -0800 Linux 4.4.39 commit 5d488dee9236466a23220ad9a881cae7e45efe89 Author: David Michael Date: Tue Nov 29 11:15:12 2016 -0800 crypto: rsa - Add Makefile dependencies to fix parallel builds commit 57891633eeef60e732e045731cf20e50ee80acb4 upstream. Both asn1 headers are included by rsa_helper.c, so rsa_helper.o should explicitly depend on them. Signed-off-by: David Michael Signed-off-by: Herbert Xu Cc: Tuomas Tynkkynen Signed-off-by: Greg Kroah-Hartman commit 1c0f4e0ebb791cad8fee77d8de1ceb684e631698 Author: Michal Hocko Date: Wed Dec 7 14:54:38 2016 +0100 hotplug: Make register and unregister notifier API symmetric commit 777c6e0daebb3fcefbbd6f620410a946b07ef6d0 upstream. Yu Zhao has noticed that __unregister_cpu_notifier only unregisters its notifiers when HOTPLUG_CPU=y while the registration might succeed even when HOTPLUG_CPU=n if MODULE is enabled. This means that e.g. zswap might keep a stale notifier on the list on the manual clean up during the pool tear down and thus corrupt the list. Resulting in the following [ 144.964346] BUG: unable to handle kernel paging request at ffff880658a2be78 [ 144.971337] IP: [] raw_notifier_chain_register+0x1b/0x40 [ 145.122628] Call Trace: [ 145.125086] [] __register_cpu_notifier+0x18/0x20 [ 145.131350] [] zswap_pool_create+0x273/0x400 [ 145.137268] [] __zswap_param_set+0x1fc/0x300 [ 145.143188] [] ? trace_hardirqs_on+0xd/0x10 [ 145.149018] [] ? kernel_param_lock+0x28/0x30 [ 145.154940] [] ? __might_fault+0x4f/0xa0 [ 145.160511] [] zswap_compressor_param_set+0x17/0x20 [ 145.167035] [] param_attr_store+0x5c/0xb0 [ 145.172694] [] module_attr_store+0x1d/0x30 [ 145.178443] [] sysfs_kf_write+0x4f/0x70 [ 145.183925] [] kernfs_fop_write+0x149/0x180 [ 145.189761] [] __vfs_write+0x18/0x40 [ 145.194982] [] vfs_write+0xb2/0x1a0 [ 145.200122] [] SyS_write+0x52/0xa0 [ 145.205177] [] entry_SYSCALL_64_fastpath+0x12/0x17 This can be even triggered manually by changing /sys/module/zswap/parameters/compressor multiple times. Fix this issue by making unregister APIs symmetric to the register so there are no surprises. Fixes: 47e627bc8c9a ("[PATCH] hotplug: Allow modules to use the cpu hotplug notifiers even if !CONFIG_HOTPLUG_CPU") Reported-and-tested-by: Yu Zhao Signed-off-by: Michal Hocko Cc: linux-mm@kvack.org Cc: Andrew Morton Cc: Dan Streetman Link: http://lkml.kernel.org/r/20161207135438.4310-1-mhocko@kernel.org Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 537e42d759aeb833bfc6dbb3711bc45e5fddb308 Author: Sven Eckelmann Date: Wed Nov 30 21:47:09 2016 +0100 batman-adv: Check for alloc errors when preparing TT local data commit c2d0f48a13e53b4747704c9e692f5e765e52041a upstream. batadv_tt_prepare_tvlv_local_data can fail to allocate the memory for the new TVLV block. The caller is informed about this problem with the returned length of 0. Not checking this value results in an invalid memory access when either tt_data or tt_change is accessed. Reported-by: Dan Carpenter Fixes: 7ea7b4a14275 ("batman-adv: make the TT CRC logic VLAN specific") Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Greg Kroah-Hartman commit f03531d091255156cf8c865b969377f01750e97a Author: Boris Brezillon Date: Fri Oct 28 17:12:28 2016 +0200 m68k: Fix ndelay() macro commit 7e251bb21ae08ca2e4fb28cc0981fac2685a8efa upstream. The current ndelay() macro definition has an extra semi-colon at the end of the line thus leading to a compilation error when ndelay is used in a conditional block without curly braces like this one: if (cond) ndelay(t); else ... which, after the preprocessor pass gives: if (cond) m68k_ndelay(t);; else ... thus leading to the following gcc error: error: 'else' without a previous 'if' Remove this extra semi-colon. Signed-off-by: Boris Brezillon Fixes: c8ee038bd1488 ("m68k: Implement ndelay() based on the existing udelay() logic") Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman commit 55e15b2f44d7f7d9350b70890b0e39a8ee713504 Author: James Morse Date: Tue Feb 2 15:53:59 2016 +0000 arm64: futex.h: Add missing PAN toggling commit 811d61e384e24759372bb3f01772f3744b0a8327 upstream. futex.h's futex_atomic_cmpxchg_inatomic() does not use the __futex_atomic_op() macro and needs its own PAN toggling. This was missed when the feature was implemented. Fixes: 338d4f49d6f ("arm64: kernel: Add support for Privileged Access Never") Signed-off-by: James Morse Signed-off-by: Will Deacon Cc: Mian Yousaf Kaukab Signed-off-by: Greg Kroah-Hartman commit e29949ed3903930e38dead204b01e7912c98fe33 Author: 추지호 Date: Thu Dec 8 12:01:13 2016 +0000 can: peak: fix bad memory access and free sequence commit b67d0dd7d0dc9e456825447bbeb935d8ef43ea7c upstream. Fix for bad memory access while disconnecting. netdev is freed before private data free, and dev is accessed after freeing netdev. This makes a slub problem, and it raise kernel oops with slub debugger config. Signed-off-by: Jiho Chu Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 083021bdba1e6d480170a4ae86cddc10f88c54d5 Author: Marc Kleine-Budde Date: Mon Dec 5 11:44:23 2016 +0100 can: raw: raw_setsockopt: limit number of can_filter that can be set commit 332b05ca7a438f857c61a3c21a88489a21532364 upstream. This patch adds a check to limit the number of can_filters that can be set via setsockopt on CAN_RAW sockets. Otherwise allocations > MAX_ORDER are not prevented resulting in a warning. Reference: https://lkml.org/lkml/2016/12/2/230 Reported-by: Andrey Konovalov Tested-by: Andrey Konovalov Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 9a3baed9103bc413a5e98e13e31cd8ae7c0b5563 Author: tim Date: Mon Dec 5 11:46:31 2016 -0800 crypto: mcryptd - Check mcryptd algorithm compatibility commit 48a992727d82cb7db076fa15d372178743b1f4cd upstream. Algorithms not compatible with mcryptd could be spawned by mcryptd with a direct crypto_alloc_tfm invocation using a "mcryptd(alg)" name construct. This causes mcryptd to crash the kernel if an arbitrary "alg" is incompatible and not intended to be used with mcryptd. It is an issue if AF_ALG tries to spawn mcryptd(alg) to expose it externally. But such algorithms must be used internally and not be exposed. We added a check to enforce that only internal algorithms are allowed with mcryptd at the time mcryptd is spawning an algorithm. Link: http://marc.info/?l=linux-crypto-vger&m=148063683310477&w=2 Reported-by: Mikulas Patocka Signed-off-by: Tim Chen Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit c4db8a7d1e0c16287642414fe16d85d1eaeb8923 Author: Peter Zijlstra (Intel) Date: Tue Nov 29 20:33:28 2016 +0000 perf/x86: Fix full width counter, counter overflow commit 7f612a7f0bc13a2361a152862435b7941156b6af upstream. Lukasz reported that perf stat counters overflow handling is broken on KNL/SLM. Both these parts have full_width_write set, and that does indeed have a problem. In order to deal with counter wrap, we must sample the counter at at least half the counter period (see also the sampling theorem) such that we can unambiguously reconstruct the count. However commit: 069e0c3c4058 ("perf/x86/intel: Support full width counting") sets the sampling interval to the full period, not half. Fixing that exposes another issue, in that we must not sign extend the delta value when we shift it right; the counter cannot have decremented after all. With both these issues fixed, counter overflow functions correctly again. Reported-by: Lukasz Odzioba Tested-by: Liang, Kan Tested-by: Odzioba, Lukasz Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Fixes: 069e0c3c4058 ("perf/x86/intel: Support full width counting") Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit c6a5bf4cda12e4a3c097036ce7044ee65e4cf6d9 Author: Thomas Gleixner Date: Wed Nov 30 21:04:42 2016 +0000 locking/rtmutex: Use READ_ONCE() in rt_mutex_owner() commit 1be5d4fa0af34fb7bafa205aeb59f5c7cc7a089d upstream. While debugging the rtmutex unlock vs. dequeue race Will suggested to use READ_ONCE() in rt_mutex_owner() as it might race against the cmpxchg_release() in unlock_rt_mutex_safe(). Will: "It's a minor thing which will most likely not matter in practice" Careful search did not unearth an actual problem in todays code, but it's better to be safe than surprised. Suggested-by: Will Deacon Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Cc: David Daney Cc: Linus Torvalds Cc: Mark Rutland Cc: Peter Zijlstra Cc: Sebastian Siewior Cc: Steven Rostedt Link: http://lkml.kernel.org/r/20161130210030.431379999@linutronix.de Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit b27d9147f24a501d632916964f77c1221246fae9 Author: Thomas Gleixner Date: Wed Nov 30 21:04:41 2016 +0000 locking/rtmutex: Prevent dequeue vs. unlock race commit dbb26055defd03d59f678cb5f2c992abe05b064a upstream. David reported a futex/rtmutex state corruption. It's caused by the following problem: CPU0 CPU1 CPU2 l->owner=T1 rt_mutex_lock(l) lock(l->wait_lock) l->owner = T1 | HAS_WAITERS; enqueue(T2) boost() unlock(l->wait_lock) schedule() rt_mutex_lock(l) lock(l->wait_lock) l->owner = T1 | HAS_WAITERS; enqueue(T3) boost() unlock(l->wait_lock) schedule() signal(->T2) signal(->T3) lock(l->wait_lock) dequeue(T2) deboost() unlock(l->wait_lock) lock(l->wait_lock) dequeue(T3) ===> wait list is now empty deboost() unlock(l->wait_lock) lock(l->wait_lock) fixup_rt_mutex_waiters() if (wait_list_empty(l)) { owner = l->owner & ~HAS_WAITERS; l->owner = owner ==> l->owner = T1 } lock(l->wait_lock) rt_mutex_unlock(l) fixup_rt_mutex_waiters() if (wait_list_empty(l)) { owner = l->owner & ~HAS_WAITERS; cmpxchg(l->owner, T1, NULL) ===> Success (l->owner = NULL) l->owner = owner ==> l->owner = T1 } That means the problem is caused by fixup_rt_mutex_waiters() which does the RMW to clear the waiters bit unconditionally when there are no waiters in the rtmutexes rbtree. This can be fatal: A concurrent unlock can release the rtmutex in the fastpath because the waiters bit is not set. If the cmpxchg() gets in the middle of the RMW operation then the previous owner, which just unlocked the rtmutex is set as the owner again when the write takes place after the successfull cmpxchg(). The solution is rather trivial: verify that the owner member of the rtmutex has the waiters bit set before clearing it. This does not require a cmpxchg() or other atomic operations because the waiters bit can only be set and cleared with the rtmutex wait_lock held. It's also safe against the fast path unlock attempt. The unlock attempt via cmpxchg() will either see the bit set and take the slowpath or see the bit cleared and release it atomically in the fastpath. It's remarkable that the test program provided by David triggers on ARM64 and MIPS64 really quick, but it refuses to reproduce on x86-64, while the problem exists there as well. That refusal might explain that this got not discovered earlier despite the bug existing from day one of the rtmutex implementation more than 10 years ago. Thanks to David for meticulously instrumenting the code and providing the information which allowed to decode this subtle problem. Reported-by: David Daney Tested-by: David Daney Signed-off-by: Thomas Gleixner Reviewed-by: Steven Rostedt Acked-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Mark Rutland Cc: Peter Zijlstra Cc: Sebastian Siewior Cc: Will Deacon Fixes: 23f78d4a03c5 ("[PATCH] pi-futex: rt mutex core") Link: http://lkml.kernel.org/r/20161130210030.351136722@linutronix.de Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit e286b6c16758adc77e960dd679073200b539803a Author: Sergey Senozhatsky Date: Wed Dec 7 14:44:31 2016 -0800 zram: restrict add/remove attributes to root only commit 5c7e9ccd91b90d87029261f8856294ee51934cab upstream. zram hot_add sysfs attribute is a very 'special' attribute - reading from it creates a new uninitialized zram device. This file, by a mistake, can be read by a 'normal' user at the moment, while only root must be able to create a new zram device, therefore hot_add attribute must have S_IRUSR mode, not S_IRUGO. [akpm@linux-foundation.org: s/sence/sense/, reflow comment to use 80 cols] Fixes: 6566d1a32bf72 ("zram: add dynamic device add/remove functionality") Link: http://lkml.kernel.org/r/20161205155845.20129-1-sergey.senozhatsky@gmail.com Signed-off-by: Sergey Senozhatsky Reported-by: Steven Allen Acked-by: Greg Kroah-Hartman Cc: Minchan Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a0bd6aa097a4c9cf920b66686515bcb174bed531 Author: Helge Deller Date: Thu Dec 8 21:00:46 2016 +0100 parisc: Fix TLB related boot crash on SMP machines commit 24d0492b7d5d321a9c5846c8c974eba9823ffaa0 upstream. At bootup we run measurements to calculate the best threshold for when we should be using full TLB flushes instead of just flushing a specific amount of TLB entries. This performance test is run over the kernel text segment. But running this TLB performance test on the kernel text segment turned out to crash some SMP machines when the kernel text pages were mapped as huge pages. To avoid those crashes this patch simply skips this test on some SMP machines and calculates an optimal threshold based on the maximum number of available TLB entries and number of online CPUs. On a technical side, this seems to happen: The TLB measurement code uses flush_tlb_kernel_range() to flush specific TLB entries with a page size of 4k (pdtlb 0(sr1,addr)). On UP systems this purge instruction seems to work without problems even if the pages were mapped as huge pages. But on SMP systems the TLB purge instruction is broadcasted to other CPUs. Those CPUs then crash the machine because the page size is not as expected. C8000 machines with PA8800/PA8900 CPUs were not affected by this problem, because the required cache coherency prohibits to use huge pages at all. Sadly I didn't found any documentation about this behaviour, so this finding is purely based on testing with phyiscal SMP machines (A500-44 and J5000, both were 2-way boxes). Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 605f315c5a8340e61fbe627907701377d27b7510 Author: John David Anglin Date: Tue Dec 6 22:02:01 2016 -0500 parisc: Remove unnecessary TLB purges from flush_dcache_page_asm and flush_icache_page_asm commit febe42964fe182281859b3d43d844bb25ca49367 upstream. We have four routines in pacache.S that use temporary alias pages: copy_user_page_asm(), clear_user_page_asm(), flush_dcache_page_asm() and flush_icache_page_asm(). copy_user_page_asm() and clear_user_page_asm() don't purge the TLB entry used for the operation. flush_dcache_page_asm() and flush_icache_page_asm do purge the entry. Presumably, this was thought to optimize TLB use. However, the operation is quite heavy weight on PA 1.X processors as we need to take the TLB lock and a TLB broadcast is sent to all processors. This patch removes the purges from flush_dcache_page_asm() and flush_icache_page_asm. Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit db95986057686ecd7d615ede326d63e8b24a5e92 Author: John David Anglin Date: Tue Dec 6 21:47:04 2016 -0500 parisc: Purge TLB before setting PTE commit c78e710c1c9fbeff43dddc0aa3d0ff458e70b0cc upstream. The attached change interchanges the order of purging the TLB and setting the corresponding page table entry. TLB purges are strongly ordered. It occurred to me one night that setting the PTE first might have subtle ordering issues on SMP machines and cause random memory corruption. A TLB lock guards the insertion of user TLB entries. So after the TLB is purged, a new entry can't be inserted until the lock is released. This ensures that the new PTE value is used when the lock is released. Since making this change, no random segmentation faults have been observed on the Debian hppa buildd servers. Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 4bcea472de100311614c442f7236d0bcc4a413b3 Author: Andrew Donnellan Date: Thu Dec 1 11:23:05 2016 +1100 powerpc/eeh: Fix deadlock when PE frozen state can't be cleared commit 409bf7f8a02ef88db5a0f2cdcf9489914f4b8508 upstream. In eeh_reset_device(), we take the pci_rescan_remove_lock immediately after after we call eeh_reset_pe() to reset the PCI controller. We then call eeh_clear_pe_frozen_state(), which can return an error. In this case, we bail out of eeh_reset_device() without calling pci_unlock_rescan_remove(). Add a call to pci_unlock_rescan_remove() in the eeh_clear_pe_frozen_state() error path so that we don't cause a deadlock later on. Reported-by: Pradipta Ghosh Fixes: 78954700631f ("powerpc/eeh: Avoid I/O access during PE reset") Signed-off-by: Andrew Donnellan Acked-by: Russell Currey Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman