commit f849d45b3247ff5fdb5bee25e120559ea5970d2d Author: Greg Kroah-Hartman Date: Fri Sep 30 10:13:55 2016 +0200 Linux 4.7.6 commit dacc0987fd2e25a8b4b8c19778862ba12ce76d0a Author: Wilfried Klaebe Date: Tue Jun 28 12:21:33 2016 +0000 builddeb: really include objtool binary in headers package commit 15f6d337159b2a9fdad8c0bef50ec826593ed5d2 upstream. On May 4th, Bjørn Mork provided patch 697bbc7b8320 ("builddeb: include objtool binary in headers package"). However, that one only works if $srctree=$objtree, because the objtool binaries are not written to the srctree, but to the objtree. Signed-off-by: Wilfried Klaebe Fixes: 697bbc7b8320 ("builddeb: include objtool binary in headers package") Signed-off-by: Michal Marek Signed-off-by: Greg Kroah-Hartman commit c270b18bea75269388a7089b080840884c9d5d5c Author: Steve Wise Date: Fri Jul 29 08:38:44 2016 -0700 iw_cxgb4: stop MPA_REPLY timer when disconnecting commit 12eb5137edecfd8fb6d23dacec2a3630e729736f upstream. There exists a race where the application can setup a connection and then disconnect it before iw_cxgb4 processes the fw4_ack message. For passive side connections, the fw4_ack message is used to know when to stop the ep timer for MPA_REPLY messages. If the application disconnects before the fw4_ack is handled then c4iw_ep_disconnect() needs to clean up the timer state and stop the timer before restarting it for the disconnect timer. Failure to do this results in a "timer already started" message and a premature stopping of the disconnect timer. Fixes: e4b76a2 ("RDMA/iw_cxgb4: stop_ep_timer() after MPA negotiation") Signed-off-by: Steve Wise Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit beaedc9689a0bb6940373624fcca36546aa66aa8 Author: Andrey Ryabinin Date: Tue Aug 2 14:02:43 2016 -0700 mm/kasan: don't reduce quarantine in atomic contexts commit 4b3ec5a3f4b1d5c9d64b9ab704042400d050d432 upstream. Currently we call quarantine_reduce() for ___GFP_KSWAPD_RECLAIM (implied by __GFP_RECLAIM) allocation. So, basically we call it on almost every allocation. quarantine_reduce() sometimes is heavy operation, and calling it with disabled interrupts may trigger hard LOCKUP: NMI watchdog: Watchdog detected hard LOCKUP on cpu 2irq event stamp: 1411258 Call Trace: dump_stack+0x68/0x96 watchdog_overflow_callback+0x15b/0x190 __perf_event_overflow+0x1b1/0x540 perf_event_overflow+0x14/0x20 intel_pmu_handle_irq+0x36a/0xad0 perf_event_nmi_handler+0x2c/0x50 nmi_handle+0x128/0x480 default_do_nmi+0xb2/0x210 do_nmi+0x1aa/0x220 end_repeat_nmi+0x1a/0x1e <> __kernel_text_address+0x86/0xb0 print_context_stack+0x7b/0x100 dump_trace+0x12b/0x350 save_stack_trace+0x2b/0x50 set_track+0x83/0x140 free_debug_processing+0x1aa/0x420 __slab_free+0x1d6/0x2e0 ___cache_free+0xb6/0xd0 qlist_free_all+0x83/0x100 quarantine_reduce+0x177/0x1b0 kasan_kmalloc+0xf3/0x100 Reduce the quarantine_reduce iff direct reclaim is allowed. Fixes: 55834c59098d("mm: kasan: initial memory quarantine implementation") Link: http://lkml.kernel.org/r/1470062715-14077-2-git-send-email-aryabinin@virtuozzo.com Signed-off-by: Andrey Ryabinin Reported-by: Dave Jones Acked-by: Alexander Potapenko Cc: Dmitry Vyukov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit cf48c9242444b9d542e2fe7e6ca01b8da00a1bc3 Author: Alexander Potapenko Date: Tue Aug 2 14:02:58 2016 -0700 kasan: avoid overflowing quarantine size on low memory systems commit c3cee372282cb6bcdf19ac1457581d5dd5ecb554 upstream. If the total amount of memory assigned to quarantine is less than the amount of memory assigned to per-cpu quarantines, |new_quarantine_size| may overflow. Instead, set it to zero. [akpm@linux-foundation.org: cleanup: use WARN_ONCE return value] Link: http://lkml.kernel.org/r/1470063563-96266-1-git-send-email-glider@google.com Fixes: 55834c59098d ("mm: kasan: initial memory quarantine implementation") Signed-off-by: Alexander Potapenko Reported-by: Dmitry Vyukov Cc: Andrey Ryabinin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6eeab2dc304a732722f77061ae364d102732943d Author: Dan Carpenter Date: Wed Jul 13 13:12:34 2016 +0300 hostfs: Freeing an ERR_PTR in hostfs_fill_sb_common() commit 8a545f185145e3c09348cd74326268ecfc6715a3 upstream. We can't pass error pointers to kfree() or it causes an oops. Fixes: 52b209f7b848 ('get rid of hostfs_read_inode()') Signed-off-by: Dan Carpenter Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit cb106d2a2c6b3d1d2459c0807b0d944983cbcc05 Author: Dan Carpenter Date: Mon Jul 11 11:46:33 2016 +0300 qxl: check for kmap failures commit f4cceb2affcd1285d4ce498089e8a79f4cd2fa66 upstream. If kmap fails, it leads to memory corruption. Fixes: f64122c1f6ad ('drm: add new QXL driver. (v1.4)') Signed-off-by: Dan Carpenter Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20160711084633.GA31411@mwanda Signed-off-by: Greg Kroah-Hartman commit 3010fb28c8345a9c9d1b807e5d1b62c496d414ad Author: Jon Hunter Date: Tue Jun 28 11:38:28 2016 +0100 soc/tegra: pmc: Don't probe PMC if early initialisation fails commit a83f1fc3f33930d01e579b9d4de92a045297b402 upstream. Commit 0259f522e04f ('soc/tegra: pmc: Restore base address on probe failure') fixes an issue where the PMC base address pointer is not restored on probe failure. However, this fix creates another problem where if early initialisation of the PMC driver fails and an initial mapping for the PMC address space is not created, then when the PMC device is probed, the PMC base address pointer will not be valid and this will cause a crash when tegra_pmc_init() is called and attempts to access a register. Although the PMC address space is mapped a 2nd time during the probe and so this could be fixed by populating the base address pointer earlier during the probe, this adds more complexity to the code. Moreover, the PMC probe also assumes the the soc data pointer is also initialised when the device is probed and if not will also lead to a crash when calling tegra_pmc_init_tsense_reset(). Given that if the early initialisation does fail then something bad has happen, it seems acceptable to allow the PMC device probe to fail as well. Therefore, if the PMC base address pointer or soc data pointer are not valid when probing the PMC device, WARN and return an error. Fixes: 0259f522e04f ('soc/tegra: pmc: Restore base address on probe failure') Signed-off-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 3350bf2d7f3aad711a2ae3b29e8cfff26143246c Author: Kshitiz Gupta Date: Sat Jul 16 02:23:45 2016 -0500 igb: fix adjusting PTP timestamps for Tx/Rx latency commit 0066c8b6f4050d7c57f6379d6fd4535e2f267f17 upstream. Fix PHY delay compensation math in igb_ptp_tx_hwtstamp() and igb_ptp_rx_rgtstamp. Add PHY delay compensation in igb_ptp_rx_pktstamp(). In the IGB driver, there are two functions that retrieve timestamps received by the PHY - igb_ptp_rx_rgtstamp() and igb_ptp_rx_pktstamp(). The previous commit only changed igb_ptp_rx_rgtstamp(), and the change was incorrect. There are two instances in which PHY delay compensations should be made: - Before the packet transmission over the PHY, the latency between when the packet is timestamped and transmission of the packets, should be an add operation, but it is currently a subtract. - After the packets are received from the PHY, the latency between the receiving and timestamping of the packets should be a subtract operation, but it is currently an add. Signed-off-by: Kshitiz Gupta Fixes: 3f544d2 (igb: adjust ptp timestamps for tx/rx latency) Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit 03c35e10e68d3dafd2a8189a37b20c21695d1e74 Author: Alexander Duyck Date: Fri Aug 12 09:53:39 2016 -0700 ixgbe: Re-enable ability to toggle VLAN filtering commit 3d951822be216d8c6fcfc8abf75e5ed307eeb646 upstream. Back when I submitted the GSO code I messed up and dropped the support for disabling the VLAN tag filtering via the feature bit. This patch re-enables the use of the NETIF_F_HW_VLAN_CTAG_FILTER to enable/disable the VLAN filtering independent of toggling promiscuous mode. Fixes: b83e30104b ("ixgbe/ixgbevf: Add support for GSO partial") Signed-off-by: Alexander Duyck Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit b4cc7dd0636a4bdf2987474dd7063044c262faab Author: Alexander Duyck Date: Thu Aug 11 14:51:56 2016 -0700 ixgbe: Force VLNCTRL.VFE to be set in all VMDq paths commit f60439bc21e3337429838e477903214f5bd8277f upstream. When I was adding the code for enabling VLAN promiscuous mode with SR-IOV enabled I had inadvertently left the VLNCTRL.VFE bit unchanged as I has assumed there was code in another path that was setting it when we enabled SR-IOV. This wasn't the case and as a result we were just disabling VLAN filtering for all the VFs apparently. Also the previous patches were always clearing CFIEN which was always set to 0 by the hardware anyway so I am dropping the redundant bit clearing. Fixes: 16369564915a ("ixgbe: Add support for VLAN promiscuous with SR-IOV") Signed-off-by: Alexander Duyck Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit 1a659cc00489659a654dffb66ff9b76b3b9f102d Author: Sven Van Asbroeck Date: Fri Aug 12 09:10:27 2016 -0400 power: supply: max17042_battery: fix model download bug. commit 5381cfb6f0422da24cfa9da35b0433c0415830e0 upstream. The device's model download function returns the model data as an array of u32s, which is later compared to the reference model data. However, since the latter is an array of u16s, the comparison does not happen correctly, and model verification fails. This in turn breaks the POR initialization sequence. Fixes: 39e7213edc4f3 ("max17042_battery: Support regmap to access device's registers") Reported-by: Dan Carpenter Signed-off-by: Sven Van Asbroeck Reviewed-by: Krzysztof Kozlowski Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit ed3bab5299d8f82cfae121e8cda2a3a7083f396b Author: Wei Yongjun Date: Tue Jul 26 14:49:04 2016 +0000 power_supply: tps65217-charger: fix missing platform_set_drvdata() commit 33e7664a0af6e9a516f01014f39737aaa119b6d9 upstream. Add missing platform_set_drvdata() in tps65217_charger_probe(), otherwise calling platform_get_drvdata() in remove returns NULL. This is detected by Coccinelle semantic patch. Fixes: 3636859b280c ("power_supply: Add support for tps65217-charger") Signed-off-by: Wei Yongjun Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 630acdbb7bbccb9b9e20178909d1dc285739ef0b Author: James Morse Date: Tue Aug 16 10:46:38 2016 +0100 PM / hibernate: Fix rtree_next_node() to avoid walking off list ends commit 924d8696751c4b9e58263bc82efdafcf875596a6 upstream. rtree_next_node() walks the linked list of leaf nodes to find the next block of pages in the struct memory_bitmap. If it walks off the end of the list of nodes, it walks the list of memory zones to find the next region of memory. If it walks off the end of the list of zones, it returns false. This leaves the struct bm_position's node and zone pointers pointing at their respective struct list_heads in struct mem_zone_bm_rtree. memory_bm_find_bit() uses struct bm_position's node and zone pointers to avoid walking lists and trees if the next bit appears in the same node/zone. It handles these values being stale. Swap rtree_next_node()s 'step then test' to 'test-next then step', this means if we reach the end of memory we return false and leave the node and zone pointers as they were. This fixes a panic on resume using AMD Seattle with 64K pages: [ 6.868732] Freezing user space processes ... (elapsed 0.000 seconds) done. [ 6.875753] Double checking all user space processes after OOM killer disable... (elapsed 0.000 seconds) [ 6.896453] PM: Using 3 thread(s) for decompression. [ 6.896453] PM: Loading and decompressing image data (5339 pages)... [ 7.318890] PM: Image loading progress: 0% [ 7.323395] Unable to handle kernel paging request at virtual address 00800040 [ 7.330611] pgd = ffff000008df0000 [ 7.334003] [00800040] *pgd=00000083fffe0003, *pud=00000083fffe0003, *pmd=00000083fffd0003, *pte=0000000000000000 [ 7.344266] Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 7.349825] Modules linked in: [ 7.352871] CPU: 2 PID: 1 Comm: swapper/0 Tainted: G W I 4.8.0-rc1 #4737 [ 7.360512] Hardware name: AMD Overdrive/Supercharger/Default string, BIOS ROD1002C 04/08/2016 [ 7.369109] task: ffff8003c0220000 task.stack: ffff8003c0280000 [ 7.375020] PC is at set_bit+0x18/0x30 [ 7.378758] LR is at memory_bm_set_bit+0x24/0x30 [ 7.383362] pc : [] lr : [] pstate: 60000045 [ 7.390743] sp : ffff8003c0283b00 [ 7.473551] [ 7.475031] Process swapper/0 (pid: 1, stack limit = 0xffff8003c0280020) [ 7.481718] Stack: (0xffff8003c0283b00 to 0xffff8003c0284000) [ 7.800075] Call trace: [ 7.887097] [] set_bit+0x18/0x30 [ 7.891876] [] duplicate_memory_bitmap.constprop.38+0x54/0x70 [ 7.899172] [] snapshot_write_next+0x22c/0x47c [ 7.905166] [] load_image_lzo+0x754/0xa88 [ 7.910725] [] swsusp_read+0x144/0x230 [ 7.916025] [] load_image_and_restore+0x58/0x90 [ 7.922105] [] software_resume+0x2f0/0x338 [ 7.927752] [] do_one_initcall+0x38/0x11c [ 7.933314] [] kernel_init_freeable+0x14c/0x1ec [ 7.939395] [] kernel_init+0x10/0xfc [ 7.944520] [] ret_from_fork+0x10/0x40 [ 7.949820] Code: d2800022 8b400c21 f9800031 9ac32043 (c85f7c22) [ 7.955909] ---[ end trace 0024a5986e6ff323 ]--- [ 7.960529] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Here struct mem_zone_bm_rtree's start_pfn has been returned instead of struct rtree_node's addr as the node/zone pointers are corrupt after we walked off the end of the lists during mark_unsafe_pages(). This behaviour was exposed by commit 6dbecfd345a6 ("PM / hibernate: Simplify mark_unsafe_pages()"), which caused mark_unsafe_pages() to call duplicate_memory_bitmap(), which uses memory_bm_find_bit() after walking off the end of the memory bitmap. Fixes: 3a20cb177961 (PM / Hibernate: Implement position keeping in radix tree) Signed-off-by: James Morse [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit b4707a7852aac91f89e44c049b459019ebb19f0e Author: Thomas Garnier Date: Thu Aug 11 14:49:29 2016 -0700 PM / hibernate: Restore processor state before using per-CPU variables commit 62822e2ec4ad091ba31f823f577ef80db52e3c2c upstream. Restore the processor state before calling any other functions to ensure per-CPU variables can be used with KASLR memory randomization. Tracing functions use per-CPU variables (GS based on x86) and one was called just before restoring the processor state fully. It resulted in a double fault when both the tracing & the exception handler functions tried to use a per-CPU variable. Fixes: bb3632c6101b (PM / sleep: trace events for suspend/resume) Reported-and-tested-by: Borislav Petkov Reported-by: Jiri Kosina Tested-by: Rafael J. Wysocki Tested-by: Jiri Kosina Signed-off-by: Thomas Garnier Acked-by: Pavel Machek Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit dab6c838065cac24e68ea0ae00970aa753d7b647 Author: Wei Yongjun Date: Sat Jul 30 00:37:57 2016 +0000 libceph: fix return value check in alloc_msg_with_page_vector() commit c22e853a2ed19321d00c1eae339ffdc4f5e7757e upstream. In case of error, the function ceph_alloc_page_vector() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Fixes: 1907920324f1 ('libceph: support for sending notifies') Signed-off-by: Wei Yongjun Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 0c157dba85e8b5713bbf23192b7640d8f30066b4 Author: Phil Turnbull Date: Thu Jul 21 13:43:09 2016 -0400 ceph: Correctly return NXIO errors from ceph_llseek commit 955818cd5b6c4b58ea574ace4573e7afa4c19c1e upstream. ceph_llseek does not correctly return NXIO errors because the 'out' path always returns 'offset'. Fixes: 06222e491e66 ("fs: handle SEEK_HOLE/SEEK_DATA properly in all fs's that define their own llseek") Signed-off-by: Phil Turnbull Signed-off-by: Yan, Zheng Signed-off-by: Greg Kroah-Hartman commit 6a8195b9028df045bef62f12837a600f500314fb Author: Arnd Bergmann Date: Mon Jun 13 15:04:56 2016 +0200 ceph: fix symbol versioning for ceph_monc_do_statfs commit a0f2b65275413b3438e9f55b1427273cd893c3b2 upstream. The genksyms helper in the kernel cannot parse a type definition like "typeof(((type *)0)->keyfld)" that is used in the DEFINE_RB_FUNCS helper, causing the following EXPORT_SYMBOL() statement to be ignored when computing the crcs, and triggering a warning about this: WARNING: "ceph_monc_do_statfs" [fs/ceph/ceph.ko] has no CRC To work around the problem, we can rewrite the type to reference an undefined 'extern' symbol instead of a NULL pointer. This is evidently ok for genksyms, and it no longer complains about the line when calling it with 'genksyms -w'. I've looked briefly into extending genksyms instead, but it seems really hard to do. Jan Beulich introduced basic support for 'typeof' a while ago in dc53324060f3 ("genksyms: fix typeof() handling"), but that is not sufficient for the expression we have here. Signed-off-by: Arnd Bergmann Fixes: fcd00b68bbe2 ("libceph: DEFINE_RB_FUNCS macro") Cc: Jan Beulich Cc: Michal Marek Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit dcb3f83230cdafb7d72cdf13676685351692b958 Author: Ilya Dryomov Date: Tue Jul 26 15:22:35 2016 +0200 libceph: add an ONSTACK initializer for oids commit 281dbe5db81c6137def9757e07a7aea14b1ed86e upstream. An on-stack oid in ceph_ioctl_get_dataloc() is not initialized, resulting in a WARN and a NULL pointer dereference later on. We will have more of these on-stack in the future, so fix it with a convenience macro. Fixes: d30291b985d1 ("libceph: variable-sized ceph_object_id") Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 453e10c44c128082d408894b1eab453735cf00ba Author: Matt Fleming Date: Tue Sep 20 14:26:21 2016 +0100 x86/mm/pat: Prevent hang during boot when mapping pages commit e535ec0899d1fe52ec3a84c9bc03457ac67ad6f7 upstream. There's a mixture of signed 32-bit and unsigned 32-bit and 64-bit data types used for keeping track of how many pages have been mapped. This leads to hangs during boot when mapping large numbers of pages (multiple terabytes, as reported by Waiman) because those values are interpreted as being negative. commit 742563777e8d ("x86/mm/pat: Avoid truncation when converting cpa->numpages to address") fixed one of those bugs, but there is another lurking in __change_page_attr_set_clr(). Additionally, the return value type for the populate_*() functions can return negative values when a large number of pages have been mapped, triggering the error paths even though no error occurred. Consistently use 64-bit types on 64-bit platforms when counting pages. Even in the signed case this gives us room for regions 8PiB (pebibytes) in size whilst still allowing the usual negative value error checking idiom. Reported-by: Waiman Long Cc: Ard Biesheuvel Cc: Borislav Petkov Cc: Linus Torvalds CC: Theodore Ts'o Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Scott J Norton Cc: Douglas Hatch Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit 16aef6c2f73d2b112733d2105cbc1129f25197e8 Author: Matt Redfearn Date: Mon Sep 5 15:43:40 2016 +0100 MIPS: paravirt: Fix undefined reference to smp_bootstrap commit 951c39cd3bc0aedf67fbd8fb4b9380287e6205d1 upstream. If the paravirt machine is compiles without CONFIG_SMP, the following linker error occurs arch/mips/kernel/head.o: In function `kernel_entry': (.ref.text+0x10): undefined reference to `smp_bootstrap' due to the kernel entry macro always including SMP startup code. Wrap this code in CONFIG_SMP to fix the error. Signed-off-by: Matt Redfearn Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14212/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 401285873b60897d47ecc968a79c0105f2556430 Author: Huacai Chen Date: Mon Sep 5 08:48:03 2016 +0800 MIPS: Add a missing ".set pop" in an early commit commit 3cbc6fc9c99f1709203711f125bc3b79487aba06 upstream. Commit 842dfc11ea9a21 ("MIPS: Fix build with binutils 2.24.51+") missing a ".set pop" in macro fpu_restore_16even, so add it. Signed-off-by: Huacai Chen Acked-by: Manuel Lauss Cc: Steven J . Hill Cc: Fuxin Zhang Cc: Zhangjin Wu Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14210/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 519e0ff1faf68487a390879a27f70340dc47b2b4 Author: Marcin Nowakowski Date: Wed Aug 31 12:33:23 2016 +0200 MIPS: Avoid a BUG warning during prctl(PR_SET_FP_MODE, ...) commit b244614a60ab7ce54c12a9cbe15cfbf8d79d0967 upstream. cpu_has_fpu macro uses smp_processor_id() and is currently executed with preemption enabled, that triggers the warning at runtime. It is assumed throughout the kernel that if any CPU has an FPU, then all CPUs would have an FPU as well, so it is safe to perform the check with preemption enabled - change the code to use raw_ variant of the check to avoid the warning. Signed-off-by: Marcin Nowakowski Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14125/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 1f13018d44740b14d1671d5623b6d5cadf79b5f2 Author: Paul Burton Date: Mon Sep 12 10:58:06 2016 +0100 MIPS: Remove compact branch policy Kconfig entries commit b03c1e3b8eed9026733c473071d1f528358a0e50 upstream. Commit c1a0e9bc885d ("MIPS: Allow compact branch policy to be changed") added Kconfig entries allowing for the compact branch policy used by the compiler for MIPSr6 kernels to be specified. This can be useful for debugging, particularly in systems where compact branches have recently been introduced. Unfortunately mainline gcc 5.x supports MIPSr6 but not the -mcompact-branches compiler flag, leading to MIPSr6 kernels failing to build with gcc 5.x with errors such as: mipsel-linux-gnu-gcc: error: unrecognized command line option '-mcompact-branches=optimal' make[2]: *** [kernel/bounds.s] Error 1 Fixing this by hiding the Kconfig entry behind another seems to be more hassle than it's worth, as MIPSr6 & compact branches have been around for a while now and if policy does need to be set for debug it can be done easily enough with KCFLAGS. Therefore remove the compact branch policy Kconfig entries & their handling in the Makefile. This reverts commit c1a0e9bc885d ("MIPS: Allow compact branch policy to be changed"). Signed-off-by: Paul Burton Reported-by: kbuild test robot Fixes: c1a0e9bc885d ("MIPS: Allow compact branch policy to be changed") Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14241/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 66f93fb33239b69092e9345d8eb1b48ba6a4b931 Author: James Hogan Date: Wed Sep 7 13:37:01 2016 +0100 MIPS: vDSO: Fix Malta EVA mapping to vDSO page structs commit 554af0c396380baf416f54c439b99b495180b2f4 upstream. The page structures associated with the vDSO pages in the kernel image are calculated using virt_to_page(), which uses __pa() under the hood to find the pfn associated with the virtual address. The vDSO data pointers however point to kernel symbols, so __pa_symbol() should really be used instead. Since there is no equivalent to virt_to_page() which uses __pa_symbol(), fix init_vdso_image() to work directly with pfns, calculated with __phys_to_pfn(__pa_symbol(...)). This issue broke the Malta Enhanced Virtual Addressing (EVA) configuration which has a non-default implementation of __pa_symbol(). This is because it uses a physical alias so that the kernel executes from KSeg0 (VA 0x80000000 -> PA 0x00000000), while RAM is provided to the kernel in the KUSeg range (VA 0x00000000 -> PA 0x80000000) which uses the same underlying RAM. Since there are no page structures associated with the low physical address region, some arbitrary kernel memory would be interpreted as a page structure for the vDSO pages and badness ensues. Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO") Signed-off-by: James Hogan Cc: Leonid Yegoshin Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14229/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 9ed2d4aceca21fe96bec0750480af3dd955ac3da Author: Matt Redfearn Date: Thu Sep 22 17:15:47 2016 +0100 MIPS: SMP: Fix possibility of deadlock when bringing CPUs online commit 8f46cca1e6c06a058374816887059bcc017b382f upstream. This patch fixes the possibility of a deadlock when bringing up secondary CPUs. The deadlock occurs because the set_cpu_online() is called before synchronise_count_slave(). This can cause a deadlock if the boot CPU, having scheduled another thread, attempts to send an IPI to the secondary CPU, which it sees has been marked online. The secondary is blocked in synchronise_count_slave() waiting for the boot CPU to enter synchronise_count_master(), but the boot cpu is blocked in smp_call_function_many() waiting for the secondary to respond to it's IPI request. Fix this by marking the CPU online in cpu_callin_map and synchronising counters before declaring the CPU online and calculating the maps for IPIs. Signed-off-by: Matt Redfearn Reported-by: Justin Chen Tested-by: Justin Chen Cc: Florian Fainelli Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14302/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 24a465cc0fac6ecccc018dd24c7a13424f8d11cc Author: Paul Burton Date: Fri Sep 23 15:13:53 2016 +0100 MIPS: Fix pre-r6 emulation FPU initialisation commit 7e956304eb8a285304a78582e4537e72c6365f20 upstream. In the mipsr2_decoder() function, used to emulate pre-MIPSr6 instructions that were removed in MIPSr6, the init_fpu() function is called if a removed pre-MIPSr6 floating point instruction is the first floating point instruction used by the task. However, init_fpu() performs varous actions that rely upon not being migrated. For example in the most basic case it sets the coprocessor 0 Status.CU1 bit to enable the FPU & then loads FP register context into the FPU registers. If the task were to migrate during this time, it may end up attempting to load FP register context on a different CPU where it hasn't set the CU1 bit, leading to errors such as: do_cpu invoked from kernel context![#2]: CPU: 2 PID: 7338 Comm: fp-prctl Tainted: G D 4.7.0-00424-g49b0c82 #2 task: 838e4000 ti: 88d38000 task.ti: 88d38000 $ 0 : 00000000 00000001 ffffffff 88d3fef8 $ 4 : 838e4000 88d38004 00000000 00000001 $ 8 : 3400fc01 801f8020 808e9100 24000000 $12 : dbffffff 807b69d8 807b0000 00000000 $16 : 00000000 80786150 00400fc4 809c0398 $20 : 809c0338 0040273c 88d3ff28 808e9d30 $24 : 808e9d30 00400fb4 $28 : 88d38000 88d3fe88 00000000 8011a2ac Hi : 0040273c Lo : 88d3ff28 epc : 80114178 _restore_fp+0x10/0xa0 ra : 8011a2ac mipsr2_decoder+0xd5c/0x1660 Status: 1400fc03 KERNEL EXL IE Cause : 1080002c (ExcCode 0b) PrId : 0001a920 (MIPS I6400) Modules linked in: Process fp-prctl (pid: 7338, threadinfo=88d38000, task=838e4000, tls=766527d0) Stack : 00000000 00000000 00000000 88d3fe98 00000000 00000000 809c0398 809c0338 808e9100 00000000 88d3ff28 00400fc4 00400fc4 0040273c 7fb69e18 004a0000 004a0000 004a0000 7664add0 8010de18 00000000 00000000 88d3fef8 88d3ff28 808e9100 00000000 766527d0 8010e534 000c0000 85755000 8181d580 00000000 00000000 00000000 004a0000 00000000 766527d0 7fb69e18 004a0000 80105c20 ... Call Trace: [<80114178>] _restore_fp+0x10/0xa0 [<8011a2ac>] mipsr2_decoder+0xd5c/0x1660 [<8010de18>] do_ri+0x90/0x6b8 [<80105c20>] ret_from_exception+0x0/0x10 Fix this by disabling preemption around the call to init_fpu(), ensuring that it starts & completes on one CPU. Signed-off-by: Paul Burton Fixes: b0a668fb2038 ("MIPS: kernel: mips-r2-to-r6-emul: Add R2 emulator for MIPS R6") Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14305/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 4b37b0ca71844614ada140b88dcee7fc2e8d1680 Author: Sudeep Holla Date: Thu Aug 25 12:23:39 2016 +0100 i2c: qup: skip qup_i2c_suspend if the device is already runtime suspended commit 331dcf421c34d227784d07943eb01e4023a42b0a upstream. If the i2c device is already runtime suspended, if qup_i2c_suspend is executed during suspend-to-idle or suspend-to-ram it will result in the following splat: WARNING: CPU: 3 PID: 1593 at drivers/clk/clk.c:476 clk_core_unprepare+0x80/0x90 Modules linked in: CPU: 3 PID: 1593 Comm: bash Tainted: G W 4.8.0-rc3 #14 Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) PC is at clk_core_unprepare+0x80/0x90 LR is at clk_unprepare+0x28/0x40 pc : [] lr : [] pstate: 60000145 Call trace: clk_core_unprepare+0x80/0x90 qup_i2c_disable_clocks+0x2c/0x68 qup_i2c_suspend+0x10/0x20 platform_pm_suspend+0x24/0x68 ... This patch fixes the issue by executing qup_i2c_pm_suspend_runtime conditionally in qup_i2c_suspend. Signed-off-by: Sudeep Holla Reviewed-by: Andy Gross Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 9bdb254d4d7a829a36047780e308e287cea70abb Author: Peter Rosin Date: Wed Sep 14 15:24:12 2016 +0200 i2c: mux: pca954x: retry updating the mux selection on failure commit 463e8f845cbf1c01e4cc8aeef1703212991d8e1e upstream. The cached value of the last selected channel prevents retries on the next call, even on failure to update the selected channel. Fix that. Signed-off-by: Peter Rosin Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 90cc7b41b7943e882c0c65386f8a8c1790f07b03 Author: Yadi.hu Date: Sun Sep 18 18:52:31 2016 +0800 i2c-eg20t: fix race between i2c init and interrupt enable commit 371a015344b6e270e7e3632107d9554ec6d27a6b upstream. the eg20t driver call request_irq() function before the pch_base_address, base address of i2c controller's register, is assigned an effective value. there is one possible scenario that an interrupt which isn't inside eg20t arrives immediately after request_irq() is executed when i2c controller shares an interrupt number with others. since the interrupt handler pch_i2c_handler() has already active as shared action, it will be called and read its own register to determine if this interrupt is from itself. At that moment, since base address of i2c registers is not remapped in kernel space yet,so the INT handler will access an illegal address and then a error occurs. Signed-off-by: Yadi.hu Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit f8fea9dc6c61cef7c1754e0b5a9f34c040152089 Author: Paul Burton Date: Tue Sep 13 17:53:35 2016 +0100 irqchip/mips-gic: Fix local interrupts commit e875bd66dfb68f4e898e9a43ef42858c504a7f23 upstream. Since the device hierarchy domain was added by commit c98c1822ee13 ("irqchip/mips-gic: Add device hierarchy domain"), GIC local interrupts have been broken. Users attempting to setup a per-cpu local IRQ, for example the GIC timer clock events code in drivers/clocksource/mips-gic-timer.c, the setup_percpu_irq function would refuse with -EINVAL because the GIC irqchip driver never called irq_set_percpu_devid so the IRQ_PER_CPU_DEVID flag was never set for the IRQ. This happens because irq_set_percpu_devid was being called from the gic_irq_domain_map function which is no longer called. Doing only that runs into further problems because gic_dev_domain_alloc set the struct irq_chip for all interrupts, local or shared, to gic_level_irq_controller despite that only being suitable for shared interrupts. The typical outcome of this is that gic_level_irq_controller callback functions are called for local interrupts, and then hwirq number calculations overflow & the driver ends up attempting to access some invalid register with an address calculated from an invalid hwirq number. Best case scenario is that this then leads to a bus error. This is fixed by abstracting the setup of the hwirq & chip to a new function gic_setup_dev_chip which is used by both the root GIC IRQ domain & the device domain. Finally, decoding local interrupts failed because gic_dev_domain_alloc only called irq_domain_alloc_irqs_parent for shared interrupts. Local ones were therefore never associated with hwirqs in the root GIC IRQ domain and the virq in gic_handle_local_int would always be 0. This is fixed by calling irq_domain_alloc_irqs_parent unconditionally & having gic_irq_domain_alloc handle both local & shared interrupts, which is easy due to the aforementioned abstraction of chip setup into gic_setup_dev_chip. This fixes use of the MIPS GIC timer for clock events, which has been broken since c98c1822ee13 ("irqchip/mips-gic: Add device hierarchy domain") but hadn't been noticed due to a silent fallback to the MIPS coprocessor 0 count/compare clock events device. Fixes: c98c1822ee13 ("irqchip/mips-gic: Add device hierarchy domain") Signed-off-by: Paul Burton Cc: linux-mips@linux-mips.org Cc: Jason Cooper Cc: Qais Yousef Cc: Marc Zyngier Link: http://lkml.kernel.org/r/20160913165335.31389-1-paul.burton@imgtec.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 39b47d3781fd51adee50b64cc0a4d52e8b873f6a Author: Matt Fleming Date: Mon Sep 19 13:09:09 2016 +0100 x86/efi: Only map RAM into EFI page tables if in mixed-mode commit 1297667083d5442aafe3e337b9413bf02b114edb upstream. Waiman reported that booting with CONFIG_EFI_MIXED enabled on his multi-terabyte HP machine results in boot crashes, because the EFI region mapping functions loop forever while trying to map those regions describing RAM. While this patch doesn't fix the underlying hang, there's really no reason to map EFI_CONVENTIONAL_MEMORY regions into the EFI page tables when mixed-mode is not in use at runtime. Reported-by: Waiman Long Cc: Ard Biesheuvel Cc: Borislav Petkov Cc: Linus Torvalds CC: Theodore Ts'o Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Scott J Norton Cc: Douglas Hatch Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit eb06045e539d847789f0a42c843559955deba693 Author: Jeff Mahoney Date: Wed Sep 21 08:31:29 2016 -0400 btrfs: ensure that file descriptor used with subvol ioctls is a dir commit 325c50e3cebb9208009083e841550f98a863bfa0 upstream. If the subvol/snapshot create/destroy ioctls are passed a regular file with execute permissions set, we'll eventually Oops while trying to do inode->i_op->lookup via lookup_one_len. This patch ensures that the file descriptor refers to a directory. Fixes: cb8e70901d (Btrfs: Fix subvolume creation locking rules) Fixes: 76dda93c6a (Btrfs: add snapshot/subvolume destroy ioctl) Signed-off-by: Jeff Mahoney Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit e402ffdeac99861b5b9c06ce7939815130b281bb Author: Johannes Berg Date: Tue Sep 13 15:53:55 2016 +0200 nl80211: validate number of probe response CSA counters commit ad5987b47e96a0fb6d13fea250e936aed000093c upstream. Due to an apparent copy/paste bug, the number of counters for the beacon configuration were checked twice, instead of checking the number of probe response counters. Fix this to check the number of probe response counters before parsing those. Fixes: 9a774c78e211 ("cfg80211: Support multiple CSA counters") Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 29adc609e25048bae1ed3261fc9f770a0f2ba91d Author: Beni Lev Date: Wed Aug 10 17:03:43 2016 +0300 iwlwifi: mvm: update TX queue before making a copy of the skb commit 54c5ef2e93ea002dc5dd63349298b2778fe59edb upstream. Off-channel action frames (such as ANQP frames) must be sent either on the AUX queue or on the offchannel queue, otherwise the firmware will cause a SYSASSERT. In the current implementation, the queue to be used is correctly set in the original skb, but this is done after it is copied. Thus the copy remains with the original, incorrect queue. Fix this by setting the queue in the original skb before copying it. Fixes: commit 5c08b0f5026f ("iwlwifi: mvm: don't override the rate with the AMSDU len") Signed-off-by: Beni Lev Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit 8c48d21dc2f90c07c2ae7e2c16b2807596d722ca Author: Marek Vasut Date: Mon Sep 19 21:34:01 2016 +0200 net: can: ifi: Configure transmitter delay commit 8d58790b832e13d6006d842037732304af357c3c upstream. Configure the transmitter delay register at +0x1c to correctly handle the CAN FD bitrate switch (BRS). This moves the SSP (secondary sample point) to a proper offset, so that the TDC mechanism works and won't generate error frames on the CAN link. Signed-off-by: Marek Vasut Cc: Marc Kleine-Budde Cc: Mark Rutland Cc: Oliver Hartkopp Cc: Wolfgang Grandegger Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 68e864b40b99ac0e5030a1bb1201b83f73f39d0d Author: Fabio Estevam Date: Wed Aug 17 12:41:08 2016 -0300 can: flexcan: fix resume function commit 4de349e786a3a2d51bd02d56f3de151bbc3c3df9 upstream. On a imx6ul-pico board the following error is seen during system suspend: dpm_run_callback(): platform_pm_resume+0x0/0x54 returns -110 PM: Device 2090000.flexcan failed to resume: error -110 The reason for this suspend error is because when the CAN interface is not active the clocks are disabled and then flexcan_chip_enable() will always fail due to a timeout error. In order to fix this issue, only call flexcan_chip_enable/disable() when the CAN interface is active. Based on a patch from Dong Aisheng in the NXP kernel. Signed-off-by: Fabio Estevam Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 1d5617bfe03a4da4e1eeb6bc9cce6ffed1f8e891 Author: Hugh Dickins Date: Fri Sep 23 20:27:04 2016 -0700 mm: delete unnecessary and unsafe init_tlb_ubc() commit b385d21f27d86426472f6ae92a231095f7de2a8d upstream. init_tlb_ubc() looked unnecessary to me: tlb_ubc is statically initialized with zeroes in the init_task, and copied from parent to child while it is quiescent in arch_dup_task_struct(); so I went to delete it. But inserted temporary debug WARN_ONs in place of init_tlb_ubc() to check that it was always empty at that point, and found them firing: because memcg reclaim can recurse into global reclaim (when allocating biosets for swapout in my case), and arrive back at the init_tlb_ubc() in shrink_node_memcg(). Resetting tlb_ubc.flush_required at that point is wrong: if the upper level needs a deferred TLB flush, but the lower level turns out not to, we miss a TLB flush. But fortunately, that's the only part of the protocol that does not nest: with the initialization removed, cpumask collects bits from upper and lower levels, and flushes TLB when needed. Fixes: 72b252aed506 ("mm: send one IPI per CPU to TLB flush all entries after unmapping pages") Signed-off-by: Hugh Dickins Acked-by: Mel Gorman Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9092c241e15bdb8eec52354e2c04fbc13b7ca675 Author: Steven Rostedt (Red Hat) Date: Fri Sep 23 22:57:13 2016 -0400 tracing: Move mutex to protect against resetting of seq data commit 1245800c0f96eb6ebb368593e251d66c01e61022 upstream. The iter->seq can be reset outside the protection of the mutex. So can reading of user data. Move the mutex up to the beginning of the function. Fixes: d7350c3f45694 ("tracing/core: make the read callbacks reentrants") Reported-by: Al Viro Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 09ae540c5e0aa7ea1f0c5573939a02e1d7e2a378 Author: Al Viro Date: Sat Sep 17 18:31:46 2016 -0400 fix memory leaks in tracing_buffers_splice_read() commit 1ae2293dd6d2f5c823cf97e60b70d03631cd622f upstream. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 22f591e2171dc6e8210e0d891bbf7fcad19bf503 Author: Johannes Berg Date: Wed Sep 14 11:38:31 2016 +0200 mac80211: reject TSPEC TIDs (TSIDs) for aggregation commit 85d5313ed717ad60769491c7c072d23bc0a68e7a upstream. Since mac80211 doesn't currently support TSIDs 8-15 which can only be used after QoS TSPEC negotiation (and not even after WMM negotiation), reject attempts to set up aggregation sessions for them, which might confuse drivers. In mac80211 we do correctly handle that, but the TSIDs should never get used anyway, and drivers might not be able to handle it. Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit c11aadb9babfba7401de5af8d34391a72e36cee3 Author: Arvind Yadav Date: Fri Aug 12 20:49:18 2016 +0530 power: reset: hisi-reboot: Unmap region obtained by of_iomap commit bae170efd6c42bf116f513a1dd07639d68fa71b9 upstream. Free memory mapping, if probe is not successful. Fixes: 4a9b37371822 ("power: reset: move hisilicon reboot code") Signed-off-by: Arvind Yadav Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 1c79cde5f08004f1d9881e36580f4cbf37b095d5 Author: Keerthy Date: Wed Jun 1 16:19:07 2016 +0530 rtc: ds1307: Fix relying on reset value for weekday commit e29385fab0bf94017fac130ee32f5bb2daf74417 upstream. The reset value of weekday is 0x1. This is wrong since the reset values of the day/month/year make up to Jan 1 2001. When computed weekday comes out to be Monday. On a scale of 1-7(Sunday - Saturday) it should be 0x2. So we should not be relying on the reset value. Hence compute the wday using the current date/month/year values. Check if reset wday is any different from the computed wday, If different then set the wday which we computed using date/month/year values. Document Referred: http://ww1.microchip.com/downloads/en/DeviceDoc/20002266F.pdf Fixes: 1d1945d261a2af "drivers/rtc/rtc-ds1307.c: add alarm support for mcp7941x chips" Signed-off-by: Keerthy Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit e7c5a957389376853e75767f7fdf532a5ebd3392 Author: John Youn Date: Tue May 31 16:55:01 2016 -0700 reset: Return -ENOTSUPP when not configured commit 168d7c4e8bb25c076ed8be67fcca84f5dcd0b2c6 upstream. Prior to commit 6c96f05c8bb8 ("reset: Make [of_]reset_control_get[_foo] functions wrappers"), the "optional" functions returned -ENOTSUPP when CONFIG_RESET_CONTROLLER was not set. Revert back to the old behavior by changing the new __devm_reset_control_get() and __of_reset_control_get() functions to return ERR_PTR(-ENOTSUPP) when compiled without CONFIG_RESET_CONTROLLER. Otherwise they will return -EINVAL causing users to think that an error occurred when CONFIG_RESET_CONTROLLER is not set. Fixes: 6c96f05c8bb8 ("reset: Make [of_]reset_control_get[_foo] functions wrappers") Signed-off-by: John Youn Signed-off-by: Philipp Zabel Signed-off-by: Greg Kroah-Hartman commit 16964b31c088636d1b0f4de69b8214d27134d5f2 Author: Brian Norris Date: Fri Jun 24 10:38:14 2016 -0700 mtd: spi-nor: fix wrong "fully unlocked" test commit 06586204714b7befec99e554c71687b0b40f351c upstream. In stm_unlock(), the test to determine whether we've fully unlocked the flash checks for the lock length to be equal to the flash size. That is a typo/think-o -- the condition actually means the flash is completely *locked.* We should be using the inverse condition -- that the lock length is 0 (i.e., no protection). The result of this bug is that we never actually turn off the Status Register Write Disable bit, even if the flash is completely unlocked. Now we can. Fixes: 47b8edbf0d43 ("mtd: spi-nor: disallow further writes to SR if WP# is low") Reported-by: Giorgio Signed-off-by: Brian Norris Cc: Ezequiel Garcia Signed-off-by: Greg Kroah-Hartman commit dc4773f971f08d6a674011314d85ff347bd40056 Author: Dan Carpenter Date: Thu Jul 14 13:44:56 2016 +0300 mtd: pmcmsp-flash: Allocating too much in init_msp_flash() commit 79ad07d45743721010e766e65dc004ad249bd429 upstream. There is a cut and paste issue here. The bug is that we are allocating more memory than necessary for msp_maps. We should be allocating enough space for a map_info struct (144 bytes) but we instead allocate enough for an mtd_info struct (1840 bytes). It's a small waste. The other part of this is not harmful but when we allocated msp_flash then we allocated enough space fro a map_info pointer instead of an mtd_info pointer. But since pointers are the same size it works out fine. Anyway, I decided to clean up all three allocations a bit to make them a bit more consistent and clear. Fixes: 68aa0fa87f6d ('[MTD] PMC MSP71xx flash/rootfs mappings') Signed-off-by: Dan Carpenter Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit 3f98badc15b1efa2f3ff1ea865c0e9282df50fea Author: Dan Carpenter Date: Fri Jul 15 14:06:30 2016 +0300 mtd: maps: sa1100-flash: potential NULL dereference commit dc01a28d80a42cef08c94dfc595565aaebe46d15 upstream. We check for NULL but then dereference "info->mtd" on the next line. Fixes: 72169755cf36 ('mtd: maps: sa1100-flash: show parent device in sysfs') Signed-off-by: Dan Carpenter Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit 753de51f8aa9e0550aa8a4730cf1e4869e6488f4 Author: Lothar Waßmann Date: Mon Sep 19 11:09:40 2016 +0200 mtd: nand: mxc: fix obiwan error in mxc_nand_v[12]_ooblayout_free() functions commit 38178e7b88dcbe1ab384f27a7370074e774dda81 upstream. commit a894cf6c5a82 ("mtd: nand: mxc: switch to mtd_ooblayout_ops") introduced a regression accessing the OOB area from the mxc_nand driver due to an Obiwan error in the mxc_nand_v[12]_ooblayout_free() functions. They report a bogus oobregion { 64, 7 } which leads to errors accessing bogus data when reading the oob area. Prior to the commit the mtd-oobtest module could be run without any errors. With the offending commit, this test fails with results like: |Running mtd-oobtest | |================================================= |mtd_oobtest: MTD device: 5 |mtd_oobtest: MTD device size 524288, eraseblock size 131072, page size 2048, count of eraseblocks 4, pages per eraseblock 64, OOB size 64 |mtd_test: scanning for bad eraseblocks |mtd_test: scanned 4 eraseblocks, 0 are bad |mtd_oobtest: test 1 of 5 |mtd_oobtest: writing OOBs of whole device |mtd_oobtest: written up to eraseblock 0 |mtd_oobtest: written 4 eraseblocks |mtd_oobtest: verifying all eraseblocks |mtd_oobtest: error @addr[0x0:0x19] 0x9a -> 0x78 diff 0xe2 |mtd_oobtest: error @addr[0x0:0x1a] 0xcc -> 0x0 diff 0xcc |mtd_oobtest: error @addr[0x0:0x1b] 0xe0 -> 0x85 diff 0x65 |mtd_oobtest: error @addr[0x0:0x1c] 0x60 -> 0x62 diff 0x2 |mtd_oobtest: error @addr[0x0:0x1d] 0x69 -> 0x45 diff 0x2c |mtd_oobtest: error @addr[0x0:0x1e] 0xcd -> 0xa0 diff 0x6d |mtd_oobtest: error @addr[0x0:0x1f] 0xf2 -> 0x60 diff 0x92 |mtd_oobtest: error: verify failed at 0x0 [...] Signed-off-by: Lothar Waßmann Fixes: a894cf6c5a82 ("mtd: nand: mxc: switch to mtd_ooblayout_ops") Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman commit 71b4a3c04e5b9e69f2b53aac5248a7b34cd57bae Author: Phil Turnbull Date: Thu Sep 15 12:20:12 2016 -0400 configfs: Return -EFBIG from configfs_write_bin_file. commit 42857cf512cb34c2c8cb50f1e766689d979d64e0 upstream. The check for writing more than cb_max_size bytes does not 'goto out' so it is a no-op which allows users to vmalloc an arbitrary amount. Fixes: 03607ace807b ("configfs: implement binary attributes") Signed-off-by: Phil Turnbull Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit 84bba4be776b894e092bede0797910674da99d58 Author: David Daney Date: Tue Sep 20 11:46:35 2016 -0700 arm64: Call numa_store_cpu_info() earlier. commit c18df0adabf8400c1825b90382d06df5edc303fa upstream. The wq_numa_init() function makes a private CPU to node map by calling cpu_to_node() early in the boot process, before the non-boot CPUs are brought online. Since the default implementation of cpu_to_node() returns zero for CPUs that have never been brought online, the workqueue system's view is that *all* CPUs are on node zero. When the unbound workqueue for a non-zero node is created, the tsk_cpus_allowed() for the worker threads is the empty set because there are, in the view of the workqueue system, no CPUs on non-zero nodes. The code in try_to_wake_up() using this empty cpumask ends up using the cpumask empty set value of NR_CPUS as an index into the per-CPU area pointer array, and gets garbage as it is one past the end of the array. This results in: [ 0.881970] Unable to handle kernel paging request at virtual address fffffb1008b926a4 [ 1.970095] pgd = fffffc00094b0000 [ 1.973530] [fffffb1008b926a4] *pgd=0000000000000000, *pud=0000000000000000, *pmd=0000000000000000 [ 1.982610] Internal error: Oops: 96000004 [#1] SMP [ 1.987541] Modules linked in: [ 1.990631] CPU: 48 PID: 295 Comm: cpuhp/48 Tainted: G W 4.8.0-rc6-preempt-vol+ #9 [ 1.999435] Hardware name: Cavium ThunderX CN88XX board (DT) [ 2.005159] task: fffffe0fe89cc300 task.stack: fffffe0fe8b8c000 [ 2.011158] PC is at try_to_wake_up+0x194/0x34c [ 2.015737] LR is at try_to_wake_up+0x150/0x34c [ 2.020318] pc : [] lr : [] pstate: 600000c5 [ 2.027803] sp : fffffe0fe8b8fb10 [ 2.031149] x29: fffffe0fe8b8fb10 x28: 0000000000000000 [ 2.036522] x27: fffffc0008c63bc8 x26: 0000000000001000 [ 2.041896] x25: fffffc0008c63c80 x24: fffffc0008bfb200 [ 2.047270] x23: 00000000000000c0 x22: 0000000000000004 [ 2.052642] x21: fffffe0fe89d25bc x20: 0000000000001000 [ 2.058014] x19: fffffe0fe89d1d00 x18: 0000000000000000 [ 2.063386] x17: 0000000000000000 x16: 0000000000000000 [ 2.068760] x15: 0000000000000018 x14: 0000000000000000 [ 2.074133] x13: 0000000000000000 x12: 0000000000000000 [ 2.079505] x11: 0000000000000000 x10: 0000000000000000 [ 2.084879] x9 : 0000000000000000 x8 : 0000000000000000 [ 2.090251] x7 : 0000000000000040 x6 : 0000000000000000 [ 2.095621] x5 : ffffffffffffffff x4 : 0000000000000000 [ 2.100991] x3 : 0000000000000000 x2 : 0000000000000000 [ 2.106364] x1 : fffffc0008be4c24 x0 : ffffff0ffffada80 [ 2.111737] [ 2.113236] Process cpuhp/48 (pid: 295, stack limit = 0xfffffe0fe8b8c020) [ 2.120102] Stack: (0xfffffe0fe8b8fb10 to 0xfffffe0fe8b90000) [ 2.125914] fb00: fffffe0fe8b8fb80 fffffc00080e7648 . . . [ 2.442859] Call trace: [ 2.445327] Exception stack(0xfffffe0fe8b8f940 to 0xfffffe0fe8b8fa70) [ 2.451843] f940: fffffe0fe89d1d00 0000040000000000 fffffe0fe8b8fb10 fffffc00080e7468 [ 2.459767] f960: fffffe0fe8b8f980 fffffc00080e4958 ffffff0ff91ab200 fffffc00080e4b64 [ 2.467690] f980: fffffe0fe8b8f9d0 fffffc00080e515c fffffe0fe8b8fa80 0000000000000000 [ 2.475614] f9a0: fffffe0fe8b8f9d0 fffffc00080e58e4 fffffe0fe8b8fa80 0000000000000000 [ 2.483540] f9c0: fffffe0fe8d10000 0000000000000040 fffffe0fe8b8fa50 fffffc00080e5ac4 [ 2.491465] f9e0: ffffff0ffffada80 fffffc0008be4c24 0000000000000000 0000000000000000 [ 2.499387] fa00: 0000000000000000 ffffffffffffffff 0000000000000000 0000000000000040 [ 2.507309] fa20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 2.515233] fa40: 0000000000000000 0000000000000000 0000000000000000 0000000000000018 [ 2.523156] fa60: 0000000000000000 0000000000000000 [ 2.528089] [] try_to_wake_up+0x194/0x34c [ 2.533723] [] wake_up_process+0x28/0x34 [ 2.539275] [] create_worker+0x110/0x19c [ 2.544824] [] alloc_unbound_pwq+0x3cc/0x4b0 [ 2.550724] [] wq_update_unbound_numa+0x10c/0x1e4 [ 2.557066] [] workqueue_online_cpu+0x220/0x28c [ 2.563234] [] cpuhp_invoke_callback+0x6c/0x168 [ 2.569398] [] cpuhp_up_callbacks+0x44/0xe4 [ 2.575210] [] cpuhp_thread_fun+0x13c/0x148 [ 2.581027] [] smpboot_thread_fn+0x19c/0x1a8 [ 2.586929] [] kthread+0xdc/0xf0 [ 2.591776] [] ret_from_fork+0x10/0x50 [ 2.597147] Code: b00057e1 91304021 91005021 b8626822 (b8606821) [ 2.603464] ---[ end trace 58c0cd36b88802bc ]--- [ 2.608138] Kernel panic - not syncing: Fatal exception Fix by moving call to numa_store_cpu_info() for all CPUs into smp_prepare_cpus(), which happens before wq_numa_init(). Since smp_store_cpu_info() now contains only a single function call, simplify by removing the function and out-lining its contents. Suggested-by: Robert Richter Fixes: 1a2db300348b ("arm64, numa: Add NUMA support for arm64 platforms.") Signed-off-by: David Daney Reviewed-by: Robert Richter Tested-by: Yisheng Xie Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit f3edd9b2367a3754e61eefb8ecd457013f44385d Author: Herbert Xu Date: Tue Sep 20 20:35:55 2016 +0800 KEYS: Fix skcipher IV clobbering commit 456bee986e0a372ad4beed5d3cedb3622633d9df upstream. The IV must not be modified by the skcipher operation so we need to duplicate it. Fixes: c3917fd9dfbc ("KEYS: Use skcipher") Reported-by: Mimi Zohar Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 206d4c6c0195a363e5a610878ae9d5354eec0f6b Author: Al Viro Date: Tue Sep 20 20:07:42 2016 +0100 fix fault_in_multipages_...() on architectures with no-op access_ok() commit e23d4159b109167126e5bcd7f3775c95de7fee47 upstream. Switching iov_iter fault-in to multipages variants has exposed an old bug in underlying fault_in_multipages_...(); they break if the range passed to them wraps around. Normally access_ok() done by callers will prevent such (and it's a guaranteed EFAULT - ERR_PTR() values fall into such a range and they should not point to any valid objects). However, on architectures where userland and kernel live in different MMU contexts (e.g. s390) access_ok() is a no-op and on those a range with a wraparound can reach fault_in_multipages_...(). Since any wraparound means EFAULT there, the fix is trivial - turn those while (uaddr <= end) ... into if (unlikely(uaddr > end)) return -EFAULT; do ... while (uaddr <= end); Reported-by: Jan Stancek Tested-by: Jan Stancek Signed-off-by: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 02d35700208c7a13a75405018222646502608961 Author: Johannes Weiner Date: Mon Sep 19 14:44:38 2016 -0700 cgroup: duplicate cgroup reference when cloning sockets commit d979a39d7242e0601bf9b60e89628fb8ac577179 upstream. When a socket is cloned, the associated sock_cgroup_data is duplicated but not its reference on the cgroup. As a result, the cgroup reference count will underflow when both sockets are destroyed later on. Fixes: bd1060a1d671 ("sock, cgroup: add sock->sk_cgroup") Link: http://lkml.kernel.org/r/20160914194846.11153-2-hannes@cmpxchg.org Signed-off-by: Johannes Weiner Acked-by: Tejun Heo Cc: Michal Hocko Cc: Vladimir Davydov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0d91b17b239118104998d5a3f0da016c93be7b69 Author: Johannes Weiner Date: Mon Sep 19 14:44:36 2016 -0700 mm: memcontrol: make per-cpu charge cache IRQ-safe for socket accounting commit db2ba40c277dc545bab531671c3f45ac0afea6f8 upstream. During cgroup2 rollout into production, we started encountering css refcount underflows and css access crashes in the memory controller. Splitting the heavily shared css reference counter into logical users narrowed the imbalance down to the cgroup2 socket memory accounting. The problem turns out to be the per-cpu charge cache. Cgroup1 had a separate socket counter, but the new cgroup2 socket accounting goes through the common charge path that uses a shared per-cpu cache for all memory that is being tracked. Those caches are safe against scheduling preemption, but not against interrupts - such as the newly added packet receive path. When cache draining is interrupted by network RX taking pages out of the cache, the resuming drain operation will put references of in-use pages, thus causing the imbalance. Disable IRQs during all per-cpu charge cache operations. Fixes: f7e1cb6ec51b ("mm: memcontrol: account socket memory in unified hierarchy memory controller") Link: http://lkml.kernel.org/r/20160914194846.11153-1-hannes@cmpxchg.org Signed-off-by: Johannes Weiner Acked-by: Tejun Heo Cc: "David S. Miller" Cc: Michal Hocko Cc: Vladimir Davydov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 45d4c53501c0119a6df29e28b259bf365d642ac3 Author: Jan Kara Date: Mon Sep 19 14:44:30 2016 -0700 fanotify: fix list corruption in fanotify_get_response() commit 96d41019e3ac55f6f0115b0ce97e4f24a3d636d2 upstream. fanotify_get_response() calls fsnotify_remove_event() when it finds that group is being released from fanotify_release() (bypass_perm is set). However the event it removes need not be only in the group's notification queue but it can have already moved to access_list (userspace read the event before closing the fanotify instance fd) which is protected by a different lock. Thus when fsnotify_remove_event() races with fanotify_release() operating on access_list, the list can get corrupted. Fix the problem by moving all the logic removing permission events from the lists to one place - fanotify_release(). Fixes: 5838d4442bd5 ("fanotify: fix double free of pending permission events") Link: http://lkml.kernel.org/r/1473797711-14111-3-git-send-email-jack@suse.cz Signed-off-by: Jan Kara Reported-by: Miklos Szeredi Tested-by: Miklos Szeredi Reviewed-by: Miklos Szeredi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e0d4517ceabd3cd0aeb37efa6022bebb93229cff Author: Jan Kara Date: Mon Sep 19 14:44:27 2016 -0700 fsnotify: add a way to stop queueing events on group shutdown commit 12703dbfeb15402260e7554d32a34ac40c233990 upstream. Implement a function that can be called when a group is being shutdown to stop queueing new events to the group. Fanotify will use this. Fixes: 5838d4442bd5 ("fanotify: fix double free of pending permission events") Link: http://lkml.kernel.org/r/1473797711-14111-2-git-send-email-jack@suse.cz Signed-off-by: Jan Kara Reviewed-by: Miklos Szeredi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 364020ae14b9411248dda6033269b340ebadba21 Author: Santosh Shilimkar Date: Mon Sep 19 14:44:15 2016 -0700 mm: fix the page_swap_info() BUG_ON check commit c8de641b1e9c5489aa6ca57b7836acd68e7563f1 upstream. Commit 62c230bc1790 ("mm: add support for a filesystem to activate swap files and use direct_IO for writing swap pages") replaced the swap_aops dirty hook from __set_page_dirty_no_writeback() with swap_set_page_dirty(). For normal cases without these special SWP flags code path falls back to __set_page_dirty_no_writeback() so the behaviour is expected to be the same as before. But swap_set_page_dirty() makes use of the page_swap_info() helper to get the swap_info_struct to check for the flags like SWP_FILE, SWP_BLKDEV etc as desired for those features. This helper has BUG_ON(!PageSwapCache(page)) which is racy and safe only for the set_page_dirty_lock() path. For the set_page_dirty() path which is often needed for cases to be called from irq context, kswapd() can toggle the flag behind the back while the call is getting executed when system is low on memory and heavy swapping is ongoing. This ends up with undesired kernel panic. This patch just moves the check outside the helper to its users appropriately to fix kernel panic for the described path. Couple of users of helpers already take care of SwapCache condition so I skipped them. Link: http://lkml.kernel.org/r/1473460718-31013-1-git-send-email-santosh.shilimkar@oracle.com Signed-off-by: Santosh Shilimkar Cc: Mel Gorman Cc: Joe Perches Cc: Peter Zijlstra Cc: Rik van Riel Cc: David S. Miller Cc: Jens Axboe Cc: Michal Hocko Cc: Hugh Dickins Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7027a3589328f561be7f3c42d3d19fbafe9afb34 Author: Brian Foster Date: Fri Aug 26 16:01:59 2016 +1000 xfs: prevent dropping ioend completions during buftarg wait commit 800b2694f890cc35a1bda63501fc71c94389d517 upstream. xfs_wait_buftarg() waits for all pending I/O, drains the ioend completion workqueue and walks the LRU until all buffers in the cache have been released. This is traditionally an unmount operation` but the mechanism is also reused during filesystem freeze. xfs_wait_buftarg() invokes drain_workqueue() as part of the quiesce, which is intended more for a shutdown sequence in that it indicates to the queue that new operations are not expected once the drain has begun. New work jobs after this point result in a WARN_ON_ONCE() and are otherwise dropped. With filesystem freeze, however, read operations are allowed and can proceed during or after the workqueue drain. If such a read occurs during the drain sequence, the workqueue infrastructure complains about the queued ioend completion work item and drops it on the floor. As a result, the buffer remains on the LRU and the freeze never completes. Despite the fact that the overall buffer cache cleanup is not necessary during freeze, fix up this operation such that it is safe to invoke during non-unmount quiesce operations. Replace the drain_workqueue() call with flush_workqueue(), which runs a similar serialization on pending workqueue jobs without causing new jobs to be dropped. This is safe for unmount as unmount independently locks out new operations by the time xfs_wait_buftarg() is invoked. cc: Signed-off-by: Brian Foster Reviewed-by: Christoph Hellwig Signed-off-by: Dave Chinner Signed-off-by: Greg Kroah-Hartman commit 93200d680909135bacbdb856756c92e7f0f7bca4 Author: Steven Rostedt Date: Thu Jul 28 22:30:43 2016 -0400 Makefile: Mute warning for __builtin_return_address(>0) for tracing only commit 377ccbb483738f84400ddf5840c7dd8825716985 upstream. With the latest gcc compilers, they give a warning if __builtin_return_address() parameter is greater than 0. That is because if it is used by a function called by a top level function (or in the case of the kernel, by assembly), it can try to access stack frames outside the stack and crash the system. The tracing system uses __builtin_return_address() of up to 2! But it is well aware of the dangers that it may have, and has even added precautions to protect against it (see the thunk code in arch/x86/entry/thunk*.S) Linus originally added KBUILD_CFLAGS that would suppress the warning for the entire kernel, as simply adding KBUILD_CFLAGS to the tracing directory wouldn't work. The tracing directory plays a bit with the CFLAGS and requires a little more logic. This adds that special logic to only suppress the warning for the tracing directory. If it is used anywhere else outside of tracing, the warning will still be triggered. Link: http://lkml.kernel.org/r/20160728223043.51996267@grimm.local.home Tested-by: Linus Torvalds Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 90d2d8f395dd5b7e4576653af9725e722f4dd5ca Author: Linus Torvalds Date: Wed Jul 27 19:03:04 2016 -0700 Disable "frame-address" warning commit 124a3d88fa20e1869fc229d7d8c740cc81944264 upstream. Newer versions of gcc warn about the use of __builtin_return_address() with a non-zero argument when "-Wall" is specified: kernel/trace/trace_irqsoff.c: In function ‘stop_critical_timings’: kernel/trace/trace_irqsoff.c:433:86: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe [-Wframe-address] stop_critical_timing(CALLER_ADDR0, CALLER_ADDR1); [ .. repeats a few times for other similar cases .. ] It is true that a non-zero argument is somewhat dangerous, and we do not actually have very many uses of that in the kernel - but the ftrace code does use it, and as Stephen Rostedt says: "We are well aware of the danger of using __builtin_return_address() of > 0. In fact that's part of the reason for having the "thunk" code in x86 (See arch/x86/entry/thunk_{64,32}.S). [..] it adds extra frames when tracking irqs off sections, to prevent __builtin_return_address() from accessing bad areas. In fact the thunk_32.S states: 'Trampoline to trace irqs off. (otherwise CALLER_ADDR1 might crash)'." For now, __builtin_return_address() with a non-zero argument is the best we can do, and the warning is not helpful and can end up making people miss other warnings for real problems. So disable the frame-address warning on compilers that need it. Acked-by: Steven Rostedt Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 63f4bb7d3552028ce92aacae7784f6cf3d01f17f Author: Linus Torvalds Date: Wed Jul 27 13:17:41 2016 -0700 Disable "maybe-uninitialized" warning globally commit 6e8d666e925333c55378e8d5540a8a9ee0eea9c5 upstream. Several build configurations had already disabled this warning because it generates a lot of false positives. But some had not, and it was still enabled for "allmodconfig" builds, for example. Looking at the warnings produced, every single one I looked at was a false positive, and the warnings are frequent enough (and big enough) that they can easily hide real problems that you don't notice in the noise generated by -Wmaybe-uninitialized. The warning is good in theory, but this is a classic case of a warning that causes more problems than the warning can solve. If gcc gets better at avoiding false positives, we may be able to re-enable this warning. But as is, we're better off without it, and I want to be able to see the *real* warnings. Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c911e4123523a184dc8f215810abc1d6d6549a22 Author: Ian Kent Date: Mon Sep 19 14:44:12 2016 -0700 autofs: use dentry flags to block walks during expire commit 7cbdb4a286a60c5d519cb9223fe2134d26870d39 upstream. Somewhere along the way the autofs expire operation has changed to hold a spin lock over expired dentry selection. The autofs indirect mount expired dentry selection is complicated and quite lengthy so it isn't appropriate to hold a spin lock over the operation. Commit 47be61845c77 ("fs/dcache.c: avoid soft-lockup in dput()") added a might_sleep() to dput() causing a WARN_ONCE() about this usage to be issued. But the spin lock doesn't need to be held over this check, the autofs dentry info. flags are enough to block walks into dentrys during the expire. I've left the direct mount expire as it is (for now) because it is much simpler and quicker than the indirect mount expire and adding spin lock release and re-aquires would do nothing more than add overhead. Fixes: 47be61845c77 ("fs/dcache.c: avoid soft-lockup in dput()") Link: http://lkml.kernel.org/r/20160912014017.1773.73060.stgit@pluto.themaw.net Signed-off-by: Ian Kent Reported-by: Takashi Iwai Tested-by: Takashi Iwai Cc: Takashi Iwai Cc: NeilBrown Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 223248f6312c3c6fd3945ecfed1c405a6179d5ab Author: Junxiao Bi Date: Mon Sep 19 14:44:44 2016 -0700 Revert "ocfs2: bump up o2cb network protocol version" commit 63b52c4936a2e679639c38ef51a50aa8ca1c5c07 upstream. This reverts commit 38b52efd218b ("ocfs2: bump up o2cb network protocol version"). This commit made rolling upgrade fail. When one node is upgraded to new version with this commit, the remaining nodes will fail to establish connections to it, then the application like VMs on the remaining nodes can't be live migrated to the upgraded one. This will cause an outage. Since negotiate hb timeout behavior didn't change without this commit, so revert it. Fixes: 38b52efd218bf ("ocfs2: bump up o2cb network protocol version") Link: http://lkml.kernel.org/r/1471396924-10375-1-git-send-email-junxiao.bi@oracle.com Signed-off-by: Junxiao Bi Cc: Mark Fasheh Cc: Joel Becker Cc: Joseph Qi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e29576aa70a87a349f28e45d359d1bb1e56dd531 Author: Ashish Samant Date: Mon Sep 19 14:44:42 2016 -0700 ocfs2: fix start offset to ocfs2_zero_range_for_truncate() commit d21c353d5e99c56cdd5b5c1183ffbcaf23b8b960 upstream. If we punch a hole on a reflink such that following conditions are met: 1. start offset is on a cluster boundary 2. end offset is not on a cluster boundary 3. (end offset is somewhere in another extent) or (hole range > MAX_CONTIG_BYTES(1MB)), we dont COW the first cluster starting at the start offset. But in this case, we were wrongly passing this cluster to ocfs2_zero_range_for_truncate() to zero out. This will modify the cluster in place and zero it in the source too. Fix this by skipping this cluster in such a scenario. To reproduce: 1. Create a random file of say 10 MB xfs_io -c 'pwrite -b 4k 0 10M' -f 10MBfile 2. Reflink it reflink -f 10MBfile reflnktest 3. Punch a hole at starting at cluster boundary with range greater that 1MB. You can also use a range that will put the end offset in another extent. fallocate -p -o 0 -l 1048615 reflnktest 4. sync 5. Check the first cluster in the source file. (It will be zeroed out). dd if=10MBfile iflag=direct bs= count=1 | hexdump -C Link: http://lkml.kernel.org/r/1470957147-14185-1-git-send-email-ashish.samant@oracle.com Signed-off-by: Ashish Samant Reported-by: Saar Maoz Reviewed-by: Srinivas Eeda Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Joseph Qi Cc: Eric Ren Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 09d56da6f68cb409582e54a10da9d8e41a9c8c8a Author: Joseph Qi Date: Mon Sep 19 14:43:55 2016 -0700 ocfs2/dlm: fix race between convert and migration commit e6f0c6e6170fec175fe676495f29029aecdf486c upstream. Commit ac7cf246dfdb ("ocfs2/dlm: fix race between convert and recovery") checks if lockres master has changed to identify whether new master has finished recovery or not. This will introduce a race that right after old master does umount ( means master will change), a new convert request comes. In this case, it will reset lockres state to DLM_RECOVERING and then retry convert, and then fail with lockres->l_action being set to OCFS2_AST_INVALID, which will cause inconsistent lock level between ocfs2 and dlm, and then finally BUG. Since dlm recovery will clear lock->convert_pending in dlm_move_lockres_to_recovery_list, we can use it to correctly identify the race case between convert and recovery. So fix it. Fixes: ac7cf246dfdb ("ocfs2/dlm: fix race between convert and recovery") Link: http://lkml.kernel.org/r/57CE1569.8010704@huawei.com Signed-off-by: Joseph Qi Signed-off-by: Jun Piao Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 77ead6507c98f793af265d09aa68533c59b8126d Author: Herbert Xu Date: Wed Sep 7 18:42:08 2016 +0800 crypto: echainiv - Replace chaining with multiplication commit 53a5d5ddccf849dbc27a8c1bba0b43c3a45fb792 upstream. The current implementation uses a global per-cpu array to store data which are used to derive the next IV. This is insecure as the attacker may change the stored data. This patch removes all traces of chaining and replaces it with multiplication of the salt and the sequence number. Fixes: a10f554fa7e0 ("crypto: echainiv - Add encrypted chain IV...") Reported-by: Mathias Krause Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit aa3520cf8c14a61e315b7e43756464e45dcc7ed1 Author: Herbert Xu Date: Tue Sep 13 14:43:29 2016 +0800 crypto: skcipher - Fix blkcipher walk OOM crash commit acdb04d0b36769b3e05990c488dc74d8b7ac8060 upstream. When we need to allocate a temporary blkcipher_walk_next and it fails, the code is supposed to take the slow path of processing the data block by block. However, due to an unrelated change we instead end up dereferencing the NULL pointer. This patch fixes it by moving the unrelated bsize setting out of the way so that we enter the slow path as inteded. Fixes: 7607bd8ff03b ("[CRYPTO] blkcipher: Added blkcipher_walk_virt_block") Reported-by: xiakaixu Reported-by: Ard Biesheuvel Signed-off-by: Herbert Xu Tested-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit e151a6f10fb1439832083dbf0b40a77f4f23cba3 Author: Ard Biesheuvel Date: Tue Sep 13 09:48:52 2016 +0100 crypto: arm/aes-ctr - fix NULL dereference in tail processing commit f82e90b28654804ab72881d577d87c3d5c65e2bc upstream. The AES-CTR glue code avoids calling into the blkcipher API for the tail portion of the walk, by comparing the remainder of walk.nbytes modulo AES_BLOCK_SIZE with the residual nbytes, and jumping straight into the tail processing block if they are equal. This tail processing block checks whether nbytes != 0, and does nothing otherwise. However, in case of an allocation failure in the blkcipher layer, we may enter this code with walk.nbytes == 0, while nbytes > 0. In this case, we should not dereference the source and destination pointers, since they may be NULL. So instead of checking for nbytes != 0, check for (walk.nbytes % AES_BLOCK_SIZE) != 0, which implies the former in non-error conditions. Fixes: 86464859cc77 ("crypto: arm - AES in ECB/CBC/CTR/XTS modes using ARMv8 Crypto Extensions") Reported-by: xiakaixu Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit d0868ac499ff3a177db4db263f60bce07cbe9634 Author: Ard Biesheuvel Date: Tue Sep 13 09:48:53 2016 +0100 crypto: arm64/aes-ctr - fix NULL dereference in tail processing commit 2db34e78f126c6001d79d3b66ab1abb482dc7caa upstream. The AES-CTR glue code avoids calling into the blkcipher API for the tail portion of the walk, by comparing the remainder of walk.nbytes modulo AES_BLOCK_SIZE with the residual nbytes, and jumping straight into the tail processing block if they are equal. This tail processing block checks whether nbytes != 0, and does nothing otherwise. However, in case of an allocation failure in the blkcipher layer, we may enter this code with walk.nbytes == 0, while nbytes > 0. In this case, we should not dereference the source and destination pointers, since they may be NULL. So instead of checking for nbytes != 0, check for (walk.nbytes % AES_BLOCK_SIZE) != 0, which implies the former in non-error conditions. Fixes: 49788fe2a128 ("arm64/crypto: AES-ECB/CBC/CTR/XTS using ARMv8 NEON and Crypto Extensions") Reported-by: xiakaixu Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit e3720827a4a94f62f99d6c0ae25de52815de3dbf Author: Jeff Mahoney Date: Tue Aug 2 14:05:33 2016 -0700 reiserfs: fix "new_insert_key may be used uninitialized ..." commit 0a11b9aae49adf1f952427ef1a1d9e793dd6ffb6 upstream. new_insert_key only makes any sense when it's associated with a new_insert_ptr, which is initialized to NULL and changed to a buffer_head when we also initialize new_insert_key. We can key off of that to avoid the uninitialized warning. Link: http://lkml.kernel.org/r/5eca5ffb-2155-8df2-b4a2-f162f105efed@suse.com Signed-off-by: Jeff Mahoney Cc: Arnd Bergmann Cc: Jan Kara Cc: Linus Torvalds Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman