commit fbc310e9c553412ebe72c14e5a7bb9807a3d1109 Author: Greg Kroah-Hartman Date: Wed May 4 14:50:38 2016 -0700 Linux 4.5.3 commit 4ab014655ebad342c6e7beae427c5cc0f8141d2b Author: Robert Jarzmik Date: Mon Feb 15 21:57:46 2016 +0100 dmaengine: mmp-pdma: add number of requestors commit c283e41ef32442f41e7180f9bb1c5aedf9255bfe upstream. The DMA chip has a fixed number of requestor lines used for flow control. This number is platform dependent. The pxa_dma dma driver will use this value to activate or not the flow control. There won't be any impact on mmp_pdma driver. Signed-off-by: Robert Jarzmik Signed-off-by: Greg Kroah-Hartman commit afd3dc5a2a2bb0f7164f2daa5972405759c07164 Author: Dan Carpenter Date: Thu Feb 4 14:36:09 2016 +0300 extcon: max77843: Use correct size for reading the interrupt register commit c4924e92442d7218bd725e47fa3988c73aae84c9 upstream. The info->status[] array has 3 elements. We are using size MAX77843_MUIC_IRQ_NUM (16) instead of MAX77843_MUIC_STATUS_NUM (3) as intended. Fixes: 135d9f7d135a ('extcon: max77843: Clear IRQ bits state before request IRQ') Signed-off-by: Dan Carpenter Reviewed-by: Jaewon Kim Reviewed-by: Krzysztof Kozlowski [cw00.choi: Modify the patch title] Signed-off-by: Chanwoo Choi Signed-off-by: Greg Kroah-Hartman commit 68517c93716826992dc91db6a65c57c7919a3484 Author: Arnd Bergmann Date: Tue Dec 22 17:25:17 2015 +0200 stm class: Select CONFIG_SRCU commit 042d4460b5b4379a12f375045ff9065cf6758735 upstream. The newly added STM code uses SRCU, but does not ensure that this code is part of the kernel: drivers/built-in.o: In function `stm_source_link_show': include/linux/srcu.h:221: undefined reference to `__srcu_read_lock' include/linux/srcu.h:238: undefined reference to `__srcu_read_unlock' drivers/built-in.o: In function `stm_source_link_drop': include/linux/srcu.h:221: undefined reference to `__srcu_read_lock' include/linux/srcu.h:238: undefined reference to `__srcu_read_unlock' This adds a Kconfig 'select' statement like all the other SRCU using drivers have. Signed-off-by: Arnd Bergmann Fixes: 7bd1d4093c2f ("stm class: Introduce an abstraction for System Trace Module devices") Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman commit 220167e67dbf387f949ef6bb370c71867f64e29d Author: Jarkko Sakkinen Date: Sat Feb 13 11:51:23 2016 +0200 tpm: fix: set continueSession attribute for the unseal operation commit c0b5eed110dcf520aadafefbcc40658cbdd18b95 upstream. It's better to set the continueSession attribute for the unseal operation so that the session object is not removed as a side-effect when the operation is successful. Since a user process created the session, it should be also decide when the session is destroyed. Signed-off-by: Jarkko Sakkinen Fixes: 5beb0c435b ("keys, trusted: seal with a TPM2 authorization policy") Signed-off-by: Greg Kroah-Hartman commit 5504693f5dcfae316d10706f6367f8724d69c67f Author: Jarkko Sakkinen Date: Wed Jan 6 16:43:30 2016 +0200 tpm: fix checks for policy digest existence in tpm2_seal_trusted() commit f3c82ade7c59303167d56b0be3e0707751fc45e2 upstream. In my original patch sealing with policy was done with dynamically allocated buffer that I changed later into an array so the checks in tpm2-cmd.c became invalid. This patch fixes the issue. Fixes: 5beb0c435bdd ("keys, trusted: seal with a TPM2 authorization policy") Reported-by: Dan Carpenter Signed-off-by: Jarkko Sakkinen Acked-by: Peter Huewe Signed-off-by: Greg Kroah-Hartman commit d84be57178d73e9007704e34ac510974a1c380aa Author: Arnd Bergmann Date: Mon Mar 14 15:29:45 2016 +0100 megaraid_sas: add missing curly braces in ioctl handler commit 3deb9438d34a09f6796639b652a01d110aca9f75 upstream. gcc-6 found a dubious indentation in the megasas_mgmt_fw_ioctl function: drivers/scsi/megaraid/megaraid_sas_base.c: In function 'megasas_mgmt_fw_ioctl': drivers/scsi/megaraid/megaraid_sas_base.c:6658:4: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation] kbuff_arr[i] = NULL; ^~~~~~~~~ drivers/scsi/megaraid/megaraid_sas_base.c:6653:3: note: ...this 'if' clause, but it is not if (kbuff_arr[i]) ^~ The code is actually correct, as there is no downside in clearing a NULL pointer again. This clarifies the code and avoids the warning by adding extra curly braces. Signed-off-by: Arnd Bergmann Fixes: 90dc9d98f01b ("megaraid_sas : MFI MPT linked list corruption fix") Reviewed-by: Hannes Reinecke Acked-by: Sumit Saxena Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 804dc5091dc709fe7cef2df53d7436f0ac0b0484 Author: NeilBrown Date: Fri Mar 4 17:20:13 2016 +1100 sunrpc/cache: drop reference when sunrpc_cache_pipe_upcall() detects a race commit a6ab1e8126d205238defbb55d23661a3a5c6a0d8 upstream. sunrpc_cache_pipe_upcall() can detect a race if CACHE_PENDING is no longer set. In this case it aborts the queuing of the upcall. However it has already taken a new counted reference on "h" and doesn't "put" it, even though it frees the data structure holding the reference. So let's delay the "cache_get" until we know we need it. Fixes: f9e1aedc6c79 ("sunrpc/cache: remove races with queuing an upcall.") Signed-off-by: NeilBrown Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit ac4b17cf608c96fd1eecee5b0ca9cbcc8765b9d8 Author: Caesar Wang Date: Mon Feb 15 15:33:28 2016 +0800 thermal: rockchip: fix a impossible condition caused by the warning commit 43b4eb9fe719b107c8e5d49d1edbff0c135a42cb upstream. As the Dan report the smatch check the thermal driver warning: drivers/thermal/rockchip_thermal.c:551 rockchip_configure_from_dt() warn: impossible condition '(thermal->tshut_temp > ((~0 >> 1))) => (s32min-s32max > s32max)' Although The shut_temp read from DT is u32,the temperature is currently represented as int not long in the thermal driver. Let's change to make shut_temp instead of the thermal->tshut_temp for the condition. Fixes: commit 437df2172e8d ("thermal: rockchip: consistently use int for temperatures") Reported-by: Dan Carpenter Signed-off-by: Caesar Wang Signed-off-by: Eduardo Valentin Signed-off-by: Greg Kroah-Hartman commit d8030202bcd9a9e12981cd0695a7c5ab40672ae7 Author: Al Viro Date: Thu Jan 14 18:13:49 2016 +0000 unbreak allmodconfig KCONFIG_ALLCONFIG=... commit 6b87b70c5339f30e3c5b32085e69625906513dc2 upstream. Prior to 3.13 make allmodconfig KCONFIG_ALLCONFIG=/dev/null used to be equivalent to make allmodconfig; these days it hardwires MODULES to n. In fact, any KCONFIG_ALLCONFIG that doesn't set MODULES explicitly is treated as if it set it to n. Regression had been introduced by commit cfa98f ("kconfig: do not override symbols already set"); what happens is that conf_read_simple() does sym_calc_value(modules_sym) on exit, which leaves SYMBOL_VALID set and has conf_set_all_new_symbols() skip modules_sym. It's pretty easy to fix - simply move that call of sym_calc_value() into the callers, except for the ones in KCONFIG_ALLCONFIG handling. Objections? Signed-off-by: Al Viro Fixes: cfa98f2e0ae9 ("kconfig: do not override symbols already set") Signed-off-by: Michal Marek Signed-off-by: Greg Kroah-Hartman commit b54368c9a0b7124a0a1a0470a034442135ab8d35 Author: Jiri Kosina Date: Tue Mar 15 11:28:54 2016 +0100 btrfs: cleaner_kthread() doesn't need explicit freeze commit 838fe1887765f4cc679febea60d87d2a06bd300e upstream. cleaner_kthread() is not marked freezable, and therefore calling try_to_freeze() in its context is a pointless no-op. In addition to that, as has been clearly demonstrated by 80ad623edd2d ("Revert "btrfs: clear PF_NOFREEZE in cleaner_kthread()"), it's perfectly valid / legal for cleaner_kthread() to stay scheduled out in an arbitrary place during suspend (in that particular example that was waiting for reading of extent pages), so there is no need to leave any traces of freezer in this kthread. Fixes: 80ad623edd2d ("Revert "btrfs: clear PF_NOFREEZE in cleaner_kthread()") Fixes: 696249132158 ("btrfs: clear PF_NOFREEZE in cleaner_kthread()") Signed-off-by: Jiri Kosina Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 151d2afffebe6d5a5a34d50f8447e395bb8fd8a4 Author: Kinglong Mee Date: Fri Jan 29 21:36:00 2016 +0800 btrfs: fix memory leak of fs_info in block group cache commit aa66b0bb08869d93492bd817d2eae694ca743a3d upstream. When starting up linux with btrfs filesystem, I got many memory leak messages by kmemleak as, unreferenced object 0xffff880066882000 (size 4096): comm "modprobe", pid 730, jiffies 4294690024 (age 196.599s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmemleak_alloc+0x4e/0xb0 [] kmem_cache_alloc_trace+0xea/0x1e0 [] btrfs_alloc_dummy_fs_info+0x6b/0x2a0 [btrfs] [] btrfs_alloc_dummy_block_group+0x5c/0x120 [btrfs] [] btrfs_test_free_space_cache+0x39/0xed0 [btrfs] [] trace_raw_output_xfs_attr_class+0x54/0xe0 [xfs] [] do_one_initcall+0xb2/0x1f0 [] do_init_module+0x5e/0x1e9 [] load_module+0x20a9/0x2690 [] SyS_finit_module+0xb9/0xf0 [] entry_SYSCALL_64_fastpath+0x12/0x76 [] 0xffffffffffffffff unreferenced object 0xffff8800573f8000 (size 10256): comm "modprobe", pid 730, jiffies 4294690185 (age 196.460s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmemleak_alloc+0x4e/0xb0 [] kmalloc_order+0x5e/0x70 [] kmalloc_order_trace+0x24/0x90 [] btrfs_alloc_dummy_fs_info+0x23/0x2a0 [btrfs] [] btrfs_alloc_dummy_block_group+0x5c/0x120 [btrfs] [] run_test+0xfd/0x320 [btrfs] [] btrfs_test_free_space_tree+0x94/0xee [btrfs] [] trace_raw_output_xfs_attr_class+0x8b/0xe0 [xfs] [] do_one_initcall+0xb2/0x1f0 [] do_init_module+0x5e/0x1e9 [] load_module+0x20a9/0x2690 [] SyS_finit_module+0xb9/0xf0 [] entry_SYSCALL_64_fastpath+0x12/0x76 [] 0xffffffffffffffff This patch lets btrfs using fs_info stored in btrfs_root for block group cache directly without allocating a new one. Fixes: d0bd456074 ("Btrfs: add fragment=* debug mount option") Signed-off-by: Kinglong Mee Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 9b60cc87007258e8cb2bdfe585ea1394e27036cf Author: Fabio Estevam Date: Mon Feb 22 09:01:53 2016 -0300 bus: imx-weim: Take the 'status' property value into account commit 33b96d2c9579213cf3f36d7b29841b1e464750c4 upstream. Currently we have an incorrect behaviour when multiple devices are present under the weim node. For example: &weim { ... status = "okay"; sram@0,0 { ... status = "okay"; }; mram@0,0 { ... status = "disabled"; }; }; In this case only the 'sram' device should be probed and not 'mram'. However what happens currently is that the status variable is ignored, causing the 'sram' device to be disabled and 'mram' to be enabled. Change the weim_parse_dt() function to use for_each_available_child_of_node()so that the devices marked with 'status = disabled' are not probed. Suggested-by: Wolfgang Netbal Signed-off-by: Fabio Estevam Reviewed-by: Sascha Hauer Acked-by: Shawn Guo Signed-off-by: Olof Johansson Signed-off-by: Greg Kroah-Hartman commit 61ceb3df1b20f7e7ef4f8d1f4c8cf7568ca1f206 Author: Franklin S Cooper Jr Date: Thu Mar 10 17:56:39 2016 -0600 ARM: dts: am437x: Fix GPMC dma properties commit 883cbc901b570625f54250a37b008d3635f1fbda upstream. This patch updates the GPMC's DT DMA property to reflect the updated eDMA bindings. Fixes: cce1ee000187 ("ARM: DTS: am437x: Use the new DT bindings for the eDMA3") Signed-off-by: Franklin S Cooper Jr Acked-by: Roger Quadros Acked-by: Peter Ujfalusi Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 4b065a2ea307a9550014aa35b57cc71e0d3d8c12 Author: Franklin S Cooper Jr Date: Thu Mar 10 17:56:38 2016 -0600 ARM: dts: am33xx: Fix GPMC dma properties commit a2abf904a6b594b93c0e73a36c98ecbaa7388463 upstream. This patch updates the GPMC's DT DMA property to reflect the updated eDMA bindings. Fixes: b5e509066074 ("ARM: DTS: am33xx: Use the new DT bindings for the eDMA3") Signed-off-by: Franklin S Cooper Jr Acked-by: Roger Quadros Acked-by: Peter Ujfalusi Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 05222d078e498ebf4de83a06d7a8536598e29863 Author: Robert Jarzmik Date: Sat Feb 13 00:49:20 2016 +0100 ARM: dts: pxa: fix dma engine node to pxa3xx-nand commit 07c6b2d01d351f0512ed7145625265e435ab3240 upstream. Since the switch from mmp_pdma to pxa_dma driver for pxa architectures, the pxa_dma requires 2 arguments, namely the requestor line and the requested priority. Fix the only left device node which was still passing only one argument, making the pxa3xx-nand driver misbehave in a device-tree configuration, ie. failing all data transfers. Fixes: c943646d1f49 ("ARM: dts: pxa: add dma engine node to pxa3xx-nand") Signed-off-by: Robert Jarzmik Signed-off-by: Greg Kroah-Hartman commit f520c0cf06a7078b2f5efa78344aff7dc8c303e6 Author: Lior Amsalem Date: Wed Feb 10 17:29:15 2016 +0100 ARM: dts: armada-375: use armada-370-sata for SATA commit b3a7f31eb7375633cd6a742f19488fc5a4208b36 upstream. The Armada 375 has the same SATA IP as Armada 370 and Armada XP, which requires the PHY speed to be set in the LP_PHY_CTL register for SATA hotplug to work. Therefore, this commit updates the compatible string used to describe the SATA IP in Armada 375 from marvell,orion-sata to marvell,armada-370-sata. Fixes: 4de59085091f753d08c8429d756b46756ab94665 ("ARM: mvebu: add Device Tree description of the Armada 375 SoC") Signed-off-by: Lior Amsalem Signed-off-by: Thomas Petazzoni Reviewed-by: Andrew Lunn Signed-off-by: Gregory CLEMENT Signed-off-by: Greg Kroah-Hartman commit 895c10d8316f0682a76feedefac06ec1275ece01 Author: Arnd Bergmann Date: Fri Jan 29 15:50:38 2016 +0100 ARM: EXYNOS: select THERMAL_OF commit dc7eb9d589e595954792cc192bcbb92932e5c2ff upstream. We cannot select a symbol that has disabled dependencies, so we get a warning if we ever enable EXYNOS_THERMAL without also turning on THERMAL_OF: warning: (ARCH_EXYNOS) selects EXYNOS_THERMAL which has unmet direct dependencies (THERMAL && (ARCH_EXYNOS || COMPILE_TEST) && THERMAL_OF) This adds another 'select' in the platform code to avoid that case. Alternatively, we could decide to not select EXYNOS_THERMAL here and instead make it a user option. Signed-off-by: Arnd Bergmann Fixes: f87e6bd3f740 ("thermal: exynos: Add the dependency of CONFIG_THERMAL_OF instead of CONFIG_OF") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit 858525d8941d19818fd0d2a997d9a0a5a762a121 Author: Arnd Bergmann Date: Sat Nov 28 23:56:47 2015 +0100 ARM: prima2: always enable reset controller commit ef2b1d777d643af227a22309d8b79898b90b123c upstream. The atlas7 clock controller driver registers a reset controller for itself, which causes a link error when the subsystem is disabled: drivers/built-in.o: In function `atlas7_clk_init': drivers/clk/sirf/clk-atlas7.c:1681: undefined reference to `reset_controller_register' As the clk driver does not have a Kconfig symbol for itself but it always built-in when the platform is enabled, we have to ensure that the reset controller subsystem is also built-in in this case. Signed-off-by: Arnd Bergmann Acked-by: Philipp Zabel Fixes: 301c5d29402e ("clk: sirf: add CSR atlas7 clk and reset support") Signed-off-by: Greg Kroah-Hartman commit ceb255575d01864a7442d9c3b759d116e81b7e55 Author: Pali Rohár Date: Fri Feb 19 10:35:39 2016 -0800 ARM: OMAP3: Add cpuidle parameters table for omap3430 commit 98f42221501353067251fbf11e732707dbb68ce3 upstream. Based on CPU type choose generic omap3 or omap3430 specific cpuidle parameters. Parameters for omap3430 were measured on Nokia N900 device and added by commit 5a1b1d3a9efa ("OMAP3: RX-51: Pass cpu idle parameters") which were later removed by commit 231900afba52 ("ARM: OMAP3: cpuidle - remove rx51 cpuidle parameters table") due to huge code complexity. This patch brings cpuidle parameters for omap3430 devices again, but uses simple condition based on CPU type. Fixes: 231900afba52 ("ARM: OMAP3: cpuidle - remove rx51 cpuidle parameters table") Signed-off-by: Pali Rohár Acked-by: Daniel Lezcano Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 06b7ad2899f5d2ff0e15141d42456c08dadbcc33 Author: Andres Freund Date: Wed Mar 30 21:02:45 2016 +0200 perf hists: Fix determination of a callchain node's childlessness commit 909890355507e92bdaf648e73870f6b5df606da8 upstream. The 4b3a3212233a ("perf hists browser: Support flat callchains") commit over-aggressively tried to optimize callchain_node__init_have_children(). That lead to --tui mode not allowing to expand call chain elements if a call chain element had only one parent. That's why --inverted callgraphs looked halfway sane, but plain ones didn't. Revert that individual optimization, it wasn't really related to the rest of the commit. Signed-off-by: Andres Freund Acked-by: Namhyung Kim Tested-by: Arnaldo Carvalho de Melo Cc: Peter Zijlstra Fixes: 4b3a3212233a ("perf hists browser: Support flat callchains") Link: http://lkml.kernel.org/r/20160330190245.GB13305@awork2.anarazel.de Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 1f861d0348fddb9c063af9c13e0c4c463fb211aa Author: Peter Zijlstra Date: Tue Mar 29 09:26:44 2016 +0200 perf/core: Fix time tracking bug with multiplexing commit 8fdc65391c6ad16461526a685f03262b3b01bfde upstream. Stephane reported that commit: 3cbaa5906967 ("perf: Fix ctx time tracking by introducing EVENT_TIME") introduced a regression wrt. time tracking, as easily observed by: > This patch introduce a bug in the time tracking of events when > multiplexing is used. > > The issue is easily reproducible with the following perf run: > > $ perf stat -a -C 0 -e branches,branches,branches,branches,branches,branches -I 1000 > 1.000730239 652,394 branches (66.41%) > 1.000730239 597,809 branches (66.41%) > 1.000730239 593,870 branches (66.63%) > 1.000730239 651,440 branches (67.03%) > 1.000730239 656,725 branches (66.96%) > 1.000730239 branches > > One branches event is shown as not having run. Yet, with > multiplexing, all events should run especially with a 1s (-I 1000) > interval. The delta for time_running comes out to 0. Yet, the event > has run because the kernel is actually multiplexing the events. The > problem is that the time tracking is the kernel and especially in > ctx_sched_out() is wrong now. > > The problem is that in case that the kernel enters ctx_sched_out() with the > following state: > ctx->is_active=0x7 event_type=0x1 > Call Trace: > [] dump_stack+0x63/0x82 > [] ctx_sched_out+0x2bc/0x2d0 > [] perf_mux_hrtimer_handler+0xf6/0x2c0 > [] ? __perf_install_in_context+0x130/0x130 > [] __hrtimer_run_queues+0xf8/0x2f0 > [] hrtimer_interrupt+0xb7/0x1d0 > [] local_apic_timer_interrupt+0x38/0x60 > [] smp_apic_timer_interrupt+0x3d/0x50 > [] apic_timer_interrupt+0x8c/0xa0 > > In that case, the test: > if (is_active & EVENT_TIME) > > will be false and the time will not be updated. Time must always be updated on > sched out. Fix this by always updating time if EVENT_TIME was set, as opposed to only updating time when EVENT_TIME changed. Reported-by: Stephane Eranian Tested-by: Stephane Eranian Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Vince Weaver Cc: kan.liang@intel.com Cc: namhyung@kernel.org Fixes: 3cbaa5906967 ("perf: Fix ctx time tracking by introducing EVENT_TIME") Link: http://lkml.kernel.org/r/20160329072644.GB3408@twins.programming.kicks-ass.net Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 4eca34694d9b4f0a8aeb41c153c73b7efed9eb17 Author: Alexander Shishkin Date: Mon Mar 21 10:02:42 2016 +0200 perf/core: Don't leak event in the syscall error path commit 201c2f85bd0bc13b712d9c0b3d11251b182e06ae upstream. In the error path, event_file not being NULL is used to determine whether the event itself still needs to be free'd, so fix it up to avoid leaking. Reported-by: Leon Yu Signed-off-by: Alexander Shishkin Signed-off-by: Peter Zijlstra (Intel) Cc: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Fixes: 130056275ade ("perf: Do not double free") Link: http://lkml.kernel.org/r/87twk06yxp.fsf@ashishki-desk.ger.corp.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit a3b5912c041dc973d7fa64e97f66bb7fafa7028a Author: Allen Hubbe Date: Mon Mar 21 04:53:14 2016 -0400 NTB: Remove _addr functions from ntb_hw_amd commit 4f1b50c3e3082b31c94cee2b897bd9f5d0f3e7c8 upstream. Kernel zero day testing warned about address space confusion. A virtual iomem address was used where a physical address is expected. The offending functions implement an optional part of the api, so they are removed. They can be added later, after testing. Fixes: a1b3695820aa490e58915d720a1438069813008b Signed-off-by: Allen Hubbe Acked-by: Xiangliang Yu Signed-off-by: Jon Mason Signed-off-by: Greg Kroah-Hartman commit 6fb42e94e2fa8fa201838418de960f7c27ea4fca Author: Arnd Bergmann Date: Tue Jan 26 10:31:45 2016 +0100 ntb: perf test: fix address space confusion commit 1985a88107b5330b2a911ad4d279e1bd7e4deb24 upstream. The ntb driver assigns between pointers an __iomem tokens, and also casts them to 64-bit integers, which results in compiler warnings on 32-bit systems: drivers/ntb/test/ntb_perf.c: In function 'perf_copy': drivers/ntb/test/ntb_perf.c:213:10: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] vbase = (u64)(u64 *)mw->vbase; ^ drivers/ntb/test/ntb_perf.c:214:14: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] dst_vaddr = (u64)(u64 *)dst; ^ This adds __iomem annotations where needed and changes the temporary variables to iomem pointers to avoid casting them to u64. I did not see the problem in linux-next earlier, but it show showed up in 4.5-rc1. Signed-off-by: Arnd Bergmann Acked-by: Dave Jiang Fixes: 8a7b6a778a85 ("ntb: ntb perf tool") Signed-off-by: Jon Mason Signed-off-by: Greg Kroah-Hartman commit 5749dc2d06e8e41e13a7ca91b7a2ac8073f6c766 Author: Borislav Petkov Date: Mon Mar 7 16:44:44 2016 -0300 perf stat: Document --detailed option commit f594bae08183fb6b57db55387794ece3e1edf6f6 upstream. I'm surprised this remained undocumented since at least 2011. And it is actually a very useful switch, as Steve and I came to realize recently. Add the text from 2cba3ffb9a9d ("perf stat: Add -d -d and -d -d -d options to show more CPU events") which added the incrementing aspect to -d. Tested-by: Arnaldo Carvalho de Melo Signed-off-by: Borislav Petkov Signed-off-by: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: David Ahern Cc: Davidlohr Bueso Cc: Jiri Olsa Cc: Mel Gorman Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Peter Zijlstra Cc: Steven Rostedt Cc: Thomas Gleixner Fixes: 2cba3ffb9a9d ("perf stat: Add -d -d and -d -d -d options to show more CPU events") Link: http://lkml.kernel.org/r/1457347294-32546-1-git-send-email-bp@alien8.de Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 9c8e6954b41f11e0ad819bd1423a4563878e90be Author: Marcin Ślusarz Date: Tue Jan 19 20:03:03 2016 +0100 perf tools: handle spaces in file names obtained from /proc/pid/maps commit 89fee59b504f86925894fcc9ba79d5c933842f93 upstream. Steam frequently puts game binaries in folders with spaces. Note: "(deleted)" markers are now treated as part of the file name. Signed-off-by: Marcin Ślusarz Acked-by: Namhyung Kim Fixes: 6064803313ba ("perf tools: Use sscanf for parsing /proc/pid/maps") Link: http://lkml.kernel.org/r/20160119190303.GA17579@marcin-Inspiron-7720 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 16ca33a5fbef3331427aa43b3d8572bc552675ad Author: Namhyung Kim Date: Thu Jan 28 00:40:54 2016 +0900 perf hists browser: Fix dump to show correct callchain style commit 0c841c6c16f320704f75970bbe6a9800c53e6cf5 upstream. The commit 8c430a348699 ("perf hists browser: Support folded callchains") missed to update hist_browser__dump() so it always shows graph-style callchains regardless of current setting. To fix that, factor out callchain printing code and rename the existing function which prints graph-style callchain. Signed-off-by: Namhyung Kim Cc: Andi Kleen Cc: David Ahern Cc: Frederic Weisbecker Cc: Jiri Olsa Cc: Peter Zijlstra Cc: Wang Nan Fixes: 8c430a348699 ("perf hists browser: Support folded callchains") Link: http://lkml.kernel.org/r/1453909257-26015-8-git-send-email-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 4067d2025ed4fb2f991c740cb476a9189548e905 Author: Namhyung Kim Date: Thu Jan 21 19:50:09 2016 -0300 perf hists browser: Only offer symbol scripting when a symbol is under the cursor commit c221acb0f970d3b80d72c812cda19c121acf5d52 upstream. When this feature was introduced a check was made if there was a resolved symbol under the cursor, it got lost in commit ea7cd5923309 ("perf hists browser: Split popup menu actions - part 2"), reinstate it. Signed-off-by: Namhyung Kim Tested-by: Arnaldo Carvalho de Melo Cc: Andi Kleen Cc: David Ahern Cc: Jiri Olsa , Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Wang Nan Fixes: ea7cd5923309 ("perf hists browser: Split popup menu actions - part 2") Link: http://lkml.kernel.org/r/1452960197-5323-9-git-send-email-namhyung@kernel.org [ Carved out from a larger patch ] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 8ac7efac123df915a503304d1a3270893987b258 Author: Ezequiel García Date: Fri Apr 1 18:29:23 2016 -0300 mtd: nand: Drop mtd.owner requirement in nand_scan commit 20c07a5bf094198ff2382aa5e7c930b3c9807792 upstream. Since commit 807f16d4db95 ("mtd: core: set some defaults when dev.parent is set"), it's now legal for drivers to call nand_scan and nand_scan_ident without setting mtd.owner. Drop the check and while at it remove the BUG() abuse. Fixes: 807f16d4db95 ("mtd: core: set some defaults when dev.parent is set") Signed-off-by: Ezequiel Garcia Acked-by: Boris Brezillon [Brian: editorial note - while commit 807f16d4db95 wasn't explicitly broken, some follow-up commits in the v4.4 release broke a few drivers, since they would hit this BUG() if they used nand_scan() and were built as modules] Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit 4517e2ffe5923b81d1ff8c7ee8a9ce4f347438c4 Author: Florian Fainelli Date: Wed Feb 24 16:07:23 2016 -0800 mtd: brcmnand: Fix v7.1 register offsets commit d267aefc54a28efc5bda7f009598dc83b5f98734 upstream. The BRCMNAND controller revision 7.1 is almost 100% compatible with the previous v6.0 register offset layout, except for the Correctable Error Reporting Threshold registers. Fix this by adding another table with the correct offsets for CORR_THRESHOLD and CORR_THRESHOLD_EXT. Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller") Signed-off-by: Florian Fainelli Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit 800a0b8a973b4262c92c228043cd17455cdf1a15 Author: Cyrille Pitchen Date: Wed Feb 3 14:26:46 2016 +0100 mtd: spi-nor: remove micron_quad_enable() commit 3b5394a3ccffbfa1d1d448d48742853a862822c4 upstream. This patch remove the micron_quad_enable() function which force the Quad SPI mode. However, once this mode is enabled, the Micron memory expect ALL commands to use the SPI 4-4-4 protocol. Hence a failure does occur when calling spi_nor_wait_till_ready() right after the update of the Enhanced Volatile Configuration Register (EVCR) in the micron_quad_enable() as the SPI controller driver is not aware about the protocol change. Since there is almost no performance increase using Fast Read 4-4-4 commands instead of Fast Read 1-1-4 commands, we rather keep on using the Extended SPI mode than enabling the Quad SPI mode. Let's take the example of the pretty standard use of 8 dummy cycles during Fast Read operations on 64KB erase sectors: Fast Read 1-1-4 requires 8 cycles for the command, then 24 cycles for the 3byte address followed by 8 dummy clock cycles and finally 65536*2 cycles for the read data; so 131112 clock cycles. On the other hand the Fast Read 4-4-4 would require 2 cycles for the command, then 6 cycles for the 3byte address followed by 8 dummy clock cycles and finally 65536*2 cycles for the read data. So 131088 clock cycles. The theorical bandwidth increase is 0.0%. Now using Fast Read operations on 512byte pages: Fast Read 1-1-4 needs 8+24+8+(512*2) = 1064 clock cycles whereas Fast Read 4-4-4 would requires 2+6+8+(512*2) = 1040 clock cycles. Hence the theorical bandwidth increase is 2.3%. Consecutive reads for non sequential pages is not a relevant use case so The Quad SPI mode is not worth it. mtd_speedtest seems to confirm these figures. Signed-off-by: Cyrille Pitchen Fixes: 548cd3ab54da ("mtd: spi-nor: Add quad I/O support for Micron SPI NOR") Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit af0f85c30481457062947f90179a56d1e9946ee5 Author: Kunihiko Hayashi Date: Fri Apr 1 19:32:43 2016 +0900 bus: uniphier-system-bus: fix condition of overlap check commit 3de7beebddf8d56dcaa17b41c723d602dd0c513c upstream. This patch fixes condition whether the specified address ranges overlap each other. Fixes: 4b7f48d395a7 ("bus: uniphier-system-bus: add UniPhier System Bus driver") Signed-off-by: Kunihiko Hayashi Acked-by: Masahiro Yamada Signed-off-by: Olof Johansson Signed-off-by: Greg Kroah-Hartman commit 091391b800a32dccd9a9138827820a3f8c83f96a Author: Chao Yu Date: Sun Feb 14 18:56:55 2016 +0800 f2fs crypto: make sure the encryption info is initialized on opendir(2) commit ed3360abbc0412f32c398e1c58887d74f3d04225 upstream. This patch syncs f2fs with commit 6bc445e0ff44 ("ext4 crypto: make sure the encryption info is initialized on opendir(2)") from ext4. Signed-off-by: Theodore Ts'o Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 629a4956e0ea66c5ff4d1bc5bbb2d5deca4e3908 Author: Chao Yu Date: Sun Feb 14 18:58:35 2016 +0800 f2fs crypto: handle unexpected lack of encryption keys commit ae1086686487f13130937918ca91d920c1daafcb upstream. This patch syncs f2fs with commit abdd438b26b4 ("ext4 crypto: handle unexpected lack of encryption keys") from ext4. Fix up attempts by users to try to write to a file when they don't have access to the encryption key. Signed-off-by: Theodore Ts'o Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 73b5a1883361c3a0bd328ba8fa1348e09594229d Author: Jaegeuk Kim Date: Mon Jan 25 14:31:58 2016 -0800 f2fs: don't need to call set_page_dirty for io error commit e3ef18762f5757d3fb86f75ca59315db6d17d719 upstream. If end_io gets an error, we don't need to set the page as dirty, since we already set f2fs_stop_checkpoint which will not flush any data. This will resolve the following warning. ====================================================== [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ] 4.4.0+ #9 Tainted: G O ------------------------------------------------------ xfs_io/26773 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: (&(&sbi->inode_lock[i])->rlock){+.+...}, at: [] update_dirty_page+0x6f/0xd0 [f2fs] and this task is already holding: (&(&q->__queue_lock)->rlock){-.-.-.}, at: [] blk_queue_bio+0x422/0x490 which would create a new lock dependency: (&(&q->__queue_lock)->rlock){-.-.-.} -> (&(&sbi->inode_lock[i])->rlock){+.+...} Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit cb3358c514b36f56f4dc52123f30c0e63a8af719 Author: Jaegeuk Kim Date: Sat Jan 23 13:35:18 2016 -0800 f2fs: do f2fs_balance_fs when block is allocated commit 3c082b7b5b28be606ed9ef11e4741df7c722c92e upstream. We should consider data block allocation to trigger f2fs_balance_fs. Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit baf12a6b246fb5a958ff16e80e3c1e7a4178c872 Author: Jaegeuk Kim Date: Tue Apr 12 16:05:36 2016 -0700 ext4/fscrypto: avoid RCU lookup in d_revalidate commit 03a8bb0e53d9562276045bdfcf2b5de2e4cff5a1 upstream. As Al pointed, d_revalidate should return RCU lookup before using d_inode. This was originally introduced by: commit 34286d666230 ("fs: rcu-walk aware d_revalidate method"). Reported-by: Al Viro Signed-off-by: Jaegeuk Kim Cc: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 3034c3231ca4db86e03c66861f7e599b14154732 Author: Jaegeuk Kim Date: Sun Mar 20 15:33:20 2016 -0700 f2fs: cover large section in sanity check of super commit fd694733d523df1e0a583cf5c4c08e41d7bf9fa3 upstream. This patch fixes the bug which does not cover a large section case when checking the sanity of superblock. If f2fs detects misalignment, it will fix the superblock during the mount time, so it doesn't need to trigger fsck.f2fs further. Reported-by: Matthias Prager Reported-by: David Gnedt Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 9a0ae8666d30d24ced8c71a7829ef119783e6610 Author: Shawn Lin Date: Wed Feb 17 08:59:01 2016 +0800 f2fs: slightly reorganize read_raw_super_block commit 2b39e9072d79ab2525100413f3f7a0b8a3e15873 upstream. read_raw_super_block was introduced to help find the first valid superblock. Commit da554e48caab ("f2fs: recovering broken superblock during mount") changed the behaviour to read both of them and check whether need the recovery flag or not. So the comment before this function isn't consistent with what it actually does. Also, the origin code use two tags to round the err cases, which isn't so readable. So this patch amend the comment and slightly reorganize it. Signed-off-by: Shawn Lin Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 5ca2636ec33c4857eae6061f4b97e52d0688b1f3 Author: Jaegeuk Kim Date: Wed Mar 30 13:13:16 2016 -0700 f2fs crypto: fix corrupted symlink in encrypted case commit c90e09f7fb498f81cd4e8bb6460d3a26ccebeca3 upstream. In the encrypted symlink case, we should check its corrupted symname after decrypting it. Otherwise, we can report -ENOENT incorrectly, if encrypted symname starts with '\0'. Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit b44d9268b28264da0b0777e3ec4d4d70bc91d09d Author: Eryu Guan Date: Sat Mar 12 21:40:32 2016 -0500 ext4: fix NULL pointer dereference in ext4_mark_inode_dirty() commit 5e1021f2b6dff1a86a468a1424d59faae2bc63c1 upstream. ext4_reserve_inode_write() in ext4_mark_inode_dirty() could fail on error (e.g. EIO) and iloc.bh can be NULL in this case. But the error is ignored in the following "if" condition and ext4_expand_extra_isize() might be called with NULL iloc.bh set, which triggers NULL pointer dereference. This is uncovered by commit 8b4953e13f4c ("ext4: reserve code points for the project quota feature"), which enlarges the ext4_inode size, and run the following script on new kernel but with old mke2fs: #/bin/bash mnt=/mnt/ext4 devname=ext4-error dev=/dev/mapper/$devname fsimg=/home/fs.img trap cleanup 0 1 2 3 9 15 cleanup() { umount $mnt >/dev/null 2>&1 dmsetup remove $devname losetup -d $backend_dev rm -f $fsimg exit 0 } rm -f $fsimg fallocate -l 1g $fsimg backend_dev=`losetup -f --show $fsimg` devsize=`blockdev --getsz $backend_dev` good_tab="0 $devsize linear $backend_dev 0" error_tab="0 $devsize error $backend_dev 0" dmsetup create $devname --table "$good_tab" mkfs -t ext4 $dev mount -t ext4 -o errors=continue,strictatime $dev $mnt dmsetup load $devname --table "$error_tab" && dmsetup resume $devname echo 3 > /proc/sys/vm/drop_caches ls -l $mnt exit 0 [ Patch changed to simplify the function a tiny bit. -- Ted ] Signed-off-by: Eryu Guan Signed-off-by: Theodore Ts'o Cc: Jan Kara Signed-off-by: Greg Kroah-Hartman commit d62a28a60562a8ba82e67e13c268245f37e796cb Author: Karol Herbst Date: Thu Mar 3 02:03:11 2016 +0100 x86/mm/kmmio: Fix mmiotrace for hugepages commit cfa52c0cfa4d727aa3e457bf29aeff296c528a08 upstream. Because Linux might use bigger pages than the 4K pages to handle those mmio ioremaps, the kmmio code shouldn't rely on the pade id as it currently does. Using the memory address instead of the page id lets us look up how big the page is and what its base address is, so that we won't get a page fault within the same page twice anymore. Tested-by: Pierre Moreau Signed-off-by: Karol Herbst Cc: Andrew Morton Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Luis R. Rodriguez Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Toshi Kani Cc: linux-mm@kvack.org Cc: linux-x86_64@vger.kernel.org Cc: nouveau@lists.freedesktop.org Cc: pq@iki.fi Cc: rostedt@goodmis.org Link: http://lkml.kernel.org/r/1456966991-6861-1-git-send-email-nouveau@karolherbst.de Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 17ad226851d1ee8303543568940774233de3fb18 Author: Chris Phlipot Date: Tue Mar 8 21:11:54 2016 -0800 perf tools: Fix perf script python database export crash commit 616df645d7238e45d3b369933a30fee4e4e305e2 upstream. Remove the union in evsel so that the database id and priv pointer can be used simultainously without conflicting and crashing. Detailed Description for the fixed bug follows: perf script crashes with a segmentation fault on user space tool version 4.5.rc7.ge2857b when using the python database export API. It works properly in 4.4 and prior versions. the crash fist appeared in: cfc8874a4859 ("perf script: Process cpu/threads maps") How to reproduce the bug: Remove any temporary files left over from a previous crash (if you have already attemped to reproduce the bug): $ rm -r test_db-perf-data $ dropdb test_db $ perf record timeout 1 yes >/dev/null $ perf script -s scripts/python/export-to-postgresql.py test_db Stack Trace: Program received signal SIGSEGV, Segmentation fault. __GI___libc_free (mem=0x1) at malloc.c:2929 2929 malloc.c: No such file or directory. (gdb) bt at util/stat.c:122 argv=, prefix=) at builtin-script.c:2231 argc=argc@entry=4, argv=argv@entry=0x7fffffffdf70) at perf.c:390 at perf.c:451 Signed-off-by: Chris Phlipot Acked-by: Jiri Olsa Cc: Adrian Hunter Cc: Peter Zijlstra Fixes: cfc8874a4859 ("perf script: Process cpu/threads maps") Link: http://lkml.kernel.org/r/1457500314-8912-1-git-send-email-cphlipot0@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 15d3a9bd950de06ed4923e5a2e5d4902708b8e9b Author: Arnaldo Carvalho de Melo Date: Wed Feb 17 10:57:19 2016 -0300 perf evlist: Reference count the cpu and thread maps at set_maps() commit a55e5663761366fb883f6f25375dd68bc958b9db upstream. We were dropping the reference we possibly held but not obtaining one for the new maps, which we will drop at perf_evlist__delete(), fix it. This was caught by Steven Noonan in some of the machines which would produce this output when caught by glibc debug mechanisms: $ sudo perf test 21 21: Test object code reading :*** Error in `perf': corrupted double-linked list: 0x00000000023ffcd0 *** ======= Backtrace: ========= /usr/lib/libc.so.6(+0x72055)[0x7f25be0f3055] /usr/lib/libc.so.6(+0x779b6)[0x7f25be0f89b6] /usr/lib/libc.so.6(+0x7a0ed)[0x7f25be0fb0ed] /usr/lib/libc.so.6(__libc_calloc+0xba)[0x7f25be0fceda] perf(parse_events_lex_init_extra+0x38)[0x4cfff8] perf(parse_events+0x55)[0x4a0615] perf(perf_evlist__config+0xcf)[0x4eeb2f] perf[0x479f82] perf(test__code_reading+0x1e)[0x47ad4e] perf(cmd_test+0x5dd)[0x46452d] perf[0x47f4e3] perf(main+0x603)[0x42c723] /usr/lib/libc.so.6(__libc_start_main+0xf0)[0x7f25be0a1610] perf(_start+0x29)[0x42c859] Further investigation using valgrind led to the reference count imbalance fixed in this patch. Reported-and-Tested-by: Steven Noonan Report-Link: http://lkml.kernel.org/r/CAKbGBLjC2Dx5vshxyGmQkcD+VwiAQLbHoXA9i7kvRB2-2opHZQ@mail.gmail.com Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Fixes: f30a79b012e5 ("perf tools: Add reference counting for cpu_map object") Link: http://lkml.kernel.org/n/tip-j0u1bdhr47sa511sgg76kb8h@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 273c0c81e890bbfaa980f48587dacf0f5258bbc2 Author: Michael Hennerich Date: Mon Feb 22 10:20:24 2016 +0100 drivers/misc/ad525x_dpot: AD5274 fix RDAC read back errors commit f3df53e4d70b5736368a8fe8aa1bb70c1cb1f577 upstream. Fix RDAC read back errors caused by a typo. Value must shift by 2. Fixes: a4bd394956f2 ("drivers/misc/ad525x_dpot.c: new features") Signed-off-by: Michael Hennerich Signed-off-by: Greg Kroah-Hartman commit 28d3c4c686d01560d0601f2b2369ed8552ab47e6 Author: Krzysztof Kozlowski Date: Thu Feb 4 09:26:35 2016 +0900 rtc: max77686: Properly handle regmap_irq_get_virq() error code commit fb166ba1d7f0a662f7332f4ff660a0d6f4d76915 upstream. The regmap_irq_get_virq() can return 0 or -EINVAL in error conditions but driver checked only for value of 0. This could lead to a cast of -EINVAL to an unsigned int used as a interrupt number for devm_request_threaded_irq(). Although this is not yet fatal (devm_request_threaded_irq() will just fail with -EINVAL) but might be a misleading when diagnosing errors. Signed-off-by: Krzysztof Kozlowski Fixes: 6f1c1e71d933 ("mfd: max77686: Convert to use regmap_irq") Reviewed-by: Javier Martinez Canillas Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 2b921caade42a6d19391ba56388f5bdcefc1df55 Author: Alexandre Belloni Date: Thu Jan 21 13:24:21 2016 +0100 rtc: rx8025: remove rv8803 id commit aaa3cee5deffa28415a6e1852c5afae0f5d210e2 upstream. The rv8803 has its own driver that should be used. Remove its id from the rx8025 driver. Fixes: b1f9d790b59dc04f8813a49a92ddd8651770ffee Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 3f59a79af574f44c1eb1ce51d59c171843dd80ec Author: Dan Carpenter Date: Wed Mar 2 13:07:45 2016 +0300 rtc: ds1685: passing bogus values to irq_restore commit 8c09b9fdecab1f4a289f07b46e2ad174b6641928 upstream. We call spin_lock_irqrestore with "flags" set to zero instead of to the value from spin_lock_irqsave(). Fixes: aaaf5fbf56f1 ('rtc: add driver for DS1685 family of real time clocks') Signed-off-by: Dan Carpenter Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit ea592ddac0b480ad4b7dc49dccd5e4f0a1f71fbe Author: Geert Uytterhoeven Date: Tue Mar 1 09:50:01 2016 +0100 rtc: vr41xx: Wire up alarm_irq_enable commit a25f4a95ec3cded34c1250364eba704c5e4fdac4 upstream. drivers/rtc/rtc-vr41xx.c:229: warning: ‘vr41xx_rtc_alarm_irq_enable’ defined but not used Apparently the conversion to alarm_irq_enable forgot to wire up the callback. Fixes: 16380c153a69c378 ("RTC: Convert rtc drivers to use the alarm_irq_enable method") Signed-off-by: Geert Uytterhoeven Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 5aa6c329edae23ee8dd2985f0c8ff355656437d2 Author: Alexander Kochetkov Date: Sun Mar 6 12:43:57 2016 +0300 rtc: hym8563: fix invalid year calculation commit d5861262210067fc01b2fb4f7af2fd85a3453f15 upstream. Year field must be in BCD format, according to hym8563 datasheet. Due to the bug year 2016 became 2010. Fixes: dcaf03849352 ("rtc: add hym8563 rtc-driver") Signed-off-by: Alexander Kochetkov Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 074b8d8788e1ffa41e1517e79f7fc192c2966f02 Author: Jon Hunter Date: Fri Mar 4 10:55:14 2016 +0000 PM / Domains: Fix removal of a subdomain commit beda5fc1ff9b527059290a97b672d2ee0eb7b92f upstream. Commit 30e7a65b3fdb (PM / Domains: Ensure subdomain is not in use before removing) added a test to ensure that a subdomain is not a master to another subdomain or if any devices are using the subdomain before removing. This change incorrectly used the "slave_links" list to determine if the subdomain is a master to another subdomain, where it should have been using the "master_links" list instead. The "slave_links" list will never be empty for a subdomain and so a subdomain can never be removed. Fix this by testing if the "master_links" list is empty instead. Fixes: 30e7a65b3fdb (PM / Domains: Ensure subdomain is not in use before removing) Signed-off-by: Jon Hunter Reviewed-by: Thierry Reding Acked-by: Ulf Hansson Acked-by: Kevin Hilman Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 0ea539773e0169e14a4209d48fcb1a6a67519d6d Author: Viresh Kumar Date: Mon Feb 15 10:21:53 2016 +0530 PM / OPP: Initialize u_volt_min/max to a valid value commit c88c395f4a6485f23f81e385c79945d68bcd5c5d upstream. We kept u_volt_min/max initialized to 0, when only the target voltage is present in DT, instead of the target/min/max triplet. This didn't go well with the regulator framework, as on few calls the min voltage was set to target and max was set to 0 and so resulted in a kernel crash like below: kernel BUG at ../drivers/regulator/core.c:216! [] (regulator_check_voltage) from [] (regulator_set_voltage_unlocked+0x58/0x230) [] (regulator_set_voltage_unlocked) from [] (regulator_set_voltage+0x28/0x54) [] (regulator_set_voltage) from [] (_set_opp_voltage+0x30/0x98) [] (_set_opp_voltage) from [] (dev_pm_opp_set_rate+0xf0/0x28c) [] (dev_pm_opp_set_rate) from [] (__cpufreq_driver_target+0x184/0x2b4) [] (__cpufreq_driver_target) from [] (dbs_check_cpu+0x1b0/0x1f4) [] (dbs_check_cpu) from [] (cpufreq_governor_dbs+0x324/0x5c4) [] (cpufreq_governor_dbs) from [] (__cpufreq_governor+0xe4/0x1ec) [] (__cpufreq_governor) from [] (cpufreq_init_policy+0x64/0x8c) [] (cpufreq_init_policy) from [] (cpufreq_online+0x2fc/0x708) [] (cpufreq_online) from [] (subsys_interface_register+0x94/0xd8) [] (subsys_interface_register) from [] (cpufreq_register_driver+0x14c/0x19c) [] (cpufreq_register_driver) from [] (dt_cpufreq_probe+0x70/0xec) [] (dt_cpufreq_probe) from [] (platform_drv_probe+0x4c/0xb0) [] (platform_drv_probe) from [] (driver_probe_device+0x214/0x2c0) [] (driver_probe_device) from [] (__driver_attach+0x8c/0x90) [] (__driver_attach) from [] (bus_for_each_dev+0x68/0x9c) [] (bus_for_each_dev) from [] (bus_add_driver+0x1a0/0x218) [] (bus_add_driver) from [] (driver_register+0x78/0xf8) [] (driver_register) from [] (do_one_initcall+0x90/0x1d8) [] (do_one_initcall) from [] (kernel_init_freeable+0x15c/0x1fc) [] (kernel_init_freeable) from [] (kernel_init+0x8/0xf0) [] (kernel_init) from [] (ret_from_fork+0x14/0x3c) Code: e1550004 baffffeb e3a00000 e8bd8070 (e7f001f2) Fix that by initializing u_volt_min/max to the target voltage in such cases. Reported-and-tested-by: Krzysztof Kozlowski Fixes: 274659029c9d (PM / OPP: Add support to parse "operating-points-v2" bindings) Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 123fd77a38c38855fc79b36872bede96efbd01f9 Author: Dan Carpenter Date: Mon Oct 19 14:19:01 2015 +0300 misc: mic/scif: fix wrap around tests commit 7b64dbf849abdd7e769820e25120758f956a7f13 upstream. Signed integer overflow is undefined. Also I added a check for "(offset < 0)" in scif_unregister() because that makes it match the other conditions and because I didn't want to subtract a negative. Fixes: ba612aa8b487 ('misc: mic: SCIF memory registration and unregistration') Signed-off-by: Dan Carpenter Signed-off-by: Greg Kroah-Hartman commit 072a47ca52eacb5d99447b01482eee91b002a44a Author: Ben Hutchings Date: Mon Dec 14 14:29:23 2015 +0000 misc/bmp085: Enable building as a module commit 50e6315dba721cbc24ccd6d7b299f1782f210a98 upstream. Commit 985087dbcb02 'misc: add support for bmp18x chips to the bmp085 driver' changed the BMP085 config symbol to a boolean. I see no reason why the shared code cannot be built as a module, so change it back to tristate. Fixes: 985087dbcb02 ("misc: add support for bmp18x chips to the bmp085 driver") Cc: Eric Andersson Signed-off-by: Ben Hutchings Acked-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 0cfe76f7852f2f10477da2d2380383d8dcee54fb Author: Michal Marek Date: Wed Feb 17 14:46:59 2016 +0100 lib/mpi: Endianness fix commit 3ee0cb5fb5eea2110db1b5cb7f67029b7be8a376 upstream. The limbs are integers in the host endianness, so we can't simply iterate over the individual bytes. The current code happens to work on little-endian, because the order of the limbs in the MPI array is the same as the order of the bytes in each limb, but it breaks on big-endian. Fixes: 0f74fbf77d45 ("MPI: Fix mpi_read_buffer") Signed-off-by: Michal Marek Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 1e2d4433b4db1961bd9f881209ed782ebf267a1c Author: Sushaanth Srirangapathi Date: Mon Feb 29 18:42:19 2016 +0530 fbdev: da8xx-fb: fix videomodes of lcd panels commit 713fced8d10fa1c759c8fb6bf9aaa681bae68cad upstream. Commit 028cd86b794f4a ("video: da8xx-fb: fix the polarities of the hsync/vsync pulse") fixes polarities of HSYNC/VSYNC pulse but forgot to update known_lcd_panels[] which had sync values according to old logic. This breaks LCD at least on DA850 EVM. This patch fixes this issue and I have tested this for panel "Sharp_LK043T1DG01" using DA850 EVM board. Fixes: 028cd86b794f4a ("video: da8xx-fb: fix the polarities of the hsync/vsync pulse") Signed-off-by: Sushaanth Srirangapathi Signed-off-by: Tomi Valkeinen Signed-off-by: Greg Kroah-Hartman commit 452370efca2b1145bdde4388c9fa51bbc263c41d Author: Arnd Bergmann Date: Wed Jan 27 16:57:23 2016 +0100 scsi_dh: force modular build if SCSI is a module commit 0c994c03c926d26ce48e6bbabbbe60366044fcae upstream. When the scsi_dh core was moved into the scsi core module, CONFIG_SCSI_DH became a 'bool' option, and now anything depending on it can be built-in even when CONFIG_SCSI=m. This of course cannot link successfully: drivers/scsi/built-in.o: In function `rdac_init': scsi_dh_alua.c:(.init.text+0x14): undefined reference to `scsi_register_device_handler' scsi_dh_alua.c:(.init.text+0x64): undefined reference to `scsi_unregister_device_handler' drivers/scsi/built-in.o: In function `alua_init': scsi_dh_alua.c:(.init.text+0xb0): undefined reference to `scsi_register_device_handler' As a workaround, this adds an extra dependency on CONFIG_SCSI, so Kconfig can figure out whether built-in is allowed or not. Signed-off-by: Arnd Bergmann Fixes: 086b91d052eb ("scsi_dh: integrate into the core SCSI code") Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 473accd48ab6dea0dbce266ca1981949a6345f42 Author: Arnd Bergmann Date: Tue Mar 15 14:53:29 2016 -0700 paride: make 'verbose' parameter an 'int' again commit dec63a4dec2d6d01346fd5d96062e67c0636852b upstream. gcc-6.0 found an ancient bug in the paride driver, which had a "module_param(verbose, bool, 0);" since before 2.6.12, but actually uses it to accept '0', '1' or '2' as arguments: drivers/block/paride/pd.c: In function 'pd_init_dev_parms': drivers/block/paride/pd.c:298:29: warning: comparison of constant '1' with boolean expression is always false [-Wbool-compare] #define DBMSG(msg) ((verbose>1)?(msg):NULL) In 2012, Rusty did a cleanup patch that also changed the type of the variable to 'bool', which introduced what is now a gcc warning. This changes the type back to 'int' and adapts the module_param() line instead, so it should work as documented in case anyone ever cares about running the ancient driver with debugging. Fixes: 90ab5ee94171 ("module_param: make bool parameters really bool (drivers & misc)") Signed-off-by: Arnd Bergmann Rusty Russell Cc: Tim Waugh Cc: Sudip Mukherjee Cc: Jens Axboe Cc: Greg Kroah-Hartman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5c203e1ccb2845a9e42504ed1186e2132c967840 Author: Arnd Bergmann Date: Tue Feb 16 15:53:11 2016 +0100 regulator: s5m8767: fix get_register() error handling commit e07ff9434167981c993a26d2edbbcb8e13801dbb upstream. The s5m8767_pmic_probe() function calls s5m8767_get_register() to read data without checking the return code, which produces a compile-time warning when that data is accessed: drivers/regulator/s5m8767.c: In function 's5m8767_pmic_probe': drivers/regulator/s5m8767.c:924:7: error: 'enable_reg' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/regulator/s5m8767.c:944:30: error: 'enable_val' may be used uninitialized in this function [-Werror=maybe-uninitialized] This changes the s5m8767_get_register() function to return a -EINVAL not just for an invalid register number but also for an invalid regulator number, as both would result in returning uninitialized data. The s5m8767_pmic_probe() function is then changed accordingly to fail on a read error, as all the other callers of s5m8767_get_register() already do. In practice this probably cannot happen, as we don't call s5m8767_get_register() with invalid arguments, but the gcc warning seems valid in principle, in terms writing safe error checking. Signed-off-by: Arnd Bergmann Fixes: 9c4c60554acf ("regulator: s5m8767: Convert to use regulator_[enable|disable|is_enabled]_regmap") Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2edbfeb22317fbaf704b36246fe1549ba42f0717 Author: Vladimir Zapolskiy Date: Wed Mar 9 03:21:40 2016 +0200 irqchip/mxs: Fix error check of of_io_request_and_map() commit edf8fcdc6b254236be005851af35ea5e826e7e09 upstream. The of_io_request_and_map() returns a valid pointer in iomem region or ERR_PTR(), check for NULL always fails and may cause a NULL pointer dereference on error path. Fixes: 25e34b44313b ("irqchip/mxs: Prepare driver for hardware with different offsets") Signed-off-by: Vladimir Zapolskiy Cc: Jason Cooper Cc: Marc Zyngier Cc: Oleksij Rempel Cc: Sascha Hauer Cc: Shawn Guo Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/1457486500-10237-1-git-send-email-vz@mleia.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit a39fc07f3fe875d2c834fa27cf0e2e6e1b3cd342 Author: Vladimir Zapolskiy Date: Wed Mar 9 03:21:29 2016 +0200 irqchip/sunxi-nmi: Fix error check of of_io_request_and_map() commit cfe199afefe6201e998ddc07102fc1fdb55f196c upstream. The of_io_request_and_map() returns a valid pointer in iomem region or ERR_PTR(), check for NULL always fails and may cause a NULL pointer dereference on error path. Fixes: 0e841b04c829 ("irqchip/sunxi-nmi: Switch to of_io_request_and_map() from of_iomap()") Signed-off-by: Vladimir Zapolskiy Cc: Jason Cooper Cc: Marc Zyngier Cc: Chen-Yu Tsai Cc: Maxime Ripard Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/1457486489-10189-1-git-send-email-vz@mleia.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit a1774b6ba1cf515c49186aedaf2b2372843df7a7 Author: Huibin Hong Date: Wed Feb 24 18:00:04 2016 +0800 spi/rockchip: Make sure spi clk is on in rockchip_spi_set_cs commit b920cc3191d7612f26f36ee494e05b5ffd9044c0 upstream. Rockchip_spi_set_cs could be called by spi_setup, but spi_setup may be called by device driver after runtime suspend. Then the spi clock is closed, rockchip_spi_set_cs may access the spi registers, which causes cpu block in some socs. Fixes: 64e36824b32 ("spi/rockchip: add driver for Rockchip RK3xxx") Signed-off-by: Huibin Hong Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 7397a681b4ad34d12d040ae6b267fd13e57ee72c Author: Peter Zijlstra Date: Mon Feb 1 15:11:28 2016 +0100 locking/mcs: Fix mcs_spin_lock() ordering commit 920c720aa5aa3900a7f1689228fdfc2580a91e7e upstream. Similar to commit b4b29f94856a ("locking/osq: Fix ordering of node initialisation in osq_lock") the use of xchg_acquire() is fundamentally broken with MCS like constructs. Furthermore, it turns out we rely on the global transitivity of this operation because the unlock path observes the pointer with a READ_ONCE(), not an smp_load_acquire(). This is non-critical because the MCS code isn't actually used and mostly serves as documentation, a stepping stone to the more complex things we've build on top of the idea. Reported-by: Andrea Parri Signed-off-by: Peter Zijlstra (Intel) Cc: Andrew Morton Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Fixes: 3552a07a9c4a ("locking/mcs: Use acquire/release semantics") Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 4bca37b600a44859893b45ca87001b808907fff7 Author: Ignat Korchagin Date: Thu Mar 17 18:00:29 2016 +0000 USB: usbip: fix potential out-of-bounds write commit b348d7dddb6c4fbfc810b7a0626e8ec9e29f7cbb upstream. Fix potential out-of-bounds write to urb->transfer_buffer usbip handles network communication directly in the kernel. When receiving a packet from its peer, usbip code parses headers according to protocol. As part of this parsing urb->actual_length is filled. Since the input for urb->actual_length comes from the network, it should be treated as untrusted. Any entity controlling the network may put any value in the input and the preallocated urb->transfer_buffer may not be large enough to hold the data. Thus, the malicious entity is able to write arbitrary data to kernel memory. Signed-off-by: Ignat Korchagin Cc: Sasha Levin Signed-off-by: Paul Gortmaker Signed-off-by: Greg Kroah-Hartman commit 1cf34a85e4a8a268a27683387caf0372e0253b99 Author: Minchan Kim Date: Thu Apr 28 16:18:44 2016 -0700 mm/hwpoison: fix wrong num_poisoned_pages accounting commit d7e69488bd04de165667f6bc741c1c0ec6042ab9 upstream. Currently, migration code increses num_poisoned_pages on *failed* migration page as well as successfully migrated one at the trial of memory-failure. It will make the stat wrong. As well, it marks the page as PG_HWPoison even if the migration trial failed. It would mean we cannot recover the corrupted page using memory-failure facility. This patches fixes it. Signed-off-by: Minchan Kim Reported-by: Vlastimil Babka Acked-by: Naoya Horiguchi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 93de90e5d049a0f790d0b7f4b29c9d4c50a09e59 Author: Minchan Kim Date: Thu Apr 28 16:18:38 2016 -0700 mm: vmscan: reclaim highmem zone if buffer_heads is over limit commit 7bf52fb891b64b8d61caf0b82060adb9db761aec upstream. We have been reclaimed highmem zone if buffer_heads is over limit but commit 6b4f7799c6a5 ("mm: vmscan: invoke slab shrinkers from shrink_zone()") changed the behavior so it doesn't reclaim highmem zone although buffer_heads is over the limit. This patch restores the logic. Fixes: 6b4f7799c6a5 ("mm: vmscan: invoke slab shrinkers from shrink_zone()") Signed-off-by: Minchan Kim Cc: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 42bbd053fcb84539dc54e450e58ffa57ed7b0ebf Author: Gerald Schaefer Date: Thu Apr 28 16:18:35 2016 -0700 numa: fix /proc//numa_maps for THP commit 28093f9f34cedeaea0f481c58446d9dac6dd620f upstream. In gather_pte_stats() a THP pmd is cast into a pte, which is wrong because the layouts may differ depending on the architecture. On s390 this will lead to inaccurate numa_maps accounting in /proc because of misguided pte_present() and pte_dirty() checks on the fake pte. On other architectures pte_present() and pte_dirty() may work by chance, but there may be an issue with direct-access (dax) mappings w/o underlying struct pages when HAVE_PTE_SPECIAL is set and THP is available. In vm_normal_page() the fake pte will be checked with pte_special() and because there is no "special" bit in a pmd, this will always return false and the VM_PFNMAP | VM_MIXEDMAP checking will be skipped. On dax mappings w/o struct pages, an invalid struct page pointer would then be returned that can crash the kernel. This patch fixes the numa_maps THP handling by introducing new "_pmd" variants of the can_gather_numa_stats() and vm_normal_page() functions. Signed-off-by: Gerald Schaefer Cc: Naoya Horiguchi Cc: "Kirill A . Shutemov" Cc: Konstantin Khlebnikov Cc: Michal Hocko Cc: Vlastimil Babka Cc: Jerome Marchand Cc: Johannes Weiner Cc: Dave Hansen Cc: Mel Gorman Cc: Dan Williams Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: Michael Holzheu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d0f803397cf872c71913bb493432e410fd51ead6 Author: Konstantin Khlebnikov Date: Thu Apr 28 16:18:32 2016 -0700 mm/huge_memory: replace VM_NO_THP VM_BUG_ON with actual VMA check commit 3486b85a29c1741db99d0c522211c82d2b7a56d0 upstream. Khugepaged detects own VMAs by checking vm_file and vm_ops but this way it cannot distinguish private /dev/zero mappings from other special mappings like /dev/hpet which has no vm_ops and popultes PTEs in mmap. This fixes false-positive VM_BUG_ON and prevents installing THP where they are not expected. Link: http://lkml.kernel.org/r/CACT4Y+ZmuZMV5CjSFOeXviwQdABAgT7T+StKfTqan9YDtgEi5g@mail.gmail.com Fixes: 78f11a255749 ("mm: thp: fix /dev/zero MAP_PRIVATE and vm_flags cleanups") Signed-off-by: Konstantin Khlebnikov Reported-by: Dmitry Vyukov Acked-by: Vlastimil Babka Acked-by: Kirill A. Shutemov Cc: Dmitry Vyukov Cc: Andrea Arcangeli Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ff7f2c020cb969e4fdc33a55f809301f3901eed4 Author: Steve Capper Date: Thu Apr 28 16:18:24 2016 -0700 mm: exclude HugeTLB pages from THP page_mapped() logic commit 66ee95d16a7f1b7b4f1dd74a2d81c6e19dc29a14 upstream. HugeTLB pages cannot be split, so we use the compound_mapcount to track rmaps. Currently page_mapped() will check the compound_mapcount, but will also go through the constituent pages of a THP compound page and query the individual _mapcount's too. Unfortunately, page_mapped() does not distinguish between HugeTLB and THP compound pages and assumes that a compound page always needs to have HPAGE_PMD_NR pages querying. For most cases when dealing with HugeTLB this is just inefficient, but for scenarios where the HugeTLB page size is less than the pmd block size (e.g. when using contiguous bit on ARM) this can lead to crashes. This patch adjusts the page_mapped function such that we skip the unnecessary THP reference checks for HugeTLB pages. Fixes: e1534ae95004 ("mm: differentiate page_mapped() from page_mapcount() for compound pages") Signed-off-by: Steve Capper Acked-by: Kirill A. Shutemov Cc: Will Deacon Cc: Catalin Marinas Cc: Michal Hocko Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1153d28d9e0c93edde896a12afd66267943823f3 Author: Tejun Heo Date: Thu Apr 21 19:09:02 2016 -0400 memcg: relocate charge moving from ->attach to ->post_attach commit 264a0ae164bc0e9144bebcd25ff030d067b1a878 upstream. Hello, So, this ended up a lot simpler than I originally expected. I tested it lightly and it seems to work fine. Petr, can you please test these two patches w/o the lru drain drop patch and see whether the problem is gone? Thanks. ------ 8< ------ If charge moving is used, memcg performs relabeling of the affected pages from its ->attach callback which is called under both cgroup_threadgroup_rwsem and thus can't create new kthreads. This is fragile as various operations may depend on workqueues making forward progress which relies on the ability to create new kthreads. There's no reason to perform charge moving from ->attach which is deep in the task migration path. Move it to ->post_attach which is called after the actual migration is finished and cgroup_threadgroup_rwsem is dropped. * move_charge_struct->mm is added and ->can_attach is now responsible for pinning and recording the target mm. mem_cgroup_clear_mc() is updated accordingly. This also simplifies mem_cgroup_move_task(). * mem_cgroup_move_task() is now called from ->post_attach instead of ->attach. Signed-off-by: Tejun Heo Cc: Johannes Weiner Acked-by: Michal Hocko Debugged-and-tested-by: Petr Mladek Reported-by: Cyril Hrubis Reported-by: Johannes Weiner Fixes: 1ed1328792ff ("sched, cgroup: replace signal_struct->group_rwsem with a global percpu_rwsem") Signed-off-by: Greg Kroah-Hartman commit a0512d18450fff56304deff3e098228a25e5235a Author: Tejun Heo Date: Thu Apr 21 19:06:48 2016 -0400 cgroup, cpuset: replace cpuset_post_attach_flush() with cgroup_subsys->post_attach callback commit 5cf1cacb49aee39c3e02ae87068fc3c6430659b0 upstream. Since e93ad19d0564 ("cpuset: make mm migration asynchronous"), cpuset kicks off asynchronous NUMA node migration if necessary during task migration and flushes it from cpuset_post_attach_flush() which is called at the end of __cgroup_procs_write(). This is to avoid performing migration with cgroup_threadgroup_rwsem write-locked which can lead to deadlock through dependency on kworker creation. memcg has a similar issue with charge moving, so let's convert it to an official callback rather than the current one-off cpuset specific function. This patch adds cgroup_subsys->post_attach callback and makes cpuset register cpuset_post_attach_flush() as its ->post_attach. The conversion is mostly one-to-one except that the new callback is called under cgroup_mutex. This is to guarantee that no other migration operations are started before ->post_attach callbacks are finished. cgroup_mutex is one of the outermost mutex in the system and has never been and shouldn't be a problem. We can add specialized synchronization around __cgroup_procs_write() but I don't think there's any noticeable benefit. Signed-off-by: Tejun Heo Cc: Li Zefan Cc: Johannes Weiner Cc: Michal Hocko Signed-off-by: Greg Kroah-Hartman commit 7eec7856fca7062dee2918013925feb426977f9d Author: Jesper Dangaard Brouer Date: Tue Mar 15 14:53:32 2016 -0700 slub: clean up code for kmem cgroup support to kmem_cache_free_bulk commit 376bf125ac781d32e202760ed7deb1ae4ed35d31 upstream. This change is primarily an attempt to make it easier to realize the optimizations the compiler performs in-case CONFIG_MEMCG_KMEM is not enabled. Performance wise, even when CONFIG_MEMCG_KMEM is compiled in, the overhead is zero. This is because, as long as no process have enabled kmem cgroups accounting, the assignment is replaced by asm-NOP operations. This is possible because memcg_kmem_enabled() uses a static_key_false() construct. It also helps readability as it avoid accessing the p[] array like: p[size - 1] which "expose" that the array is processed backwards inside helper function build_detached_freelist(). Lastly this also makes the code more robust, in error case like passing NULL pointers in the array. Which were previously handled before commit 033745189b1b ("slub: add missing kmem cgroup support to kmem_cache_free_bulk"). Fixes: 033745189b1b ("slub: add missing kmem cgroup support to kmem_cache_free_bulk") Signed-off-by: Jesper Dangaard Brouer Cc: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Cc: Vladimir Davydov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9467ba065f226285498ee0902e33abed70963f17 Author: Roman Pen Date: Tue Apr 26 13:15:35 2016 +0200 workqueue: fix ghost PENDING flag while doing MQ IO commit 346c09f80459a3ad97df1816d6d606169a51001a upstream. The bug in a workqueue leads to a stalled IO request in MQ ctx->rq_list with the following backtrace: [ 601.347452] INFO: task kworker/u129:5:1636 blocked for more than 120 seconds. [ 601.347574] Tainted: G O 4.4.5-1-storage+ #6 [ 601.347651] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 601.348142] kworker/u129:5 D ffff880803077988 0 1636 2 0x00000000 [ 601.348519] Workqueue: ibnbd_server_fileio_wq ibnbd_dev_file_submit_io_worker [ibnbd_server] [ 601.348999] ffff880803077988 ffff88080466b900 ffff8808033f9c80 ffff880803078000 [ 601.349662] ffff880807c95000 7fffffffffffffff ffffffff815b0920 ffff880803077ad0 [ 601.350333] ffff8808030779a0 ffffffff815b01d5 0000000000000000 ffff880803077a38 [ 601.350965] Call Trace: [ 601.351203] [] ? bit_wait+0x60/0x60 [ 601.351444] [] schedule+0x35/0x80 [ 601.351709] [] schedule_timeout+0x192/0x230 [ 601.351958] [] ? blk_flush_plug_list+0xc7/0x220 [ 601.352208] [] ? ktime_get+0x37/0xa0 [ 601.352446] [] ? bit_wait+0x60/0x60 [ 601.352688] [] io_schedule_timeout+0xa4/0x110 [ 601.352951] [] ? _raw_spin_unlock_irqrestore+0xe/0x10 [ 601.353196] [] bit_wait_io+0x1b/0x70 [ 601.353440] [] __wait_on_bit+0x5d/0x90 [ 601.353689] [] wait_on_page_bit+0xc0/0xd0 [ 601.353958] [] ? autoremove_wake_function+0x40/0x40 [ 601.354200] [] __filemap_fdatawait_range+0xe4/0x140 [ 601.354441] [] filemap_fdatawait_range+0x14/0x30 [ 601.354688] [] filemap_write_and_wait_range+0x3f/0x70 [ 601.354932] [] blkdev_fsync+0x1b/0x50 [ 601.355193] [] vfs_fsync_range+0x49/0xa0 [ 601.355432] [] blkdev_write_iter+0xca/0x100 [ 601.355679] [] __vfs_write+0xaa/0xe0 [ 601.355925] [] vfs_write+0xa9/0x1a0 [ 601.356164] [] kernel_write+0x38/0x50 The underlying device is a null_blk, with default parameters: queue_mode = MQ submit_queues = 1 Verification that nullb0 has something inflight: root@pserver8:~# cat /sys/block/nullb0/inflight 0 1 root@pserver8:~# find /sys/block/nullb0/mq/0/cpu* -name rq_list -print -exec cat {} \; ... /sys/block/nullb0/mq/0/cpu2/rq_list CTX pending: ffff8838038e2400 ... During debug it became clear that stalled request is always inserted in the rq_list from the following path: save_stack_trace_tsk + 34 blk_mq_insert_requests + 231 blk_mq_flush_plug_list + 281 blk_flush_plug_list + 199 wait_on_page_bit + 192 __filemap_fdatawait_range + 228 filemap_fdatawait_range + 20 filemap_write_and_wait_range + 63 blkdev_fsync + 27 vfs_fsync_range + 73 blkdev_write_iter + 202 __vfs_write + 170 vfs_write + 169 kernel_write + 56 So blk_flush_plug_list() was called with from_schedule == true. If from_schedule is true, that means that finally blk_mq_insert_requests() offloads execution of __blk_mq_run_hw_queue() and uses kblockd workqueue, i.e. it calls kblockd_schedule_delayed_work_on(). That means, that we race with another CPU, which is about to execute __blk_mq_run_hw_queue() work. Further debugging shows the following traces from different CPUs: CPU#0 CPU#1 ---------------------------------- ------------------------------- reqeust A inserted STORE hctx->ctx_map[0] bit marked kblockd_schedule...() returns 1 request B inserted STORE hctx->ctx_map[1] bit marked kblockd_schedule...() returns 0 *** WORK PENDING bit is cleared *** flush_busy_ctxs() is executed, but bit 1, set by CPU#1, is not observed As a result request B pended forever. This behaviour can be explained by speculative LOAD of hctx->ctx_map on CPU#0, which is reordered with clear of PENDING bit and executed _before_ actual STORE of bit 1 on CPU#1. The proper fix is an explicit full barrier , which guarantees that clear of PENDING bit is to be executed before all possible speculative LOADS or STORES inside actual work function. Signed-off-by: Roman Pen Cc: Gioh Kim Cc: Michael Wang Cc: Tejun Heo Cc: Jens Axboe Cc: linux-block@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 332da5896337f59634cc65999e45e05d932df76e Author: Keith Busch Date: Wed Apr 27 14:22:32 2016 -0600 x86/apic: Handle zero vector gracefully in clear_vector_irq() commit 1bdb8970392a68489b469c3a330a1adb5ef61beb upstream. If x86_vector_alloc_irq() fails x86_vector_free_irqs() is invoked to cleanup the already allocated vectors. This subsequently calls clear_vector_irq(). The failed irq has no vector assigned, which triggers the BUG_ON(!vector) in clear_vector_irq(). We cannot suppress the call to x86_vector_free_irqs() for the failed interrupt, because the other data related to this irq must be cleaned up as well. So calling clear_vector_irq() with vector == 0 is legitimate. Remove the BUG_ON and return if vector is zero, [ tglx: Massaged changelog ] Fixes: b5dc8e6c21e7 "x86/irq: Use hierarchical irqdomain to manage CPU interrupt vectors" Signed-off-by: Keith Busch Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 39a719247564df7c177ddfc558f49975154914e0 Author: Ard Biesheuvel Date: Mon Feb 1 22:06:55 2016 +0000 efi: Expose non-blocking set_variable() wrapper to efivars commit 9c6672ac9c91f7eb1ec436be1442b8c26d098e55 upstream. Commit 6d80dba1c9fe ("efi: Provide a non-blocking SetVariable() operation") implemented a non-blocking alternative for the UEFI SetVariable() invocation performed by efivars, since it may occur in atomic context. However, this version of the function was never exposed via the efivars struct, so the non-blocking versions was not actually callable. Fix that. Signed-off-by: Ard Biesheuvel Signed-off-by: Matt Fleming Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Fixes: 6d80dba1c9fe ("efi: Provide a non-blocking SetVariable() operation") Link: http://lkml.kernel.org/r/1454364428-494-2-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 7c5de74238e1bbbf607228dc412dc82d6250f6d3 Author: Laszlo Ersek Date: Thu Apr 21 18:21:11 2016 +0200 efi: Fix out-of-bounds read in variable_matches() commit 630ba0cc7a6dbafbdee43795617c872b35cde1b4 upstream. The variable_matches() function can currently read "var_name[len]", for example when: - var_name[0] == 'a', - len == 1 - match_name points to the NUL-terminated string "ab". This function is supposed to accept "var_name" inputs that are not NUL-terminated (hence the "len" parameter"). Document the function, and access "var_name[*match]" only if "*match" is smaller than "len". Reported-by: Chris Wilson Signed-off-by: Laszlo Ersek Cc: Peter Jones Cc: Matthew Garrett Cc: Jason Andryuk Cc: Jani Nikula Link: http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/86906 Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit 0919927a5c86e71655ebc3a96a465c6eb640927b Author: Jason Gunthorpe Date: Sun Apr 10 19:13:13 2016 -0600 IB/security: Restrict use of the write() interface commit e6bd18f57aad1a2d1ef40e646d03ed0f2515c9e3 upstream. The drivers/infiniband stack uses write() as a replacement for bi-directional ioctl(). This is not safe. There are ways to trigger write calls that result in the return structure that is normally written to user space being shunted off to user specified kernel memory instead. For the immediate repair, detect and deny suspicious accesses to the write API. For long term, update the user space libraries and the kernel API to something that doesn't present the same security vulnerabilities (likely a structured ioctl() interface). The impacted uAPI interfaces are generally only available if hardware from drivers/infiniband is installed in the system. Reported-by: Jann Horn Signed-off-by: Linus Torvalds Signed-off-by: Jason Gunthorpe [ Expanded check to all known write() entry points ] Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit f0a5cc2e6685a452ccb7002073664dd5849a6e19 Author: Sagi Grimberg Date: Thu Mar 31 19:03:25 2016 +0300 IB/mlx5: Expose correct max_sge_rd limit commit 986ef95ecdd3eb6fa29433e68faa94c7624083be upstream. mlx5 devices (Connect-IB, ConnectX-4, ConnectX-4-LX) has a limitation where rdma read work queue entries cannot exceed 512 bytes. A rdma_read wqe needs to fit in 512 bytes: - wqe control segment (16 bytes) - rdma segment (16 bytes) - scatter elements (16 bytes each) So max_sge_rd should be: (512 - 16 - 16) / 16 = 30. Reported-by: Christoph Hellwig Tested-by: Christoph Hellwig Signed-off-by: Sagi Grimberg Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 0af7d2fc9dd15f67c8fec0a817c033b0ee66e70f Author: chunfan chen Date: Wed Jan 6 23:40:48 2016 -0800 mwifiex: fix IBSS data path issue. commit dc386ce76dedaeeaaf006fceb6ed8cf2e20ff026 upstream. The port_open flag is not applicable for IBSS mode. IBSS data path was broken when port_open flag was introduced. This patch fixes the problem by correcting the checks. Fixes: 5c8946330abfa4c ("mwifiex: enable traffic only when port is open") Signed-off-by: chunfan chen Signed-off-by: Amitkumar Karwar Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 0203ecf1fd3040cf8f2ea3d248036ed9f12c72dc Author: Doug Ledford Date: Fri Apr 22 20:14:58 2016 -0400 IB/core: Fix oops in ib_cache_gid_set_default_gid commit f4e7de63ab273b6a5e35c82eb4fc6363c855ddd4 upstream. When we fail to find the default gid index, we can't continue processing in this routine or else we will pass a negative index to later routines resulting in invalid memory access attempts and a kernel oops. Fixes: 03db3a2d81e6 (IB/core: Add RoCE GID table management) Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 669811a195e2bf4bb5e47cecee31c8c656458a98 Author: Michael Neuling Date: Fri Apr 22 14:57:48 2016 +1000 cxl: Keep IRQ mappings on context teardown commit d6776bba44d9752f6cdf640046070e71ee4bba7b upstream. Keep IRQ mappings on context teardown. This won't leak IRQs as if we allocate the mapping again, the generic code will give the same mapping used last time. Doing this works around a race in the generic code. Masking the interrupt introduces a race which can crash the kernel or result in IRQ that is never EOIed. The lost of EOI results in all subsequent mappings to the same HW IRQ never receiving an interrupt. We've seen this race with cxl test cases which are doing heavy context startup and teardown at the same time as heavy interrupt load. A fix to the generic code is being investigated also. Signed-off-by: Michael Neuling Tested-by: Andrew Donnellan Acked-by: Ian Munsie Tested-by: Vaibhav Jain Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 670f432010842747a2d3a12ea5307f2ba2bb4177 Author: Hans Verkuil Date: Fri Apr 22 04:00:50 2016 -0300 v4l2-dv-timings.h: fix polarity for 4k formats commit 3020ca711871fdaf0c15c8bab677a6bc302e28fe upstream. The VSync polarity was negative instead of positive for the 4k CEA formats. I probably copy-and-pasted these from the DMT 4k format, which does have a negative VSync polarity. Signed-off-by: Hans Verkuil Reported-by: Martin Bugge Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 922ff7af18370b752204c03e75e3dc3a2c50127d Author: Sakari Ailus Date: Sun Apr 3 16:31:03 2016 -0300 videobuf2-v4l2: Verify planes array in buffer dequeueing commit 2c1f6951a8a82e6de0d82b1158b5e493fc6c54ab upstream. When a buffer is being dequeued using VIDIOC_DQBUF IOCTL, the exact buffer which will be dequeued is not known until the buffer has been removed from the queue. The number of planes is specific to a buffer, not to the queue. This does lead to the situation where multi-plane buffers may be requested and queued with n planes, but VIDIOC_DQBUF IOCTL may be passed an argument struct with fewer planes. __fill_v4l2_buffer() however uses the number of planes from the dequeued videobuf2 buffer, overwriting kernel memory (the m.planes array allocated in video_usercopy() in v4l2-ioctl.c) if the user provided fewer planes than the dequeued buffer had. Oops! Fixes: b0e0e1f83de3 ("[media] media: videobuf2: Prepare to divide videobuf2") Signed-off-by: Sakari Ailus Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit ef468ad540f990e0f479a7548aea7dd089fdbd5a Author: Sakari Ailus Date: Sun Apr 3 16:15:00 2016 -0300 videobuf2-core: Check user space planes array in dqbuf commit e7e0c3e26587749b62d17b9dd0532874186c77f7 upstream. The number of planes in videobuf2 is specific to a buffer. In order to verify that the planes array provided by the user is long enough, a new vb2_buf_op is required. Call __verify_planes_array() when the dequeued buffer is known. Return an error to the caller if there was one, otherwise remove the buffer from the done list. Signed-off-by: Sakari Ailus Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 097b0525284c991c396b5a95c78426c8e1b93f3c Author: Ricardo Ribalda Delgado Date: Mon Apr 25 06:04:45 2016 -0300 media: vb2: Fix regression on poll() for RW mode commit b93876845c5e30a92964eeb088d9d2e024118022 upstream. When using a device is read/write mode, vb2 does not handle properly the first select/poll operation. The reason for this, is that when this code has been refactored, some of the operations have changed their order, and now fileio emulator is not started. The reintroduced check to the core is enabled by a quirk flag, that avoids this check by other subsystems like DVB. Fixes: 49d8ab9feaf2 ("media] media: videobuf2: Separate vb2_poll()") Reported-by: Dimitrios Katsaros Cc: Junghak Sung Signed-off-by: Ricardo Ribalda Delgado Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 0356e39aaf588e0099a9bd59916a65ac3c00030c Author: Ricardo Ribalda Delgado Date: Thu Mar 3 16:12:48 2016 -0300 vb2-memops: Fix over allocation of frame vectors commit 89a095668304e8a02502ffd35edacffdbf49aa8c upstream. On page unaligned frames, create_framevec forces get_vaddr_frames to allocate an extra page at the end of the buffer. Under some circumstances, this leads to -EINVAL on VIDIOC_QBUF. E.g: We have vm_a that vm_area that goes from 0x1000 to 0x3000. And a frame that goes from 0x1800 to 0x2800, i.e. 2 pages. frame_vector_create will be called with the following params: get_vaddr_frames(0x1800, 2, write, 1, vec); get_vaddr will allocate the first page after checking that the memory 0x1800-0x27ff is valid, but it will not allocate the second page because the range 0x2800-0x37ff is out of the vm_a range. This results in create_framevec returning -EFAULT Error Trace: [ 9083.793015] video0: VIDIOC_QBUF: 00:00:00.00000000 index=1, type=vid-cap, flags=0x00002002, field=any, sequence=0, memory=userptr, bytesused=0, offset/userptr=0x7ff2b023ca80, length=5765760 [ 9083.793028] timecode=00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000 [ 9083.793117] video0: VIDIOC_QBUF: error -22: 00:00:00.00000000 index=2, type=vid-cap, flags=0x00000000, field=any, sequence=0, memory=userptr, bytesused=0, offset/userptr=0x7ff2b07bc500, length=5765760 Also use true instead of 1 since that argument is a bool in the get_vaddr_frames() prototype. Fixes: 21fb0cb7ec65 ("[media] vb2: Provide helpers for mapping virtual addresses") Reported-by: Albert Antony Signed-off-by: Ricardo Ribalda Delgado [hans.verkuil@cisco.com: merged the 'bool' change into this patch] Acked-by: Marek Szyprowski Reviewed-by: Jan Kara Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman Signed-off-by: Mauro Carvalho Chehab commit 83f7a94330768bf6d1fdd86e1486797b7baf36cd Author: Sugar Zhang Date: Fri Mar 18 14:54:22 2016 +0800 ASoC: rt5640: Correct the digital interface data select commit 653aa4645244042826f105aab1be3d01b3d493ca upstream. this patch corrects the interface adc/dac control register definition according to datasheet. Signed-off-by: Sugar Zhang Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c1d80c01d44ecc0909200968274b116492fb36a5 Author: Mark Brown Date: Fri Mar 18 12:04:23 2016 +0000 ASoC: dapm: Make sure we have a card when displaying component widgets commit 47325078f2a3e543150e7df967e45756b2fff7ec upstream. The dummy component is reused for all cards so we special case and don't bind it to any of them. This means that code like that displaying the component widgets that tries to look at the card will crash. In the future we will fix this by ensuring that the dummy component looks like other components but that is invasive and so not suitable for a fix. Instead add a special case check here. Reported-by: Harry Pan Suggested-by: Lars-Peter Clausen Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 98e318d5ce62c6f3da316022a6b716c22aa64409 Author: Lars-Peter Clausen Date: Wed Jan 27 14:26:18 2016 +0100 ASoC: ssm4567: Reset device before regcache_sync() commit 712a8038cc24dba668afe82f0413714ca87184e0 upstream. When the ssm4567 is powered up the driver calles regcache_sync() to restore the register map content. regcache_sync() assumes that the device is in its power-on reset state. Make sure that this is the case by explicitly resetting the ssm4567 register map before calling regcache_sync() otherwise we might end up with a incorrect register map which leads to undefined behaviour. One such undefined behaviour was observed when returning from system suspend while a playback stream is active, in that case the ssm4567 was kept muted after resume. Fixes: 1ee44ce03011 ("ASoC: ssm4567: Add driver for Analog Devices SSM4567 amplifier") Reported-by: Harsha Priya Tested-by: Fang, Yang A Signed-off-by: Lars-Peter Clausen Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 9641d9d4d6f497dc56d512bf78ff7959a35d3613 Author: Arnd Bergmann Date: Mon Jan 25 18:07:33 2016 +0100 ASoC: s3c24xx: use const snd_soc_component_driver pointer commit ba4bc32eaa39ba7687f0958ae90eec94da613b46 upstream. An older patch to convert the API in the s3c i2s driver ended up passing a const pointer into a function that takes a non-const pointer, so we now get a warning: sound/soc/samsung/s3c2412-i2s.c: In function 's3c2412_iis_dev_probe': sound/soc/samsung/s3c2412-i2s.c:172:9: error: passing argument 3 of 's3c_i2sv2_register_component' discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] However, the s3c_i2sv2_register_component() function again passes the pointer into another function taking a const, so we just need to change its prototype. Fixes: eca3b01d0885 ("ASoC: switch over to use snd_soc_register_component() on s3c i2s") Signed-off-by: Arnd Bergmann Reviewed-by: Krzysztof Kozlowski Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6d32aa7ab6bfa3b95e51a8387aa5d7d6426b231f Author: Tony Luck Date: Fri Apr 29 15:42:25 2016 +0200 EDAC: i7core, sb_edac: Don't return NOTIFY_BAD from mce_decoder callback commit c4fc1956fa31003bfbe4f597e359d751568e2954 upstream. Both of these drivers can return NOTIFY_BAD, but this terminates processing other callbacks that were registered later on the chain. Since the driver did nothing to log the error it seems wrong to prevent other interested parties from seeing it. E.g. neither of them had even bothered to check the type of the error to see if it was a memory error before the return NOTIFY_BAD. Signed-off-by: Tony Luck Acked-by: Aristeu Rozanski Acked-by: Mauro Carvalho Chehab Cc: linux-edac Link: http://lkml.kernel.org/r/72937355dd92318d2630979666063f8a2853495b.1461864507.git.tony.luck@intel.com Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman commit 17b7a0f09f6dff4fd8d4a15027ccde8c9e427388 Author: Azael Avalos Date: Fri Apr 22 09:29:36 2016 -0600 toshiba_acpi: Fix regression caused by hotkey enabling value commit a30b8f81d9d6fe24eab8a023794548b048f08e3c upstream. Commit 52cbae0127ad ("toshiba_acpi: Change default Hotkey enabling value") changed the hotkeys enabling value, as it was the same value Windows uses, however, it turns out that the value tells the EC that the driver will now take care of the hardware events like the physical RFKill switch or the pointing device toggle button. This patch reverts such commit by changing the default hotkey enabling value to 0x09, which enables hotkey events only, making the hardware buttons working again. Fixes bugs 113331 and 114941. Signed-off-by: Azael Avalos Signed-off-by: Darren Hart Signed-off-by: Greg Kroah-Hartman commit 2068f4681b73b91c62b089bdea352c6853ea752b Author: Adrian Hunter Date: Fri Apr 15 14:06:57 2016 +0300 mmc: sdhci-acpi: Reduce Baytrail eMMC/SD/SDIO hangs commit 6e1c7d6103fe7031035cec321307c6356809adf4 upstream. Baytrail eMMC/SD/SDIO host controllers have been known to hang. A change to a hardware setting has been found to reduce the occurrence of such hangs. This patch ensures the correct setting. This patch applies cleanly to v4.4+. It could go to earlier kernels also, so I will send backports to the stable list in due course. Signed-off-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 2df18bf87e6ffbc13844543579fcc9e1be699001 Author: Lv Zheng Date: Thu Mar 10 10:54:29 2016 +0800 ACPICA / Interpreter: Fix a regression triggered because of wrong Linux ECDT support commit 5508df89756f8378024828e185724a9bd2348985 upstream. It is reported that the following commit triggers regressions: Linux commit: efaed9be998b5ae0afb7458e057e5f4402b43fa0 ACPICA commit: 31178590dde82368fdb0f6b0e466b6c0add96c57 Subject: ACPICA: Events: Enhance acpi_ev_execute_reg_method() to ensure no _REG evaluations can happen during OS early boot stages This is because that the ECDT support is not corrected in Linux, and Linux requires to execute _REG for ECDT (though this sounds so wrong), we need to ensure acpi_gbl_namespace_initialized is set before ECDT probing in order for _REG to be executed. Since we have to move "acpi_gbl_namespace_initialized = TRUE" to the initialization step happening before ECDT probing, acpi_load_tables() is the best candidate for now. Thus this patch fixes the regression by doing so. But if the ECDT support is fixed, Linux will not execute _REG for ECDT, and ECDT probing will happen before acpi_load_tables(). At that time, we still want to ensure acpi_gbl_namespace_initialized is set after executing acpi_ns_initialize_objects() (under the condition of acpi_gbl_group_module_level_code = FALSE), this patch also moves acpi_ns_initialize_objects() to acpi_load_tables() accordingly. Since acpi_ns_initialize_objects() doesn't seem to be skippable, this patch also removes ACPI_NO_OBJECT_INIT for the one invoked in acpi_load_tables(). And since the default region handlers should always be installed before loading the tables, this patch also removes useless acpi_gbl_group_module_level_code check accordingly. Reported by Chris Bainbridge, Fixed by Lv Zheng. Fixes: efaed9be998b (ACPICA: Events: Enhance acpi_ev_execute_reg_method() to ensure no _REG evaluations can happen during OS early boot stages) Reported-and-tested-by: Chris Bainbridge Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit d5a92c354a06c2d1d15a2a776a95fe99a5771ca0 Author: Javier Martinez Canillas Date: Sat Apr 16 21:14:52 2016 -0400 i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared commit 10ff4c5239a137abfc896ec73ef3d15a0f86a16a upstream. The exynos5 I2C controller driver always prepares and enables a clock before using it and then disables unprepares it when the clock is not used anymore. But this can cause a possible ABBA deadlock in some scenarios since a driver that uses regmap to access its I2C registers, will first grab the regmap lock and then the I2C xfer function will grab the prepare lock when preparing the I2C clock. But since the clock driver also uses regmap for I2C accesses, preparing a clock will first grab the prepare lock and then the regmap lock when using the regmap API. An example of this happens on the Exynos5422 Odroid XU4 board where a s2mps11 PMIC is used and both the s2mps11 regulators and clk drivers share the same I2C regmap. The possible deadlock is reported by the kernel lockdep: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sec_core:428:(regmap)->lock); lock(prepare_lock); lock(sec_core:428:(regmap)->lock); lock(prepare_lock); *** DEADLOCK *** Fix it by leaving the code prepared on probe and use {en,dis}able in the I2C transfer function. This patch is similar to commit 34e81ad5f0b6 ("i2c: s3c2410: fix ABBA deadlock by keeping clock prepared") that fixes the same bug in other driver for an I2C controller found in Samsung SoCs. Reported-by: Anand Moon Signed-off-by: Javier Martinez Canillas Reviewed-by: Anand Moon Reviewed-by: Krzysztof Kozlowski Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit dbfe960cd6e4a354265e1f89fcd3a5dc0aa7e690 Author: Michael Ellerman Date: Wed Apr 13 13:59:14 2016 +1000 i2c: cpm: Fix build break due to incompatible pointer types commit 609d5a1b2b35bb62b4b3750396e55453160c2a17 upstream. Since commit ea8daa7b9784 ("kbuild: Add option to turn incompatible pointer check into error"), assignments from an incompatible pointer types have become a hard error, eg: drivers/i2c/busses/i2c-cpm.c:545:91: error: passing argument 3 of 'dma_alloc_coherent' from incompatible pointer type Fix the build break by converting txdma & rxdma to dma_addr_t. Signed-off-by: Michael Ellerman Signed-off-by: Wolfram Sang Fixes: ea8daa7b9784 Signed-off-by: Greg Kroah-Hartman commit 585e3346943d925659fcef5b9b5f09855fa24fc2 Author: Adrian Hunter Date: Mon Apr 18 13:57:48 2016 +0300 perf intel-pt: Fix segfault tracing transactions commit 1342e0b7a6c1a060c593037fbac9f4b717f1cb3b upstream. Tracing a workload that uses transactions gave a seg fault as follows: perf record -e intel_pt// workload perf report Program received signal SIGSEGV, Segmentation fault. 0x000000000054b58c in intel_pt_reset_last_branch_rb (ptq=0x1a36110) at util/intel-pt.c:929 929 ptq->last_branch_rb->nr = 0; (gdb) p ptq->last_branch_rb $1 = (struct branch_stack *) 0x0 (gdb) up 1148 intel_pt_reset_last_branch_rb(ptq); (gdb) l 1143 if (ret) 1144 pr_err("Intel Processor Trace: failed to deliver transaction event 1145 ret); 1146 1147 if (pt->synth_opts.callchain) 1148 intel_pt_reset_last_branch_rb(ptq); 1149 1150 return ret; 1151 } 1152 (gdb) p pt->synth_opts.callchain $2 = true (gdb) (gdb) bt #0 0x000000000054b58c in intel_pt_reset_last_branch_rb (ptq=0x1a36110) #1 0x000000000054c1e0 in intel_pt_synth_transaction_sample (ptq=0x1a36110) #2 0x000000000054c5b2 in intel_pt_sample (ptq=0x1a36110) Caused by checking the 'callchain' flag when it should have been the 'last_branch' flag. Fix that. Reported-by: Andi Kleen Signed-off-by: Adrian Hunter Cc: Jiri Olsa Fixes: f14445ee72c5 ("perf intel-pt: Support generating branch stack") Link: http://lkml.kernel.org/r/1460977068-11566-1-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit ed050f0a5ab5ad8eca15b1e69311200364c2afb6 Author: Linus Walleij Date: Tue Feb 23 11:01:38 2016 +0100 video: ARM CLCD: runtime check for Versatile commit f36fdacc5fcdca7b0c0d89f031fcdc89717e0be3 upstream. The current compile-time check for inversed IENB/CNTL does not work in multiplatform boots: as soon as versatile is included in the build, the IENB/CNTL is switched and breaks graphics. Convert this to a runtime switch. Cc: Rob Herring Cc: Russell King Fixes: a29da136de34 ("ARM: versatile: convert to multi-platform") Signed-off-by: Linus Walleij Signed-off-by: Tomi Valkeinen Signed-off-by: Greg Kroah-Hartman commit fdc3e797c2e93082bd512711f8832e3565671613 Author: Flora Cui Date: Wed Apr 20 10:23:47 2016 +0800 drm/ttm: fix kref count mess in ttm_bo_move_to_lru_tail commit 56fc350224f16901db709cd8cba86bac751aa2a2 upstream. Fixes the following scenario: 1. Page table bo allocated in vram and linked to man->lru. tbo->list_kref.refcount=2 2. Page table bo is swapped out and removed from man->lru. tbo->list_kref.refcount=1 3. Command submission from userspace. Page table bo is moved to vram. ttm_bo_move_to_lru_tail() link it to man->lru and don't increase the kref count. Reviewed-by: Thomas Hellstrom Signed-off-by: Flora Cui Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 24346b9ba7260c86ab94779d7bce60431581ae08 Author: Ville Syrjälä Date: Thu Apr 14 14:39:02 2016 +0300 drm/i915: Use fw_domains_put_with_fifo() on HSW commit 31318a922395ec9e78d6e2ddf70779355afc7594 upstream. HSW still has the wake FIFO, so let's check it. Cc: Mika Kuoppala Cc: Deepak S Fixes: 05a2fb157e44 ("drm/i915: Consolidate forcewake code") Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1460633942-24013-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Mika Kuoppala (cherry picked from commit 3d7d0c85e41afb5a05e98b3a8a72c38357f02594) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 9e55305f88211868c4e0b05f076ee1dc60d36a37 Author: Chris Wilson Date: Wed Apr 13 17:35:11 2016 +0100 drm/i915: Force ringbuffers to not be at offset 0 commit 1b3e885a05d4f0a35dde035724e7c6453d2cbe71 upstream. For reasons unknown Sandybridge GT1 (at least) will eventually hang when it encounters a ring wraparound at offset 0. The test case that reproduces the bug reliably forces a large number of interrupted context switches, thereby causing very frequent ring wraparounds, but there are similar bug reports in the wild with the same symptoms, seqno writes stop just before the wrap and the ringbuffer at address 0. It is also timing crucial, but adding various delays hasn't helped pinpoint where the window lies. Whether the fault is restricted to the ringbuffer itself or the GTT addressing is unclear, but moving the ringbuffer fixes all the hangs I have been able to reproduce. References: (e.g.) https://bugs.freedesktop.org/show_bug.cgi?id=93262 Testcase: igt/gem_exec_whisper/render-contexts-interruptible #snb-gt1 Signed-off-by: Chris Wilson Acked-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1460565315-7748-12-git-send-email-chris@chris-wilson.co.uk (cherry picked from commit a687a43a48f0f91ba37dce5a14b467258ed6f035) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit c31aab947bf83aea9ae236237585bb9aa3c44569 Author: Akash Goel Date: Fri Mar 11 14:56:42 2016 +0530 drm/i915: Fixup the free space logic in ring_prepare commit d43f3ebf12f59c57782ec652da65ef61c2662b40 upstream. Currently for the case where there is enough space at the end of Ring buffer for accommodating only the base request, the wrapround is done immediately and as a result the base request gets added at the start of Ring buffer. But there may not be enough free space at the beginning to accommodate the base request, as before the wraparound, the wait was effectively done for the reserved_size free space from the start of Ring buffer. In such a case there is a potential of Ring buffer overflow, the instructions at the head of Ring (ACTHD) can get overwritten. Since the base request can fit in the remaining space, there is no need to wraparound immediately. The wraparound will anyway happen later when the reserved part starts getting used. Cc: Chris Wilson Signed-off-by: Akash Goel Signed-off-by: Chris Wilson Link: http://patchwork.freedesktop.org/patch/msgid/1457688402-10411-1-git-send-email-akash.goel@intel.com Reviewed-by: Chris Wilson (cherry picked from commit 782f6bc0aba037436d6a04d19b23f8b61020a576) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit d55f9f73e092bc77d337d76137763cd18746d05e Author: Mika Kuoppala Date: Tue Apr 5 15:56:17 2016 +0300 drm/i915/skl: Fix spurious gpu hang with gt3/gt4 revs commit 510650e8b2ab965931b35e9813467439d4df0b9c upstream. Experiments with heaven 4.0 benchmark and skylake gt3e (rev 0xa) suggest that WaForceContextSaveRestoreNonCoherent is needed for all revs. Extending this to all revs cures a gpu hang with rev 0xa when running heaven4.0 gpu benchmark. We have been here before, with problems enabling gt4e and extending up to revision F0 instead of false claims of bspec of E0 only. See commit ("drm/i915/skl: Default to noncoherent access up to F0"). In retrospect we should have covered this with this big blanket back then already, as E0 vs F0 discrepancy was suspicious enough. Previously the WaForceEnableNonCoherent has been tied to context non-coherence, atleast in relevant hsds. So keep this tie and extended this alongside. Cc: Abdiel Janulgue Cc: Ben Widawsky Cc: Timo Aaltonen Reported-by: Mike Lothian References: https://bugs.freedesktop.org/show_bug.cgi?id=93491 Signed-off-by: Mika Kuoppala Reviewed-by: Ben Widawsky Tested-by: Timo Aaltonen Link: http://patchwork.freedesktop.org/patch/msgid/1459860977-27751-2-git-send-email-mika.kuoppala@intel.com (cherry picked from commit 97ea6be161c55dec896b65c95157d953c330ae05) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 63982970eab27e840661a3d18b6afb35a93faea2 Author: Mat Martineau Date: Thu Jan 28 15:19:23 2016 -0800 drm/i915/skl: Fix DMC load on Skylake J0 and K0 commit a41c8882592fb80458959b10e37632ce030b68ca upstream. The driver does not load firmware for unknown steppings, so these new steppings must be added to the list. Cc: Rodrigo Vivi Signed-off-by: Mat Martineau Reviewed-by: Rodrigo Vivi Signed-off-by: Rodrigo Vivi Link: http://patchwork.freedesktop.org/patch/msgid/1454023163-25469-1-git-send-email-mathew.j.martineau@linux.intel.com Cc: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit d800a6576917cf7758b4b02608f3effed29bb6f5 Author: Dan Carpenter Date: Fri Mar 11 10:51:51 2016 +0300 drm/amdkfd: uninitialized variable in dbgdev_wave_control_set_registers() commit 93fce954427effee89e44a976299b15dd75b4bbc upstream. At the end of the function we expect "status" to be zero, but it's either -EINVAL or uninitialized. Fixes: 788bf83db301 ('drm/amdkfd: Add wave control operation to debugger') Signed-off-by: Dan Carpenter Signed-off-by: Oded Gabbay Signed-off-by: Greg Kroah-Hartman commit b72f5dc1569e1ae8b0bf56a5f27929789ffbc0c5 Author: Ville Syrjälä Date: Thu Oct 15 17:01:58 2015 +0300 drm/i915: skl_update_scaler() wants a rotation bitmask instead of bit number commit fa5a7970d372c9c9beb3a0ce79ee1d0c23387d0a upstream. Pass BIT(DRM_ROTATE_0) instead of DRM_ROTATE_0 to skl_update_scaler(). The former is a mask, the latter just the bit number. Fortunately the only thing skl_update_scaler() does with the rotation is check if it's 90/270 degrees or not, and so in this case it would still do the right thing. Cc: Chandra Konduru Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1444917718-28495-1-git-send-email-ville.syrjala@linux.intel.com Fixes: 6156a45602f9 ("drm/i915: skylake primary plane scaling using shared scalers") Reviewed-by: Matt Roper Signed-off-by: Greg Kroah-Hartman commit e62691bcc31759d59369c73e526b8cd0a4a9ca5f Author: Ville Syrjälä Date: Thu Jan 14 14:53:34 2016 +0200 drm/i915: Start WM computation from scratch on ILK-BDW commit f1ecaf8f9c9924badd4c8f690e39632d31edb500 upstream. ilk_compute_pipe_wm() assumes as zeroed pipe_wm structure when it starts. We used to pass such a zeroed struct in, but this got broken when the pipe_wm structure got embedded in the crtc state. To fix it without too much fuzz, we need to resort to a memset(). Fixes: 4e0963c7663b ("drm/i915: Calculate pipe watermarks into CRTC state (v3)") Cc: Matt Roper Signed-off-by: Ville Syrjälä Reviewed-by: Matt Roper Link: http://patchwork.freedesktop.org/patch/msgid/1452776015-22076-1-git-send-email-ville.syrjala@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit e49734bb47000aba674b7720ffa8ba37a31d7098 Author: Ville Syrjälä Date: Thu Jan 14 14:53:35 2016 +0200 drm/i915: Use the active wm config for merging on ILK-BDW commit d890565c44447db08fd9d07f5b02928a07a88c7e upstream. ilk_program_watermarks() is supposed to merge the active watermarks from all pipes. Thus we need to use the active config too instead of some precomputed stuff. Fixes: aa363136866c ("drm/i915: Calculate watermark configuration during atomic check (v2)") Cc: Matt Roper Signed-off-by: Ville Syrjälä Reviewed-by: Matt Roper Link: http://patchwork.freedesktop.org/patch/msgid/1452776015-22076-2-git-send-email-ville.syrjala@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 68941df2a3f7f28197445fe7b7ed3bc003099a58 Author: Ville Syrjälä Date: Mon Jan 11 20:48:32 2016 +0200 drm/i915: Cleanup phys status page too commit 7d3fdfff23852fe458a0d0979a3555fe60f1e563 upstream. Restore the lost phys status page cleanup. Fixes the following splat with DMA_API_DEBUG=y: WARNING: CPU: 0 PID: 21615 at ../lib/dma-debug.c:974 dma_debug_device_change+0x190/0x1f0() pci 0000:00:02.0: DMA-API: device driver has pending DMA allocations while released from device [count=1] One of leaked entries details: [device address=0x0000000023163000] [size=4096 bytes] [mapped with DMA_BIDIRECTIONAL] [mapped as coherent] Modules linked in: i915(-) i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm sha256_generic hmac drbg ctr ccm sch_fq_codel binfmt_misc joydev mousedev arc4 ath5k iTCO_wdt mac80211 smsc_ircc2 ath snd_intel8x0m snd_intel8x0 snd_ac97_codec ac97_bus psmouse snd_pcm input_leds i2c_i801 pcspkr snd_timer cfg80211 snd soundcore i2c_core ehci_pci firewire_ohci ehci_hcd firewire_core lpc_ich 8139too rfkill crc_itu_t mfd_core mii usbcore rng_core intel_agp intel_gtt usb_common agpgart irda crc_ccitt fujitsu_laptop led_class parport_pc video parport evdev backlight CPU: 0 PID: 21615 Comm: rmmod Tainted: G U 4.4.0-rc4-mgm-ovl+ #4 Hardware name: FUJITSU SIEMENS LIFEBOOK S6120/FJNB16C, BIOS Version 1.26 05/10/2004 e31a3de0 e31a3de0 e31a3d9c c128d4bd e31a3dd0 c1045a0c c15e00c4 e31a3dfc 0000546f c15dfad2 000003ce c12b3740 000003ce c12b3740 00000000 00000001 f61fb8a0 e31a3de8 c1045a83 00000009 e31a3de0 c15e00c4 e31a3dfc e31a3e4c Call Trace: [] dump_stack+0x16/0x19 [] warn_slowpath_common+0x8c/0xd0 [] ? dma_debug_device_change+0x190/0x1f0 [] ? dma_debug_device_change+0x190/0x1f0 [] warn_slowpath_fmt+0x33/0x40 [] dma_debug_device_change+0x190/0x1f0 [] notifier_call_chain+0x59/0x70 [] __blocking_notifier_call_chain+0x3f/0x80 [] blocking_notifier_call_chain+0x1f/0x30 [] __device_release_driver+0xc3/0xf0 [] driver_detach+0x97/0xa0 [] bus_remove_driver+0x40/0x90 [] driver_unregister+0x28/0x60 [] ? trace_hardirqs_on_caller+0x12c/0x1d0 [] pci_unregister_driver+0x18/0x80 [] drm_pci_exit+0x87/0xb0 [drm] [] i915_exit+0x1b/0x1ee [i915] [] SyS_delete_module+0x14c/0x210 [] ? trace_hardirqs_on_caller+0x12c/0x1d0 [] ? ____fput+0xd/0x10 [] do_fast_syscall_32+0xa4/0x450 [] sysenter_past_esp+0x3b/0x5d ---[ end trace c2ecbc77760f10a0 ]--- Mapped at: [] debug_dma_alloc_coherent+0x33/0x90 [] drm_pci_alloc+0x18c/0x1e0 [drm] [] intel_init_ring_buffer+0x2af/0x490 [i915] [] intel_init_render_ring_buffer+0x130/0x750 [i915] [] i915_gem_init_rings+0x1e/0x110 [i915] v2: s/BUG_ON/WARN_ON/ since dim doens't like the former anymore Cc: Chris Wilson Fixes: 5c6c600 ("drm/i915: Remove DRI1 ring accessors and API") Signed-off-by: Ville Syrjälä Reviewed-by: Chris Wilson (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1452538112-5331-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit cd8602ccbd8950ffb3a40afa995afde226bce321 Author: Ville Syrjälä Date: Tue Dec 8 19:59:36 2015 +0200 drm/i915: Pass the correct encoder to intel_ddi_clk_select() with MST commit d919161b67b1ed4a374dae685840a601bbeb1347 upstream. We're supposed to pass the primary DP encoder to intel_ddi_clk_select(), not the fake MST encoder. Do so. There's no real bug here though, since intel_ddi_clk_select() only checks if the encoder type is EDP (which it isn't for either the primary DP encoder or the fake MST encoder), and it gets the DDI port via intel_ddi_get_encoder_port() (which knows how to do the fake->primary->port dance itself). Fixes: e404ba8 ("drm/i915: Setup DDI clk for MST on SKL") Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1449597590-6971-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 668062601c05c5d734b70b9d804731927656797f Author: Vladimir Zapolskiy Date: Sun Mar 6 03:21:46 2016 +0200 pwm: brcmstb: Fix check of devm_ioremap_resource() return code commit c5857e3f94ab2719dfac649a146cb5dd6f21fcf3 upstream. The change fixes potential oops while accessing iomem on invalid address if devm_ioremap_resource() fails due to some reason. The devm_ioremap_resource() function returns ERR_PTR() and never returns NULL, which makes useless a following check for NULL. Signed-off-by: Vladimir Zapolskiy Fixes: 3a9f5957020f ("pwm: Add Broadcom BCM7038 PWM controller support") Acked-by: Florian Fainelli Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 29dd6b130d58aa49cf2c3006b8b5ff3f37b97b1e Author: cpaul@redhat.com Date: Fri Apr 22 16:08:46 2016 -0400 drm/dp/mst: Get validated port ref in drm_dp_update_payload_part1() commit 263efde31f97c498e1ebad30e4d2906609d7ad6b upstream. We can thank KASAN for finding this, otherwise I probably would have spent hours on it. This fixes a somewhat harder to trigger kernel panic, occuring while enabling MST where the port we were currently updating the payload on would have all of it's refs dropped before we finished what we were doing: ================================================================== BUG: KASAN: use-after-free in drm_dp_update_payload_part1+0xb3f/0xdb0 [drm_kms_helper] at addr ffff8800d29de018 Read of size 4 by task Xorg/973 ============================================================================= BUG kmalloc-2048 (Tainted: G B W ): kasan: bad access detected ----------------------------------------------------------------------------- INFO: Allocated in drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper] age=16477 cpu=0 pid=2175 ___slab_alloc+0x472/0x490 __slab_alloc+0x20/0x40 kmem_cache_alloc_trace+0x151/0x190 drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper] drm_dp_send_link_address+0x526/0x960 [drm_kms_helper] drm_dp_check_and_send_link_address+0x1ac/0x210 [drm_kms_helper] drm_dp_mst_link_probe_work+0x77/0xd0 [drm_kms_helper] process_one_work+0x562/0x1350 worker_thread+0xd9/0x1390 kthread+0x1c5/0x260 ret_from_fork+0x22/0x40 INFO: Freed in drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper] age=7521 cpu=0 pid=2175 __slab_free+0x17f/0x2d0 kfree+0x169/0x180 drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper] drm_dp_destroy_connector_work+0x2b8/0x490 [drm_kms_helper] process_one_work+0x562/0x1350 worker_thread+0xd9/0x1390 kthread+0x1c5/0x260 ret_from_fork+0x22/0x40 which on this T460s, would eventually lead to kernel panics in somewhat random places later in intel_mst_enable_dp() if we got lucky enough. Signed-off-by: Lyude Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 051430d073048ac390f7c40882ef4cba4dc63820 Author: Lyude Date: Wed Apr 13 16:50:18 2016 -0400 drm/dp/mst: Restore primary hub guid on resume commit 9dc0487d96a0396367a1451b31873482080b527f upstream. Some hubs are forgetful, and end up forgetting whatever GUID we set previously after we do a suspend/resume cycle. This can lead to hotplugging breaking (along with probably other things) since the hub will start sending connection notifications with the wrong GUID. As such, we need to check on resume whether or not the GUID the hub is giving us is valid. Signed-off-by: Lyude Reviewed-by: Harry Wentland Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1460580618-7421-1-git-send-email-cpaul@redhat.com Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 1e349a12f80f731eceaccdaf3bada358f964b0a5 Author: cpaul@redhat.com Date: Mon Apr 4 19:58:47 2016 -0400 drm/dp/mst: Validate port in drm_dp_payload_send_msg() commit deba0a2af9592b2022a0bce7b085a318b53ce1db upstream. With the joys of things running concurrently, there's always a chance that the port we get passed in drm_dp_payload_send_msg() isn't actually valid anymore. Because of this, we need to make sure we validate the reference to the port before we use it otherwise we risk running into various race conditions. For instance, on the Dell MST monitor I have here for testing, hotplugging it enough times causes us to kernel panic: [drm:intel_mst_enable_dp] 1 [drm:drm_dp_update_payload_part2] payload 0 1 [drm:intel_get_hpd_pins] hotplug event received, stat 0x00200000, dig 0x10101011, pins 0x00000020 [drm:intel_hpd_irq_handler] digital hpd port B - short [drm:intel_dp_hpd_pulse] got hpd irq on port B - short [drm:intel_dp_check_mst_status] got esi 00 10 00 [drm:drm_dp_update_payload_part2] payload 1 1 general protection fault: 0000 [#1] SMP … Call Trace: [] drm_dp_update_payload_part2+0xc2/0x130 [drm_kms_helper] [] intel_mst_enable_dp+0xf8/0x180 [i915] [] haswell_crtc_enable+0x3ed/0x8c0 [i915] [] intel_atomic_commit+0x5ad/0x1590 [i915] [] ? drm_atomic_set_crtc_for_connector+0x57/0xe0 [drm] [] drm_atomic_commit+0x37/0x60 [drm] [] drm_atomic_helper_set_config+0x7a/0xb0 [drm_kms_helper] [] drm_mode_set_config_internal+0x62/0x100 [drm] [] drm_mode_setcrtc+0x3cd/0x4e0 [drm] [] drm_ioctl+0x143/0x510 [drm] [] ? drm_mode_setplane+0x1b0/0x1b0 [drm] [] ? hrtimer_start_range_ns+0x1b7/0x3a0 [] do_vfs_ioctl+0x92/0x570 [] ? __sys_recvmsg+0x42/0x80 [] SyS_ioctl+0x79/0x90 [] entry_SYSCALL_64_fastpath+0x1a/0xa4 RIP [] drm_dp_payload_send_msg+0x146/0x1f0 [drm_kms_helper] Which occurs because of the hotplug event shown in the log, which ends up causing DRM's dp helpers to drop the port we're updating the payload on and panic. Signed-off-by: Lyude Reviewed-by: David Airlie Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 84567d48428068c30c5ae39df3add68d3063a089 Author: Ben Skeggs Date: Fri Apr 22 10:05:21 2016 +1000 drm/nouveau/gr/gf100: select a stream master to fixup tfb offset queries commit 28dca90533750c7e31e8641c3df426bad9c12941 upstream. Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 133aa320dca4764c229e44ad193dc4c8fd356d02 Author: Huacai Chen Date: Tue Apr 19 19:19:11 2016 +0800 drm: Loongson-3 doesn't fully support wc memory commit 221004c66a58949a0f25c937a6789c0839feb530 upstream. Signed-off-by: Huacai Chen Reviewed-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit e2a679a4821048f3522cf6fc9d5aad071d4ec598 Author: Vitaly Prosyak Date: Thu Apr 14 13:34:03 2016 -0400 drm/radeon: fix vertical bars appear on monitor (v2) commit 5d5b7803c49bbb01bdf4c6e95e8314d0515b9484 upstream. When crtc/timing is disabled on boot the dig block should be stopped in order ignore timing from crtc, reset the steering fifo otherwise we get display corruption or hung in dp sst mode. v2: agd: fix coding style Signed-off-by: Vitaly Prosyak Signed-off-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 035c2a77f9463d08d614dfc979a5bda2cda9e805 Author: Jérôme Glisse Date: Tue Apr 19 09:07:50 2016 -0400 drm/radeon: forbid mapping of userptr bo through radeon device file commit b5dcec693f87cb8475f2291c0075b2422addd3d6 upstream. Allowing userptr bo which are basicly a list of page from some vma (so either anonymous page or file backed page) would lead to serious corruption of kernel structures and counters (because we overwrite the page->mapping field when mapping buffer). This will already block if the buffer was populated before anyone does try to mmap it because then TTM_PAGE_FLAG_SG would be set in in the ttm_tt flags. But that flag is check before ttm_tt_populate in the ttm vm fault handler. So to be safe just add a check to verify_access() callback. Reviewed-by: Christian König Signed-off-by: Jérôme Glisse Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit e9b17ac18472285d7d372c65b4c134e3ba702402 Author: Alex Deucher Date: Wed Apr 13 12:08:27 2016 -0400 drm/radeon: fix initial connector audio value commit 7403c515c49c033fec33df0814fffdc977e6acdc upstream. This got lost somewhere along the way. This fixes audio not working until set_property was called. Noticed-by: Hyungwon Hwang Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit d4b97922117d54ea64db30aeafe03009cf7015e0 Author: Alex Deucher Date: Thu Apr 14 14:15:16 2016 -0400 drm/radeon: add a quirk for a XFX R9 270X commit bcb31eba4a4ea356fd61cbd5dec5511c3883f57e upstream. bug: https://bugs.freedesktop.org/show_bug.cgi?id=76490 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit a287c79db4cb54efd714455dae24cb1d7b2969b9 Author: Grigori Goronzy Date: Tue Mar 22 15:48:18 2016 -0400 drm/amdgpu: fix regression on CIK (v2) This fix was written against drm-next, but when it was backported to 4.5 as a stable fix, the driver internal structure change was missed. Fix that up here to avoid a hang due to waiting for the wrong sequence number. v2: agd: fix up commit message Signed-off-by: Grigori Goronzy Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher commit 645c785a6df4b2499f1122126cb4613e39f16142 Author: Sonny Jiang Date: Mon Apr 18 16:05:04 2016 -0400 amdgpu/uvd: add uvd fw version for amdgpu commit 562e2689baebaa2ac25b7ec934385480ed1cb7d6 upstream. Was previously always hardcoded to 0. Signed-off-by: Sonny Jiang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 365c61975fbd453155f784162c4a3bfc5f0e3d9f Author: Alex Deucher Date: Mon Apr 18 18:25:34 2016 -0400 drm/amdgpu: bump the afmt limit for CZ, ST, Polaris commit 83c5cda2ccf40a7a7e4bb674321509b346e23d5a upstream. Fixes array overflow on these chips. Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 20b3683349aa8a9cfa835e174812c2150a583680 Author: Alex Deucher Date: Mon Apr 18 18:09:57 2016 -0400 drm/amdgpu: use defines for CRTCs and AMFT blocks commit 3ea25f858fd5aeee888059952bbb8e910541eebb upstream. Prerequiste for the next patch which ups the limits. Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 6c222fccda9494207839ddce9a48805d50a6e9f5 Author: Rex Zhu Date: Tue Apr 12 19:25:52 2016 +0800 drm/amdgpu: when suspending, if uvd/vce was running. need to cancel delay work. commit 85cc88f02eb0ecf44493c1b2ebb6f206cd5fc321 upstream. fix the issue that when resume back, uvd/vce dpm was disabled and uvd/vce's performace dropped. Signed-off-by: Rex Zhu Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 595d20448db71e24edea9b1fa39464ce62704518 Author: Robin Murphy Date: Thu Mar 10 19:28:12 2016 +0000 iommu/dma: Restore scatterlist offsets correctly commit 07b48ac4bbe527e68cfc555f2b2b206908437141 upstream. With the change to stashing just the IOVA-page-aligned remainder of the CPU-page offset rather than the whole thing, the failure path in __invalidate_sg() also needs tweaking to account for that in the case of differing page sizes where the two offsets may not be equivalent. Similarly in __finalise_sg(), lest the architecture-specific wrappers later get the wrong address for cache maintenance on sync or unmap. Fixes: 164afb1d85b8 ("iommu/dma: Use correct offset in map_sg") Reported-by: Magnus Damm Signed-off-by: Robin Murphy Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 80424d70b7e9e3246cf173aa9a8e74d17bf3c775 Author: Joerg Roedel Date: Fri Apr 8 15:12:24 2016 +0200 iommu/amd: Fix checking of pci dma aliases commit e3156048346c28c695f5cf9db67a8cf88c90f947 upstream. Commit 61289cb ('iommu/amd: Remove old alias handling code') removed the old alias handling code from the AMD IOMMU driver because this is now handled by the IOMMU core code. But this also removed the handling of PCI aliases, which is not handled by the core code. This caused issues with PCI devices that have hidden PCIe-to-PCI bridges that rewrite the request-id. Fix this bug by re-introducing some of the removed functions from commit 61289cbaf6c8 and add a alias field 'struct iommu_dev_data'. This field carrys the return value of the get_alias() function and uses that instead of the amd_iommu_alias_table[] array in the code. Fixes: 61289cbaf6c8 ('iommu/amd: Remove old alias handling code') Tested-by: Tomasz Golinski Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 2c776b98a8b3102b6d0a18827e8f60dcb3f679f3 Author: Keerthy Date: Thu Apr 14 10:29:16 2016 +0530 pinctrl: single: Fix pcs_parse_bits_in_pinctrl_entry to use __ffs than ffs commit 56b367c0cd67d4c3006738e7dc9dda9273fd2bfe upstream. pcs_parse_bits_in_pinctrl_entry uses ffs which gives bit indices ranging from 1 to MAX. This leads to a corner case where we try to request the pin number = MAX and fails. bit_pos value is being calculted using ffs. pin_num_from_lsb uses bit_pos value. pins array is populated with: pin + pin_num_from_lsb. The above is 1 more than usual bit indices as bit_pos uses ffs to compute first set bit. Hence the last of the pins array is populated with the MAX value and not MAX - 1 which causes error when we call pin_request. mask_pos is rightly calculated as ((pcs->fmask) << (bit_pos - 1)) Consequently val_pos and submask are correct. Hence use __ffs which gives (ffs(x) - 1) as the first bit set. fixes: 4e7e8017a8 ("pinctrl: pinctrl-single: enhance to configure multiple pins of different modules") Signed-off-by: Keerthy Acked-by: Tony Lindgren Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 2126e3425ef520ab8133b4ff09fe7fff77149b07 Author: Yingjoe Chen Date: Sat Apr 2 14:57:49 2016 +0800 pinctrl: mediatek: correct debounce time unit in mtk_gpio_set_debounce commit 5fedbb923936174ab4d1d5cc92bca1cf6b2e0ca2 upstream. The debounce time unit for gpio_chip.set_debounce is us but mtk_gpio_set_debounce regard it as ms. Fix this by correct debounce time array dbnc_arr so it can find correct debounce setting. Debounce time for first debounce setting is 500us, correct this as well. While I'm at it, also change the debounce time array name to "debounce_time" for readability. Signed-off-by: Yingjoe Chen Reviewed-by: Daniel Kurtz Acked-by: Hongzhou Yang Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 3c1deaf612d2bb21a43a9b7bb259df85837c5448 Author: Arnd Bergmann Date: Tue Feb 16 16:03:23 2016 +0100 xen kconfig: don't "select INPUT_XEN_KBDDEV_FRONTEND" commit 13aa38e291bdd4e4018f40dd2f75e464814dcbf3 upstream. The Xen framebuffer driver selects the xen keyboard driver, so the latter will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT is a loadable module, this configuration cannot work. On mainline kernels, the symbol will be enabled but not used, while in combination with a patch I have to detect such useless configurations, we get the expected link failure: drivers/input/built-in.o: In function `xenkbd_remove': xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device' xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device' This removes the extra "select", as it just causes more trouble than it helps. In theory, some defconfig file might break if it has XEN_FBDEV_FRONTEND in it but not INPUT_XEN_KBDDEV_FRONTEND. The Kconfig fragment we ship in the kernel (kernel/configs/xen.config) however already enables both, and anyone using an old .config file would keep having both enabled. Signed-off-by: Arnd Bergmann Suggested-by: David Vrabel Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND") Acked-by: Stefano Stabellini Signed-off-by: Tomi Valkeinen Signed-off-by: Greg Kroah-Hartman commit cce3b7ea49d10207fdb980f4c9675644cc804444 Author: Stephen Boyd Date: Sun Apr 17 05:21:42 2016 -0700 Input: pmic8xxx-pwrkey - fix algorithm for converting trigger delay commit eda5ecc0a6b865561997e177c393f0b0136fe3b7 upstream. The trigger delay algorithm that converts from microseconds to the register value looks incorrect. According to most of the PMIC documentation, the equation is delay (Seconds) = (1 / 1024) * 2 ^ (x + 4) except for one case where the documentation looks to have a formatting issue and the equation looks like delay (Seconds) = (1 / 1024) * 2 x + 4 Most likely this driver was written with the improper documentation to begin with. According to the downstream sources the valid delays are from 2 seconds to 1/64 second, and the latter equation just doesn't make sense for that. Let's fix the algorithm and the range check to match the documentation and the downstream sources. Reported-by: Bjorn Andersson Fixes: 92d57a73e410 ("input: Add support for Qualcomm PMIC8XXX power key") Signed-off-by: Stephen Boyd Tested-by: John Stultz Acked-by: Bjorn Andersson Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 14e42e0a81bd16c8db80c686d97388c03d87e3fc Author: Vladis Dronov Date: Thu Mar 31 10:53:42 2016 -0700 Input: gtco - fix crash on detecting device without endpoints commit 162f98dea487206d9ab79fc12ed64700667a894d upstream. The gtco driver expects at least one valid endpoint. If given malicious descriptors that specify 0 for the number of endpoints, it will crash in the probe function. Ensure there is at least one endpoint on the interface before using it. Also let's fix a minor coding style issue. The full correct report of this issue can be found in the public Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1283385 Reported-by: Ralf Spenneberg Signed-off-by: Vladis Dronov Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 9ee3568e4c66681a1ef19e34bd524cd3443afa91 Author: Dmitry Ivanov Date: Thu Apr 7 09:31:38 2016 +0200 netlink: don't send NETLINK_URELEASE for unbound sockets commit e27260203912b40751fa353d009eaa5a642c739f upstream. All existing users of NETLINK_URELEASE use it to clean up resources that were previously allocated to a socket via some command. As a result, no users require getting this notification for unbound sockets. Sending it for unbound sockets, however, is a problem because any user (including unprivileged users) can create a socket that uses the same ID as an existing socket. Binding this new socket will fail, but if the NETLINK_URELEASE notification is generated for such sockets, the users thereof will be tricked into thinking the socket that they allocated the resources for is closed. In the nl80211 case, this will cause destruction of virtual interfaces that still belong to an existing hostapd process; this is the case that Dmitry noticed. In the NFC case, it will cause a poll abort. In the case of netlink log/queue it will cause them to stop reporting events, as if NFULNL_CFG_CMD_UNBIND/NFQNL_CFG_CMD_UNBIND had been called. Fix this problem by checking that the socket is bound before generating the NETLINK_URELEASE notification. Signed-off-by: Dmitry Ivanov Signed-off-by: Johannes Berg Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 22717803bc026a31e747cfb642e5e6480c81e3fe Author: Dmitry Ivanov Date: Wed Apr 6 17:23:18 2016 +0300 nl80211: check netlink protocol in socket release notification commit 8f815cdde3e550e10c2736990d791f60c2ce43eb upstream. A non-privileged user can create a netlink socket with the same port_id as used by an existing open nl80211 netlink socket (e.g. as used by a hostapd process) with a different protocol number. Closing this socket will then lead to the notification going to nl80211's socket release notification handler, and possibly cause an action such as removing a virtual interface. Fix this issue by checking that the netlink protocol is NETLINK_GENERIC. Since generic netlink has no notifier chain of its own, we can't fix the problem more generically. Fixes: 026331c4d9b5 ("cfg80211/mac80211: allow registering for and sending action frames") Signed-off-by: Dmitry Ivanov [rewrite commit message] Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 11372ae1ccbfee91d85e59cb1d6d4ff3b55b5659 Author: Anton Blanchard Date: Fri Apr 15 12:08:19 2016 +1000 powerpc: Update TM user feature bits in scan_features() commit 4705e02498d6d5a7ab98dfee9595cd5e91db2017 upstream. We need to update the user TM feature bits (PPC_FEATURE2_HTM and PPC_FEATURE2_HTM) to mirror what we do with the kernel TM feature bit. At the moment, if firmware reports TM is not available we turn off the kernel TM feature bit but leave the userspace ones on. Userspace thinks it can execute TM instructions and it dies trying. This (together with a QEMU patch) fixes PR KVM, which doesn't currently support TM. Signed-off-by: Anton Blanchard Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 3a14513f75e01d9b7a4a264014f0947a05ffbb00 Author: Anton Blanchard Date: Fri Apr 15 12:07:24 2016 +1000 powerpc: Update cpu_user_features2 in scan_features() commit beff82374b259d726e2625ec6c518a5f2613f0ae upstream. scan_features() updates cpu_user_features but not cpu_user_features2. Amongst other things, cpu_user_features2 contains the user TM feature bits which we must keep in sync with the kernel TM feature bit. Signed-off-by: Anton Blanchard Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 07302a0576c7a213b6c87afab6783701540574ef Author: Anton Blanchard Date: Fri Apr 15 12:06:13 2016 +1000 powerpc: scan_features() updates incorrect bits for REAL_LE commit 6997e57d693b07289694239e52a10d2f02c3a46f upstream. The REAL_LE feature entry in the ibm_pa_feature struct is missing an MMU feature value, meaning all the remaining elements initialise the wrong values. This means instead of checking for byte 5, bit 0, we check for byte 0, bit 0, and then we incorrectly set the CPU feature bit as well as MMU feature bit 1 and CPU user feature bits 0 and 2 (5). Checking byte 0 bit 0 (IBM numbering), means we're looking at the "Memory Management Unit (MMU)" feature - ie. does the CPU have an MMU. In practice that bit is set on all platforms which have the property. This means we set CPU_FTR_REAL_LE always. In practice that seems not to matter because all the modern cpus which have this property also implement REAL_LE, and we've never needed to disable it. We're also incorrectly setting MMU feature bit 1, which is: #define MMU_FTR_TYPE_8xx 0x00000002 Luckily the only place that looks for MMU_FTR_TYPE_8xx is in Book3E code, which can't run on the same cpus as scan_features(). So this also doesn't matter in practice. Finally in the CPU user feature mask, we're setting bits 0 and 2. Bit 2 is not currently used, and bit 0 is: #define PPC_FEATURE_PPC_LE 0x00000001 Which says the CPU supports the old style "PPC Little Endian" mode. Again this should be harmless in practice as no 64-bit CPUs implement that mode. Fix the code by adding the missing initialisation of the MMU feature. Also add a comment marking CPU user feature bit 2 (0x4) as reserved. It would be unsafe to start using it as old kernels incorrectly set it. Fixes: 44ae3ab3358e ("powerpc: Free up some CPU feature bits by moving out MMU-related features") Signed-off-by: Anton Blanchard [mpe: Flesh out changelog, add comment reserving 0x4] Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 9c78c121978db38129d312feac5a6433e16fdc28 Author: Horia Geant? Date: Tue Apr 19 20:33:48 2016 +0300 crypto: talitos - fix AEAD tcrypt tests commit 340ff60ae93a5db2b2be6f38868df9a1293b6007 upstream. After conversion to new AEAD interface, tcrypt tests fail as follows: [...] [ 1.145414] alg: aead: Test 1 failed on encryption for authenc-hmac-sha1-cbc-aes-talitos [ 1.153564] 00000000: 53 69 6e 67 6c 65 20 62 6c 6f 63 6b 20 6d 73 67 [ 1.160041] 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1.166509] 00000020: 00 00 00 00 [...] Fix them by providing the correct cipher in & cipher out pointers, i.e. must skip over associated data in src and dst S/G. While here, fix a problem with the HW S/G table index usage: tbl_off must be updated after the pointer to the table entries is set. Fixes: aeb4c132f33d ("crypto: talitos - Convert to new AEAD interface") Reported-by: Jonas Eymann Signed-off-by: Horia Geant? Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 19613a8c615ade2bcae3afc06297680a71bf2645 Author: Jonas Eymann Date: Tue Apr 19 20:33:47 2016 +0300 crypto: talitos - fix crash in talitos_cra_init() commit 89d124cb61b39900959e2839ac06b6339b6a54cb upstream. Conversion of talitos driver to the new AEAD interface hasn't been properly tested. AEAD algorithms crash in talitos_cra_init as follows: [...] [ 1.141095] talitos ffe30000.crypto: hwrng [ 1.145381] Unable to handle kernel paging request for data at address 0x00000058 [ 1.152913] Faulting instruction address: 0xc02accc0 [ 1.157910] Oops: Kernel access of bad area, sig: 11 [#1] [ 1.163315] SMP NR_CPUS=2 P1020 RDB [ 1.166810] Modules linked in: [ 1.169875] CPU: 0 PID: 1007 Comm: cryptomgr_test Not tainted 4.4.6 #1 [ 1.176415] task: db5ec200 ti: db4d6000 task.ti: db4d6000 [ 1.181821] NIP: c02accc0 LR: c02acd18 CTR: c02acd04 [ 1.186793] REGS: db4d7d30 TRAP: 0300 Not tainted (4.4.6) [ 1.192457] MSR: 00029000 CR: 95009359 XER: e0000000 [ 1.198585] DEAR: 00000058 ESR: 00000000 GPR00: c017bdc0 db4d7de0 db5ec200 df424b48 00000000 00000000 df424bfc db75a600 GPR08: df424b48 00000000 db75a628 db4d6000 00000149 00000000 c0044cac db5acda0 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000400 df424940 GPR24: df424900 00003083 00000400 c0180000 db75a640 c03e9f84 df424b40 df424b48 [ 1.230978] NIP [c02accc0] talitos_cra_init+0x28/0x6c [ 1.236039] LR [c02acd18] talitos_cra_init_aead+0x14/0x28 [ 1.241443] Call Trace: [ 1.243894] [db4d7de0] [c03e9f84] 0xc03e9f84 (unreliable) [ 1.249322] [db4d7df0] [c017bdc0] crypto_create_tfm+0x5c/0xf0 [ 1.255083] [db4d7e10] [c017beec] crypto_alloc_tfm+0x98/0xf8 [ 1.260769] [db4d7e40] [c0186a20] alg_test_aead+0x28/0xc8 [ 1.266181] [db4d7e60] [c0186718] alg_test+0x260/0x2e0 [ 1.271333] [db4d7ee0] [c0183860] cryptomgr_test+0x30/0x54 [ 1.276843] [db4d7ef0] [c0044d80] kthread+0xd4/0xd8 [ 1.281741] [db4d7f40] [c000e4a4] ret_from_kernel_thread+0x5c/0x64 [ 1.287930] Instruction dump: [ 1.290902] 38600000 4e800020 81230028 7c681b78 81490010 38e9ffc0 3929ffe8 554a073e [ 1.298691] 2b8a000a 7d474f9e 812a0008 91230030 <80e90058> 39270060 7c0004ac 7cc04828 Fixes: aeb4c132f33d ("crypto: talitos - Convert to new AEAD interface") Signed-off-by: Jonas Eymann Signed-off-by: Greg Kroah-Hartman Fix typo - replaced parameter of __crypto_ahash_alg(): s/tfm/alg Remove checkpatch warnings. Add commit message. Signed-off-by: Horia Geant? Signed-off-by: Herbert Xu commit 397666872f678009f235bae843085ca4c38bbab4 Author: Xiaodong Liu Date: Tue Apr 12 09:45:51 2016 +0000 crypto: sha1-mb - use corrcet pointer while completing jobs commit 0851561d9c965df086ef8a53f981f5f95a57c2c8 upstream. In sha_complete_job, incorrect mcryptd_hash_request_ctx pointer is used when check and complete other jobs. If the memory of first completed req is freed, while still completing other jobs in the func, kernel will crash since NULL pointer is assigned to RIP. Signed-off-by: Xiaodong Liu Acked-by: Tim Chen Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit ff09a40c4cd4f1f892888cd61cb3724d9242b8bd Author: Tom Lendacky Date: Wed Apr 13 10:52:25 2016 -0500 crypto: ccp - Prevent information leakage on export commit f709b45ec461b548c41a00044dba1f1b572783bf upstream. Prevent information from leaking to userspace by doing a memset to 0 of the export state structure before setting the structure values and copying it. This prevents un-initialized padding areas from being copied into the export area. Reported-by: Ben Hutchings Signed-off-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 72e520a940cb24c4a616edb5dbd94b980fa88dd3 Author: Tadeusz Struk Date: Wed Apr 6 14:42:32 2016 -0700 crypto: rsa-pkcs1pad - fix dst len commit 6f0904ada402a45b3a0a3b9b6507d91d3a9da67a upstream. The output buffer length has to be at least as big as the key_size. It is then updated to the actual output size by the implementation. Signed-off-by: Tadeusz Struk Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 3a698a36c9d9d2f807a5a5739b552253b2cee49f Author: Matti Gottlieb Date: Tue Mar 15 13:46:47 2016 +0200 iwlwifi: mvm: fix memory leak in paging commit 7fdf9663261cc77a516396fec82cee8a8ea07e76 upstream. Currently paging download buffer is freed during the the unloading of the opmode which happens when the driver is unloaded. This causes a memory leak since the paging download buffer is allocated every time we enable the interface, so the download buffer can be allocated many times, but only be freed once. Free paging download buffer during disabling of the interface. Signed-off-by: Matti Gottlieb Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit eefe1567b6cf0a336213c7302b6b407c65a55ece Author: Emmanuel Grumbach Date: Thu Mar 10 13:07:17 2016 +0200 iwlwifi: pcie: lower the debug level for RSA semaphore access commit 9fc515bc9e735c10cd327f05c20f5ef69474188d upstream. IWL_INFO is not an error but still printed by default. "can't access the RSA semaphore it is write protected" seems worrisome but it is not really a problem. Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit df9b0e78d6420cf10ba66b2264434ff0a8d520c6 Author: Sebastian Ott Date: Thu Mar 31 11:48:31 2016 +0200 s390/pci: add extra padding to function measurement block commit 9d89d9e61d361f3adb75e1aebe4bb367faf16cfa upstream. Newer machines might use a different (larger) format for function measurement blocks. To ensure that we comply with the alignment requirement on these machines and prevent memory corruption (when firmware writes more data than we expect) add 16 padding bytes at the end of the fmb. Signed-off-by: Sebastian Ott Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit a6d040719dbf8deb946e25d823797757f675d606 Author: Srinivas Pandruvada Date: Fri Apr 22 19:53:59 2016 -0700 cpufreq: intel_pstate: Fix processing for turbo activation ratio commit 1becf03545a0859ceaaf9e8c2d9861882a71cb01 upstream. When the config TDP level is not nominal (level = 0), the MSR values for reading level 1 and level 2 ratios contain power in low 14 bits and actual ratio bits are at bits [23:16]. The current processing for level 1 and level 2 is wrong as there is no shift done to get actual ratio. Fixes: 6a35fc2d6c22 (cpufreq: intel_pstate: get P1 from TAR when available) Signed-off-by: Srinivas Pandruvada Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 048866b7fa8978ca583866bfef106a35ef83e6cd Author: Alex Deucher Date: Mon Apr 25 13:12:18 2016 -0400 Revert "drm/amdgpu: disable runtime pm on PX laptops without dGPU power control" commit e9bef455af8eb0e837e179aab8988ae2649fd8d3 upstream. This reverts commit bedf2a65c1aa8fb29ba8527fd00c0f68ec1f55f1. See the radeon revert for an extended description. Signed-off-by: Greg Kroah-Hartman commit 119d57d1ed4c66172dd1a8f396c19c2a81479c10 Author: Vladis Dronov Date: Sun Jan 31 14:14:52 2016 -0200 usbvision: revert commit 588afcc1 commit d5468d7afaa9c9e961e150f0455a14a9f4872a98 upstream. Commit 588afcc1c0e4 ("[media] usbvision fix overflow of interfaces array")' should be reverted, because: * "!dev->actconfig->interface[ifnum]" won't catch a case where the value is not NULL but some garbage. This way the system may crash later with GPF. * "(ifnum >= USB_MAXINTERFACES)" does not cover all the error conditions. "ifnum" should be compared to "dev->actconfig-> desc.bNumInterfaces", i.e. compared to the number of "struct usb_interface" kzalloc()-ed, not to USB_MAXINTERFACES. * There is a "struct usb_device" leak in this error path, as there is usb_get_dev(), but no usb_put_dev() on this path. * There is a bug of the same type several lines below with number of endpoints. The code is accessing hard-coded second endpoint ("interface->endpoint[1].desc") which may not exist. It would be great to handle this in the same patch too. * All the concerns above are resolved by already-accepted commit fa52bd50 ("[media] usbvision: fix crash on detecting device with invalid configuration") * Mailing list message: http://www.spinics.net/lists/linux-media/msg94832.html Signed-off-by: Vladis Dronov Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit f4957fc4e66e25ca0750816a00438f60b0f7af87 Author: Fabio Estevam Date: Mon Mar 28 18:45:36 2016 -0300 Revert "PCI: imx6: Add support for active-low reset GPIO" commit b2d7a9cd3ff8ec561348267c2ef7d47b2b91e801 upstream. Commit 5c5fb40de8f1 ("PCI: imx6: Add support for active-low reset GPIO") cause regressions on some boards like MX6 Gateworks Ventana, for example. The reason for the breakage is that this commit sets the GPIO polarity in the wrong logic level. Also, the commit log is wrong because active-low reset GPIO is what the driver used to support since the beginning. So keep the old behavior that ignores the GPIO polarity specified in the device tree and treat the PCI reset GPIO as active-low. Reported-by: Krzysztof Hałasa Tested-by: Tim Harvey # Gateworks Ventana Signed-off-by: Fabio Estevam Signed-off-by: Bjorn Helgaas Acked-by: Tim Harvey Acked-by: Lucas Stach Signed-off-by: Greg Kroah-Hartman commit 3773e5419fba1b7377c07170d414c093e76af66f Author: Alex Deucher Date: Mon Apr 18 11:19:19 2016 -0400 Revert "drm/radeon: disable runtime pm on PX laptops without dGPU power control" commit bfaddd9fc8ac048b99475f000dbef6f08297417f upstream. This reverts commit e64c952efb8e0c15ae82cec8e455ab4910690ef1. ATPX is the ACPI method for controlling AMD PowerXpress laptops. There are flags to indicate which methods are supported. If the dGPU power down flag is not supported, the driver needs to implement the dGPU power down manually. We had previously always forced the driver to assume the ATPX dGPU power down was present, but this causes problems on boards where it is not, leading to GPU hangs when attempting to power down the dGPU. Manual dGPU power down is not currently supported in the Linux driver. Some laptops indicate that the ATPX dGPU power down method is not present, but it actually apparently is. I'm not sure if this is a bios bug and it should be set or if there is a reason it was unset and the method should not be used. This is not an issue on other OSes since both the ATPX and the manual driver power down methods are supported. This is apparently fairly widespread, so just revert for now. bugs: https://bugzilla.kernel.org/show_bug.cgi?id=115321 https://bugzilla.kernel.org/show_bug.cgi?id=116581 https://bugzilla.kernel.org/show_bug.cgi?id=116251 Signed-off-by: Greg Kroah-Hartman commit 12bd0cc56f4eb0f2294e4ab3af5d6edb1d6102c7 Author: Lyude Date: Wed Mar 16 15:18:04 2016 -0400 drm/i915: Fix race condition in intel_dp_destroy_mst_connector() commit 9e60290dbafdf577766e5fc5f2fdb3be450cf9a6 upstream. After unplugging a DP MST display from the system, we have to go through and destroy all of the DRM connectors associated with it since none of them are valid anymore. Unfortunately, intel_dp_destroy_mst_connector() doesn't do a good enough job of ensuring that throughout the destruction process that no modesettings can be done with the connectors. As it is right now, intel_dp_destroy_mst_connector() works like this: * Take all modeset locks * Clear the configuration of the crtc on the connector, if there is one * Drop all modeset locks, this is required because of circular dependency issues that arise with trying to remove the connector from sysfs with modeset locks held * Unregister the connector * Take all modeset locks, again * Do the rest of the required cleaning for destroying the connector * Finally drop all modeset locks for good This only works sometimes. During the destruction process, it's very possible that a userspace application will attempt to do a modesetting using the connector. When we drop the modeset locks, an ioctl handler such as drm_mode_setcrtc has the oppurtunity to take all of the modeset locks from us. When this happens, one thing leads to another and eventually we end up committing a mode with the non-existent connector: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to enable link training [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f [drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel equalization [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f [drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi And in some cases, such as with the T460s using an MST dock, this results in breaking modesetting and/or panicking the system. To work around this, we now unregister the connector at the very beginning of intel_dp_destroy_mst_connector(), grab all the modesetting locks, and then hold them until we finish the rest of the function. Signed-off-by: Lyude Signed-off-by: Rob Clark Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1458155884-13877-1-git-send-email-cpaul@redhat.com (cherry picked from commit 1f7717552ef1306be3b7ed28c66c6eff550e3a23) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 9a0afb4c8ab9c676f7fc74986f8503e73a1a1955 Author: John Keeping Date: Wed Nov 18 11:17:25 2015 +0000 drm/qxl: fix cursor position with non-zero hotspot commit d59a1f71ff1aeda4b4630df92d3ad4e3b1dfc885 upstream. The SPICE protocol considers the position of a cursor to be the location of its active pixel on the display, so the cursor is drawn with its top-left corner at "(x - hot_spot_x, y - hot_spot_y)" but the DRM cursor position gives the location where the top-left corner should be drawn, with the hotspot being a hint for drivers that need it. This fixes the location of the window resize cursors when using Fluxbox with the QXL DRM driver and both the QXL and modesetting X drivers. Signed-off-by: John Keeping Reviewed-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1447845445-2116-1-git-send-email-john@metanate.com Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 3ccf26206bb31c336170c141d02e7a465ea95ac0 Author: Ilia Mirkin Date: Sun Mar 6 16:06:06 2016 -0500 drm/nouveau/core: use vzalloc for allocating ramht commit 78a121d82da8aff3aca2a6a1c40f5061081760f0 upstream. Most calls to nvkm_ramht_new use 0x8000 as the size. This results in a fairly sizeable chunk of memory to be allocated, which may not be available with kzalloc. Since this is done fairly rarely (once per channel), use vzalloc instead. Signed-off-by: Ilia Mirkin Signed-off-by: Ben Skeggs Cc: Sven Joachim Signed-off-by: Greg Kroah-Hartman commit 2b543041318b815a82b5098e13dba362afd36f43 Author: Davidlohr Bueso Date: Wed Apr 20 20:09:24 2016 -0700 futex: Acknowledge a new waiter in counter before plist commit fe1bce9e2107ba3a8faffe572483b6974201a0e6 upstream. Otherwise an incoming waker on the dest hash bucket can miss the waiter adding itself to the plist during the lockless check optimization (small window but still the correct way of doing this); similarly to the decrement counterpart. Suggested-by: Peter Zijlstra Signed-off-by: Davidlohr Bueso Cc: Davidlohr Bueso Cc: bigeasy@linutronix.de Cc: dvhart@infradead.org Link: http://lkml.kernel.org/r/1461208164-29150-1-git-send-email-dave@stgolabs.net Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 2fb38003da2f53c68e9fd603cb45f1c0d408df21 Author: Sebastian Andrzej Siewior Date: Fri Apr 15 14:35:39 2016 +0200 futex: Handle unlock_pi race gracefully commit 89e9e66ba1b3bde9d8ea90566c2aee20697ad681 upstream. If userspace calls UNLOCK_PI unconditionally without trying the TID -> 0 transition in user space first then the user space value might not have the waiters bit set. This opens the following race: CPU0 CPU1 uval = get_user(futex) lock(hb) lock(hb) futex |= FUTEX_WAITERS .... unlock(hb) cmpxchg(futex, uval, newval) So the cmpxchg fails and returns -EINVAL to user space, which is wrong because the futex value is valid. To handle this (yes, yet another) corner case gracefully, check for a flag change and retry. [ tglx: Massaged changelog and slightly reworked implementation ] Fixes: ccf9e6a80d9e ("futex: Make unlock_pi more robust") Signed-off-by: Sebastian Andrzej Siewior Cc: Davidlohr Bueso Cc: Darren Hart Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1460723739-5195-1-git-send-email-bigeasy@linutronix.de Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit ad208db91aa8ce3c25be86e8ae535e1e9525a24a Author: Romain Perier Date: Thu Apr 14 15:36:03 2016 +0200 asm-generic/futex: Re-enable preemption in futex_atomic_cmpxchg_inatomic() commit fba7cd681b6155e2d93e7862fcd6f970336b83c3 upstream. The recent decoupling of pagefault disable and preempt disable added an explicit preempt_disable/enable() pair to the futex_atomic_cmpxchg_inatomic() implementation in asm-generic/futex.h. But it forgot to add preempt_enable() calls to the error handling code pathes, which results in a preemption count imbalance. This is observable on boot when the test for atomic_cmpxchg() is calling futex_atomic_cmpxchg_inatomic() on a NULL pointer. Add the missing preempt_enable() calls to the error handling code pathes. [ tglx: Massaged changelog ] Fixes: d9b9ff8c1889 ("sched/preempt, futex: Disable preemption in UP futex_atomic_cmpxchg_inatomic() explicitly") Signed-off-by: Romain Perier Cc: linux-arch@vger.kernel.org Cc: Thomas Petazzoni Cc: Arnd Bergmann Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1460640963-690-1-git-send-email-romain.perier@free-electrons.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit fffbd108ed5365ac6584a6f866449493113b394b Author: Takashi Iwai Date: Thu Apr 21 16:39:17 2016 +0200 ALSA: hda - Update BCLK also at hotplug for i915 HSW/BDW commit bb03ed216370cb021f377f923471e56d1de3ff5d upstream. The recent bug report suggests that BCLK setup for i915 HSW/BDW needs to be updated at each HDMI hotplug, not only at initialization and resume. That is, we need to update HSW_EM4 and HSW_EM5 registers at ELD notification, too. Otherwise the HDMI audio may be out of sync and played in a wrong pitch. However, the HDA codec driver has no access to the controller registers, and currently the code managing these registers is in hda_intel.c, i.e. local to the controller driver. For allowing the explicit BCLK update from the codec driver, as in this patch, the former haswell_set_bclk() in hda_intel.c is moved to hdac_i915.c and exposed as snd_hdac_i915_set_bclk(). This is called from both the HDA controller driver and intel_pin_eld_notify() in HDMI codec driver. Along with this change, snd_hdac_get_display_clk() gets dropped as it's no longer used. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91410 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c603999c8a32b504c1bed83c7e764e5295a8407e Author: Conrad Kostecki Date: Tue Apr 26 10:08:10 2016 +0200 ALSA: hda - Add dock support for ThinkPad X260 commit 037e119738120c1cdc460c6ae33871c3000531f3 upstream. Fixes audio output on a ThinkPad X260, when using Lenovo CES 2013 docking station series (basic, pro, ultra). Signed-off-by: Conrad Kostecki Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3aa21d9c1ab90bf6d1b2e1d777c2c83d18412b0f Author: Takashi Iwai Date: Thu Apr 21 17:37:54 2016 +0200 ALSA: pcxhr: Fix missing mutex unlock commit 67f3754b51f22b18c4820fb84062f658c30e8644 upstream. The commit [9bef72bdb26e: ALSA: pcxhr: Use nonatomic PCM ops] converted to non-atomic PCM ops, but shamelessly with an unbalanced mutex locking, which leads to the hangup easily. Fix it. Fixes: 9bef72bdb26e ('ALSA: pcxhr: Use nonatomic PCM ops') Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116441 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e2eda0c984c9b43f3f1a1156ee51226d9588c313 Author: Lu, Han Date: Wed Apr 20 10:08:43 2016 +0800 ALSA: hda - add PCI ID for Intel Broxton-T commit 9859a971ca228725425238756ee89c6133306ec8 upstream. Add HD Audio Device PCI ID for the Intel Broxton-T platform. It is an HDA Intel PCH controller. Signed-off-by: Lu, Han Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 34712f41945242ead08068a04a3e0c3fd5b4cd2d Author: Takashi Iwai Date: Tue Apr 19 22:07:50 2016 +0200 ALSA: hda - Keep powering up ADCs on Cirrus codecs commit de3df8a986b635082a1d94bae2c361d043c57106 upstream. Although one weird behavior about the input path (inconsistent D0/D3 switch) on Cirrus CS420x codecs was fixed in the previous commit, there is still an issue on some Mac machines: the capture stream stalls when switching the ADCs on the fly. More badly, this keeps stuck until the next reboot. The dynamic ADC switching is already a bit fragile and assuming optimistically that the chip accepts the frequent power changes. On Cirrus codecs, this doesn't seem applicable. As a quick workaround, we pin down the ADCs to keep up in D0 when spec->dyn_adc_switch is set. In this way, the ADCs are kept up only for the system that were confirmed to be broken. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116171 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e7b5493db28b51ccc9e173ab11c9a135f3970eb3 Author: Bastien Nocera Date: Mon Apr 18 11:10:42 2016 +0200 ALSA: hda/realtek - Add ALC3234 headset mode for Optiplex 9020m commit afecb146d8d8a60a1dde9cdf570c278649617fde upstream. The Optiplex 9020m with Haswell-DT processor needs a quirk for the headset jack at the front of the machine to be able to use microphones. A quirk for this model was originally added in 3127899, but c77900e removed it in favour of a more generic version. Unfortunately, pin configurations can changed based on firmware/BIOS versions, and the generic version doesn't have any effect on newer versions of the machine/firmware anymore. With help from David Henningsson Signed-off-by: Bastien Nocera Tested-by: Bastien Nocera Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 657e34bf7816b021886e0eccaa684f2c7abc292a Author: Takashi Iwai Date: Sun Apr 17 09:39:41 2016 +0200 ALSA: hda - Don't trust the reported actual power state commit 50fd4987c4f3c3ebf0ce94d932732011bbdc7c71 upstream. We've got a regression report that the recording on Mac with a cirrus codec doesn't work any longer. This turned out to be the missing power up to D0 by power_save_node enablement. After analyzing the traces, we found out that the culprit is that the codec advertises the "actual" power state of a few nodes to be D0 while the "target" power state is D3. This inconsistency is usually OK, as it implies the power transition. But in the case of cirrus codec, this seems to be stuck to D3 while it's not actually D0. This patch addresses the issue by checking the power state difference more strictly. It sends the power-state change verb unless both the target and the actual power states show the given value. We may introduce yet another flag indicating the possible broken hardware power state, but it's anyway safer to set the proper power state even in a transition (at least it's harmless as long as the target state is same). So this simpler change was applied now. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116171 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit feafdc60ef9d64f3029370fbc665ca6142e40a41 Author: Tony Luck Date: Thu Apr 14 10:22:02 2016 -0700 x86 EDAC, sb_edac.c: Take account of channel hashing when needed commit ea5dfb5fae81939f777ca569d8cfb599252da2e8 upstream. Haswell and Broadwell can be configured to hash the channel interleave function using bits [27:12] of the physical address. On those processor models we must check to see if hashing is enabled (bit21 of the HASWELL_HASYSDEFEATURE2 register) and act accordingly. Based on a patch by patrickg Tested-by: Patrick Geary Signed-off-by: Tony Luck Acked-by: Mauro Carvalho Chehab Cc: Aristeu Rozanski Cc: Borislav Petkov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-edac@vger.kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 80970bb790b213e7ebdf4b7296607f83b0c2d2c8 Author: Tony Luck Date: Thu Apr 14 10:21:52 2016 -0700 x86 EDAC, sb_edac.c: Repair damage introduced when "fixing" channel address commit ff15e95c82768d589957dbb17d7eb7dba7904659 upstream. In commit: eb1af3b71f9d ("Fix computation of channel address") I switched the "sck_way" variable from holding the log2 value read from the h/w to instead be the actual number. Unfortunately it is needed in log2 form when used to shift the address. Tested-by: Patrick Geary Signed-off-by: Tony Luck Acked-by: Mauro Carvalho Chehab Cc: Aristeu Rozanski Cc: Borislav Petkov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-edac@vger.kernel.org Fixes: eb1af3b71f9d ("Fix computation of channel address") Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit d5e81d34ceadad4174a61c9bf910b89a32509581 Author: Jan Beulich Date: Thu Apr 21 00:27:04 2016 -0600 x86/mm/xen: Suppress hugetlbfs in PV guests commit 103f6112f253017d7062cd74d17f4a514ed4485c upstream. Huge pages are not normally available to PV guests. Not suppressing hugetlbfs use results in an endless loop of page faults when user mode code tries to access a hugetlbfs mapped area (since the hypervisor denies such PTEs to be created, but error indications can't be propagated out of xen_set_pte_at(), just like for various of its siblings), and - once killed in an oops like this: kernel BUG at .../fs/hugetlbfs/inode.c:428! invalid opcode: 0000 [#1] SMP ... RIP: e030:[] [] remove_inode_hugepages+0x25b/0x320 ... Call Trace: [] hugetlbfs_evict_inode+0x15/0x40 [] evict+0xbd/0x1b0 [] __dentry_kill+0x19a/0x1f0 [] dput+0x1fe/0x220 [] __fput+0x155/0x200 [] task_work_run+0x60/0xa0 [] do_exit+0x160/0x400 [] do_group_exit+0x3b/0xa0 [] get_signal+0x1ed/0x470 [] do_signal+0x14/0x110 [] prepare_exit_to_usermode+0xe9/0xf0 [] retint_user+0x8/0x13 This is CVE-2016-3961 / XSA-174. Reported-by: Vitaly Kuznetsov Signed-off-by: Jan Beulich Cc: Andrew Morton Cc: Andy Lutomirski Cc: Boris Ostrovsky Cc: Borislav Petkov Cc: Brian Gerst Cc: David Vrabel Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Juergen Gross Cc: Linus Torvalds Cc: Luis R. Rodriguez Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Toshi Kani Cc: xen-devel Link: http://lkml.kernel.org/r/57188ED802000078000E431C@prv-mh.provo.novell.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 1389f1bee142433b6d12d47dbfb417774836dda1 Author: Peter Zijlstra Date: Wed Mar 16 16:22:45 2016 +0100 sched/cgroup: Fix/cleanup cgroup teardown/init commit 2f5177f0fd7e531b26d54633be62d1d4cb94621c upstream. The CPU controller hasn't kept up with the various changes in the whole cgroup initialization / destruction sequence, and commit: 2e91fa7f6d45 ("cgroup: keep zombies associated with their original cgroups") caused it to explode. The reason for this is that zombies do not inhibit css_offline() from being called, but do stall css_released(). Now we tear down the cfs_rq structures on css_offline() but zombies can run after that, leading to use-after-free issues. The solution is to move the tear-down to css_released(), which guarantees nobody (including no zombies) is still using our cgroup. Furthermore, a few simple cleanups are possible too. There doesn't appear to be any point to us using css_online() (anymore?) so fold that in css_alloc(). And since cgroup code guarantees an RCU grace period between css_released() and css_free() we can forgo using call_rcu() and free the stuff immediately. Suggested-by: Tejun Heo Reported-by: Kazuki Yamaguchi Reported-by: Niklas Cassel Tested-by: Niklas Cassel Signed-off-by: Peter Zijlstra (Intel) Acked-by: Tejun Heo Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Fixes: 2e91fa7f6d45 ("cgroup: keep zombies associated with their original cgroups") Link: http://lkml.kernel.org/r/20160316152245.GY6344@twins.programming.kicks-ass.net Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit d97a32ea55cc048020ec515b25df3b78267e17af Author: Robert Jarzmik Date: Fri Feb 12 23:29:04 2016 +0100 mtd: nand: pxa3xx_nand: fix dmaengine initialization commit 9097103f06332d099c5ab06d1e7f22f4bcaca6e2 upstream. When the driver is initialized in a pure device-tree platform, the driver's probe fails allocating the dma channel : [ 525.624435] pxa3xx-nand 43100000.nand: no resource defined for data DMA [ 525.632088] pxa3xx-nand 43100000.nand: alloc nand resource failed The reason is that the DMA IO resource is not acquired through platform resources but by OF bindings. Fix this by ensuring that DMA IO resources are only queried in the non device-tree case. Fixes: 8f5ba31aa565 ("mtd: nand: pxa3xx-nand: switch to dmaengine") Signed-off-by: Robert Jarzmik Acked-by: Ezequiel Garcia Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit 128a7d5e35cee72b5be483edbbf4e1f21285c890 Author: Robert Jarzmik Date: Mon Feb 15 21:57:48 2016 +0100 dmaengine: pxa_dma: fix the maximum requestor line commit 6bab1c6afdca0371cfa957079b36b78d12dd2cf5 upstream. The current number of requestor lines is limited to 31. This was an error of a previous commit, as this number is platform dependent, and is actually : - for pxa25x: 40 requestor lines - for pxa27x: 75 requestor lines - for pxa3xx: 100 requestor lines The previous testing did not reveal the faulty constant as on pxa[23]xx platforms, only camera, MSL and USB are above requestor 32, and in these only the camera has a driver using dma. Fixes: e87ffbdf0697 ("dmaengine: pxa_dma: fix the no-requestor case") Signed-off-by: Robert Jarzmik Acked-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 34590a40fef3cf6d35fe6a7b67d8035904af12fb Author: Peter Ujfalusi Date: Wed Apr 6 13:01:46 2016 +0300 dmaengine: edma: Remove dynamic TPTC power management feature commit 23f49fd2ea9bc8e1c8cff0126cd71b071ea9e91f upstream. The dynamic or on demand pm_runtime does not work correctly on am335x and am437x due to interference with hwmod. Fall back using the pm_runtime usage as it was in the old driver stack, meaning that at probe time call pm_runtime_enable() and pm_runtime_get_sync() for the TPTCs as well. Fixes: 1be5336bc7ba ("dmaengine: edma: New device tree binding") Signed-off-by: Peter Ujfalusi Reported-by: Tero Kristo Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 4fbd6178a6f999a30d86bcb517efda47eaeaad94 Author: Peter Ujfalusi Date: Tue Apr 5 15:20:20 2016 +0300 dmaengine: omap-dma: Fix polled channel completion detection and handling commit 689d3c5ecc9e2eac714d32ca152b72988bc2a67b upstream. When based on the CCR_ENABLE bit the channel is stopped we should not call omap_dma_callback(), only change the return value to DMA_COMPLETE. Client drivers will do the right thing to clean up the channel after the transfer has been completed. Check the CCR_ENABLE only if the channel is running and not paused since pause in sDMA means that the channel is stopped. This will fix one hard to reproduce race condition when the channel is terminated during transfer (affecting cyclic operation). Fixes: 1a7cf7b26f25 ("dmaengine: omap-dma: Handle cases when the channel is polled for completion") Signed-off-by: Peter Ujfalusi Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 390cb9a6064eed7b197e926137293ffbfb2eb3d8 Author: Andy Shevchenko Date: Fri Mar 18 14:26:33 2016 +0200 dmaengine: hsu: correct residue calculation of active descriptor commit a197f3c7d48c0c1f45076ea47533a76ba9b1a959 upstream. The commit f0579c8ceaf1 ("dmaengine: hsu: speed up residue calculation") speeded up calculation of the queued descriptor but broke the initial residue value for active descriptor. In accordance with documentation the hardware descriptor is updated each time DMA transfered some bytes. It means we have to calculate a sum of lengths of non-submitted hardware descriptors and whatever current values in the hardware. Do this straightforward. Fixes: f0579c8ceaf1 ("dmaengine: hsu: speed up residue calculation") Signed-off-by: Andy Shevchenko Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit bff35bc72156c845f29a549c12fbec7a3618c739 Author: Andy Shevchenko Date: Fri Mar 18 14:26:32 2016 +0200 dmaengine: hsu: correct use of channel status register commit 4f4bc0abff79dc9d7ccbd3143adbf8ad1f4fe6ab upstream. There is a typo in documentation regarding to descriptor empty bit (DESCE) which is set to 1 when descriptor is empty. Thus, status register at the end of a transfer usually returns all DESCE bits set and thus it will never be zero. Moreover, there are 2 bits (CDESC) that encode current descriptor, on which interrupt has been asserted. In case when we have few descriptors programmed we might have non-zero value. Remove DESCE and CDESC bits from DMA channel status register (HSU_CH_SR) when reading it. Fixes: 2b49e0c56741 ("dmaengine: append hsu DMA driver") Signed-off-by: Andy Shevchenko Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 69903542733aec03b28d9d7ac824ed0cf7ab0a2e Author: Andy Shevchenko Date: Fri Apr 8 16:22:17 2016 +0300 dmaengine: dw: fix master selection commit 3fe6409c23e2bee4b2b1b6d671d2da8daa15271c upstream. The commit 895005202987 ("dmaengine: dw: apply both HS interfaces and remove slave_id usage") cleaned up the code to avoid usage of depricated slave_id member of generic slave configuration. Meanwhile it broke the master selection by removing important call to dwc_set_masters() in ->device_alloc_chan_resources() which copied masters from custom slave configuration to the internal channel structure. Everything works until now since there is no customized connection of DesignWare DMA IP to the bus, i.e. one bus and one or more masters are in use. The configurations where 2 masters are connected to the different masters are not working anymore. We are expecting one user of such configuration and need to select masters properly. Besides that it is obviously a performance regression since only one master is in use in multi-master configuration. Select masters in accordance with what user asked for. Keep this patch in a form more suitable for back porting. We are safe to take necessary data in ->device_alloc_chan_resources() because we don't support generic slave configuration embedded into custom one, and thus the only way to provide such is to use the parameter to a filter function which is called exactly before channel resource allocation. While here, replase BUG_ON to less noisy dev_warn() and prevent channel allocation in case of error. Fixes: 895005202987 ("dmaengine: dw: apply both HS interfaces and remove slave_id usage") Signed-off-by: Andy Shevchenko Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 8200ed1cc49d2dbcc7ea6a455df1627afedda900 Author: Seth Forshee Date: Wed Mar 9 09:18:07 2016 -0600 debugfs: Make automount point inodes permanently empty commit 87243deb88671f70def4c52dfa7ca7830707bd31 upstream. Starting with 4.1 the tracing subsystem has its own filesystem which is automounted in the tracing subdirectory of debugfs. Prior to this debugfs could be bind mounted in a cloned mount namespace, but if tracefs has been mounted under debugfs this now fails because there is a locked child mount. This creates a regression for container software which bind mounts debugfs to satisfy the assumption of some userspace software. In other pseudo filesystems such as proc and sysfs we're already creating mountpoints like this in such a way that no dirents can be created in the directories, allowing them to be exceptions to some MNT_LOCKED tests. In fact we're already do this for the tracefs mountpoint in sysfs. Do the same in debugfs_create_automount(), since the intention here is clearly to create a mountpoint. This fixes the regression, as locked child mounts on permanently empty directories do not cause a bind mount to fail. Signed-off-by: Seth Forshee Acked-by: Serge Hallyn Signed-off-by: Greg Kroah-Hartman commit 8133ecf9cb68089d666616e283136110b6148519 Author: Rui Salvaterra Date: Sat Apr 9 22:05:34 2016 +0100 lib: lz4: fixed zram with lz4 on big endian machines commit 3e26a691fe3fe1e02a76e5bab0c143ace4b137b4 upstream. Based on Sergey's test patch [1], this fixes zram with lz4 compression on big endian cpus. Note that the 64-bit preprocessor test is not a cleanup, it's part of the fix, since those identifiers are bogus (for example, __ppc64__ isn't defined anywhere else in the kernel, which means we'd fall into the 32-bit definitions on ppc64). Tested on ppc64 with no regression on x86_64. [1] http://marc.info/?l=linux-kernel&m=145994470805853&w=4 Suggested-by: Sergey Senozhatsky Signed-off-by: Rui Salvaterra Reviewed-by: Sergey Senozhatsky Signed-off-by: Greg Kroah-Hartman commit 50abecbc50f8e3af5ef384f58183d89fcef6f5d1 Author: Ahmed Samy Date: Sun Apr 17 05:37:09 2016 +0000 dm cache metadata: fix cmd_read_lock() acquiring write lock commit 6545b60baaf880b0cd29a5e89dbe745a06027e89 upstream. Commit 9567366fefdd ("dm cache metadata: fix READ_LOCK macros and cleanup WRITE_LOCK macros") uses down_write() instead of down_read() in cmd_read_lock(), yet up_read() is used to release the lock in READ_UNLOCK(). Fix it. Fixes: 9567366fefdd ("dm cache metadata: fix READ_LOCK macros and cleanup WRITE_LOCK macros") Signed-off-by: Ahmed Samy Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit be5fb2757b1855f55e05e6970d2808ac280ceddd Author: Mike Snitzer Date: Tue Apr 12 12:14:46 2016 -0400 dm cache metadata: fix READ_LOCK macros and cleanup WRITE_LOCK macros commit 9567366fefddeaea4ed1d713270535d93a3b3c76 upstream. The READ_LOCK macro was incorrectly returning -EINVAL if dm_bm_is_read_only() was true -- it will always be true once the cache metadata transitions to read-only by dm_cache_metadata_set_read_only(). Wrap READ_LOCK and WRITE_LOCK multi-statement macros in do {} while(0). Also, all accesses of the 'cmd' argument passed to these related macros are now encapsulated in parenthesis. A follow-up patch can be developed to eliminate the use of macros in favor of pure C code. Avoiding that now given that this needs to apply to stable@. Reported-by: Ben Hutchings Signed-off-by: Mike Snitzer Fixes: d14fcf3dd79 ("dm cache: make sure every metadata function checks fail_io") Signed-off-by: Greg Kroah-Hartman commit b1fb1321ed52927cfddc532af376d16e4abab866 Author: Lars-Peter Clausen Date: Thu Apr 14 17:01:17 2016 +0200 usb: gadget: f_fs: Fix use-after-free commit 38740a5b87d53ceb89eb2c970150f6e94e00373a upstream. When using asynchronous read or write operations on the USB endpoints the issuer of the IO request is notified by calling the ki_complete() callback of the submitted kiocb when the URB has been completed. Calling this ki_complete() callback will free kiocb. Make sure that the structure is no longer accessed beyond that point, otherwise undefined behaviour might occur. Fixes: 2e4c7553cd6f ("usb: gadget: f_fs: add aio support") Signed-off-by: Lars-Peter Clausen Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 2246a752e715afb1cc80c2b4be564420a2301ed9 Author: Robert Dobrowolski Date: Thu Mar 24 03:30:07 2016 -0700 usb: hcd: out of bounds access in for_each_companion commit e86103a75705c7c530768f4ffaba74cf382910f2 upstream. On BXT platform Host Controller and Device Controller figure as same PCI device but with different device function. HCD should not pass data to Device Controller but only to Host Controllers. Checking if companion device is Host Controller, otherwise skip. Signed-off-by: Robert Dobrowolski Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit d3a0db2a8acb66545c1648b19f9fef419c5fb1d0 Author: Peter Griffin Date: Wed Apr 13 19:58:44 2016 +0300 usb: host: xhci-plat: Make enum xhci_plat_type start at a non zero value commit f9a85f6e61c695daeb427dfc6c1d5a279654207b upstream. Otherwise generic-xhci and xhci-platform which have no data get wrongly detected as XHCI_PLAT_TYPE_MARVELL_ARMADA by xhci_plat_type_is(). This fixes a regression in v4.5 for STiH407 family SoC's which use the synopsis dwc3 IP, whereby the disable_clk error path gets taken due to wrongly being detected as XHCI_PLAT_TYPE_MARVELL_ARMADA and the hcd never gets added. I suspect this will also fix other dwc3 DT platforms such as Exynos, although I've only tested on STih410 SoC. Fixes: 4efb2f694114 ("usb: host: xhci-plat: add struct xhci_plat_priv") Cc: gregory.clement@free-electrons.com Cc: yoshihiro.shimoda.uh@renesas.com Signed-off-by: Peter Griffin Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 7786c2f1ffb5e64ec7f7678b6f0f5ac4cbbf45f9 Author: Mathias Nyman Date: Fri Apr 8 16:25:10 2016 +0300 xhci: fix 10 second timeout on removal of PCI hotpluggable xhci controllers commit 98d74f9ceaefc2b6c4a6440050163a83be0abede upstream. PCI hotpluggable xhci controllers such as some Alpine Ridge solutions will remove the xhci controller from the PCI bus when the last USB device is disconnected. Add a flag to indicate that the host is being removed to avoid queueing configure_endpoint commands for the dropped endpoints. For PCI hotplugged controllers this will prevent 5 second command timeouts For static xhci controllers the configure_endpoint command is not needed in the removal case as everything will be returned, freed, and the controller is reset. For now the flag is only set for PCI connected host controllers. Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 46810b1c030ec57830a9939d677bca26c5131451 Author: Lu Baolu Date: Fri Apr 8 16:25:09 2016 +0300 usb: xhci: fix wild pointers in xhci_mem_cleanup commit 71504062a7c34838c3fccd92c447f399d3cb5797 upstream. This patch fixes some wild pointers produced by xhci_mem_cleanup. These wild pointers will cause system crash if xhci_mem_cleanup() is called twice. Reported-and-tested-by: Pengcheng Li Signed-off-by: Lu Baolu Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit cdefb5685abbea5c75b62e38cac5bcde799886eb Author: Yoshihiro Shimoda Date: Fri Apr 8 16:25:08 2016 +0300 usb: host: xhci-plat: fix cannot work if R-Car Gen2/3 run on above 4GB phys commit 5ad3b03e4910f9f62342956ecdc758c7af6b8699 upstream. This patch fixes an issue that cannot work if R-Car Gen2/3 run on above 4GB physical memory environment to use a quirk XHCI_NO_64BIT_SUPPORT. Signed-off-by: Yoshihiro Shimoda Reviewed-by: Felipe Balbi Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 93e64310a349d390b7fd1e38ebdc88c6eb76e6b4 Author: Yoshihiro Shimoda Date: Fri Apr 8 16:25:07 2016 +0300 usb: host: xhci: add a new quirk XHCI_NO_64BIT_SUPPORT commit 0a380be8233dbf8dd20795b801c5d5d5ef3992f7 upstream. On some xHCI controllers (e.g. R-Car SoCs), the AC64 bit (bit 0) of HCCPARAMS1 is set to 1. However, the xHCs don't support 64-bit address memory pointers actually. So, in this case, this driver should call dma_set_coherent_mask(dev, DMA_BIT_MASK(32)) in xhci_gen_setup(). Otherwise, the xHCI controller will be died after a usb device is connected if it runs on above 4GB physical memory environment. So, this patch adds a new quirk XHCI_NO_64BIT_SUPPORT to resolve such an issue. Signed-off-by: Yoshihiro Shimoda Reviewed-by: Felipe Balbi Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 39af3586b3c217db185c26f49b24b756579ea663 Author: Mathias Nyman Date: Fri Apr 8 16:25:06 2016 +0300 xhci: resume USB 3 roothub first commit 671ffdff5b13314b1fc65d62cf7604b873fb5dc4 upstream. Give USB3 devices a better chance to enumerate at USB 3 speeds if they are connected to a suspended host. Solves an issue with NEC uPD720200 host hanging when partially enumerating a USB3 device as USB2 after host controller runtime resume. Tested-by: Mike Murdoch Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 8547d83761dfc36e24c86116a57708ae65c8cd24 Author: Rafal Redzimski Date: Fri Apr 8 16:25:05 2016 +0300 usb: xhci: applying XHCI_PME_STUCK_QUIRK to Intel BXT B0 host commit 0d46faca6f887a849efb07c1655b5a9f7c288b45 upstream. Broxton B0 also requires XHCI_PME_STUCK_QUIRK. Adding PCI device ID for Broxton B and adding to quirk. Signed-off-by: Rafal Redzimski Signed-off-by: Robert Dobrowolski Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 3a8c16abfa42e287b586142297115986b8eeb8fb Author: Jerome Marchand Date: Wed Apr 6 14:06:48 2016 +0100 assoc_array: don't call compare_object() on a node commit 8d4a2ec1e0b41b0cf9a0c5cd4511da7f8e4f3de2 upstream. Changes since V1: fixed the description and added KASan warning. In assoc_array_insert_into_terminal_node(), we call the compare_object() method on all non-empty slots, even when they're not leaves, passing a pointer to an unexpected structure to compare_object(). Currently it causes an out-of-bound read access in keyring_compare_object detected by KASan (see below). The issue is easily reproduced with keyutils testsuite. Only call compare_object() when the slot is a leave. KASan warning: ================================================================== BUG: KASAN: slab-out-of-bounds in keyring_compare_object+0x213/0x240 at addr ffff880060a6f838 Read of size 8 by task keyctl/1655 ============================================================================= BUG kmalloc-192 (Not tainted): kasan: bad access detected ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: Allocated in assoc_array_insert+0xfd0/0x3a60 age=69 cpu=1 pid=1647 ___slab_alloc+0x563/0x5c0 __slab_alloc+0x51/0x90 kmem_cache_alloc_trace+0x263/0x300 assoc_array_insert+0xfd0/0x3a60 __key_link_begin+0xfc/0x270 key_create_or_update+0x459/0xaf0 SyS_add_key+0x1ba/0x350 entry_SYSCALL_64_fastpath+0x12/0x76 INFO: Slab 0xffffea0001829b80 objects=16 used=8 fp=0xffff880060a6f550 flags=0x3fff8000004080 INFO: Object 0xffff880060a6f740 @offset=5952 fp=0xffff880060a6e5d1 Bytes b4 ffff880060a6f730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f740: d1 e5 a6 60 00 88 ff ff 0e 00 00 00 00 00 00 00 ...`............ Object ffff880060a6f750: 02 cf 8e 60 00 88 ff ff 02 c0 8e 60 00 88 ff ff ...`.......`.... Object ffff880060a6f760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f7a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f7b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f7c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f7d0: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f7e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ CPU: 0 PID: 1655 Comm: keyctl Tainted: G B 4.5.0-rc4-kasan+ #291 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 0000000000000000 000000001b2800b4 ffff880060a179e0 ffffffff81b60491 ffff88006c802900 ffff880060a6f740 ffff880060a17a10 ffffffff815e2969 ffff88006c802900 ffffea0001829b80 ffff880060a6f740 ffff880060a6e650 Call Trace: [] dump_stack+0x85/0xc4 [] print_trailer+0xf9/0x150 [] object_err+0x34/0x40 [] kasan_report_error+0x230/0x550 [] ? keyring_get_key_chunk+0x13e/0x210 [] __asan_report_load_n_noabort+0x5d/0x70 [] ? keyring_compare_object+0x213/0x240 [] keyring_compare_object+0x213/0x240 [] assoc_array_insert+0x86c/0x3a60 [] ? assoc_array_cancel_edit+0x70/0x70 [] ? __key_link_begin+0x20d/0x270 [] __key_link_begin+0xfc/0x270 [] key_create_or_update+0x459/0xaf0 [] ? trace_hardirqs_on+0xd/0x10 [] ? key_type_lookup+0xc0/0xc0 [] ? lookup_user_key+0x13d/0xcd0 [] ? memdup_user+0x53/0x80 [] SyS_add_key+0x1ba/0x350 [] ? key_get_type_from_user.constprop.6+0xa0/0xa0 [] ? retint_user+0x18/0x23 [] ? trace_hardirqs_on_caller+0x3fe/0x580 [] ? trace_hardirqs_on_thunk+0x17/0x19 [] entry_SYSCALL_64_fastpath+0x12/0x76 Memory state around the buggy address: ffff880060a6f700: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00 ffff880060a6f780: 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc >ffff880060a6f800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff880060a6f880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff880060a6f900: fc fc fc fc fc fc 00 00 00 00 00 00 00 00 00 00 ================================================================== Signed-off-by: Jerome Marchand Signed-off-by: David Howells Signed-off-by: Greg Kroah-Hartman commit 459c0dc452b63bb22708ffd2235bbb794b912992 Author: Lokesh Vutla Date: Sat Mar 26 23:08:55 2016 -0600 ARM: OMAP2+: hwmod: Fix updating of sysconfig register commit 3ca4a238106dedc285193ee47f494a6584b6fd2f upstream. Commit 127500ccb766f ("ARM: OMAP2+: Only write the sysconfig on idle when necessary") talks about verification of sysconfig cache value before updating it, only during idle path. But the patch is adding the verification in the enable path. So, adding the check in a proper place as per the commit description. Not keeping this check during enable path as there is a chance of losing context and it is safe to do on idle as the context of the register will never be lost while the device is active. Signed-off-by: Lokesh Vutla Acked-by: Tero Kristo Cc: Jon Hunter Fixes: commit 127500ccb766 "ARM: OMAP2+: Only write the sysconfig on idle when necessary" [paul@pwsan.com: appears to have been caused by my own mismerge of the originally posted patch] Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit 66d268b43751cdf5717173c32713db6636edba9e Author: Nishanth Menon Date: Fri Mar 11 10:12:28 2016 -0600 ARM: OMAP2: Fix up interconnect barrier initialization for DRA7 commit 456e8d53482537616899a146b706eccd095404e6 upstream. The following commits: commit 3fa609755c11 ("ARM: omap2: restore OMAP4 barrier behaviour") commit f746929ffdc8 ("Revert "ARM: OMAP4: remove dead kconfig option OMAP4_ERRATA_I688"") and commit ea827ad5ffbb ("ARM: DRA7: Provide proper IO map table") came in around the same time, unfortunately this seem to have missed initializing the barrier for DRA7 platforms - omap5_map_io was reused for dra7 till it was split out by the last patch. barrier_init needs to be hence carried forward as it is valid for DRA7 family of processors as they are for OMAP5. Fixes: ea827ad5ffbb7 ("ARM: DRA7: Provide proper IO map table") Reported-by: Laurent Pinchart Reported-by: Tomi Valkeinen Cc: Russell King Signed-off-by: Nishanth Menon Reviewed-by: Laurent Pinchart Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 786590668743ca69ece4f8090f2f6e76e9abe18a Author: Patrick Uiterwijk Date: Tue Mar 29 16:57:40 2016 +0000 ARM: mvebu: Correct unit address for linksys commit 199831c77c50e6913e893b6bc268ba9f4a9a2bf8 upstream. The USB2 port for Armada 38x is defined to be at 58000, not at 50000. Fixes: 2d0a7addbd10 ("ARM: Kirkwood: Add support for many Synology NAS devices") Signed-off-by: Patrick Uiterwijk Acked-by: Imre Kaloz Signed-off-by: Gregory CLEMENT Signed-off-by: Greg Kroah-Hartman commit 4984953d536352b1d665edb9039ca311931622af Author: Tero Kristo Date: Mon Mar 14 11:01:50 2016 +0200 ARM: dts: am43xx: fix edma memcpy channel allocation commit d41676ddddef27224a398609d874055866694cfa upstream. EDMA was allocating DMA channels 32 and 33 for memcpy usage, out of which channel 33 is actually used by DES crypto engine. This bad allocation of the channel causes a crash in the DES crypto engine, as the channel gets configured for memcpy usage instead of hardware <-> memory DMA. Fixed by allocating DMA channels 58 and 59 for memcpy usage (I2C0 RX/TX), which are not used by anybody. Fixes: cce1ee000187 ("ARM: DTS: am437x: Use the new DT bindings for the eDMA3") Signed-off-by: Tero Kristo Suggested-by: Peter Ujfalusi Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit c8b266e2fa59586a085caf9f50217e2e6e4b2659 Author: Lokesh Vutla Date: Tue Mar 8 12:24:35 2016 +0530 ARM: dts: AM43x-epos: Fix clk parent for synctimer commit cfe1580a6415bc37fd62d79eb8102a618f7650b2 upstream. commit 55ee7017ee31 ("arm: omap2: board-generic: use omap4_local_timer_init for AM437x") makes synctimer32k as the clocksource on AM43xx. By default the synctimer32k is clocked by 32K RTC OSC on AM43xx. But this 32K RTC OSC is not available on epos boards which makes it fail to boot. Synctimer32k can also be clocked by a peripheral PLL, so making this as clock parent for synctimer3k on epos boards. Fixes: 55ee7017ee31 ("arm: omap2: board-generic: use omap4_local_timer_init for AM437x") Reported-by: Nishanth Menon Signed-off-by: Lokesh Vutla Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit dfcaf5d7f967678a6edf08139886c2e1c462bbcf Author: Marc Zyngier Date: Wed Apr 6 09:37:22 2016 +0100 KVM: arm/arm64: Handle forward time correction gracefully commit 1c5631c73fc2261a5df64a72c155cb53dcdc0c45 upstream. On a host that runs NTP, corrections can have a direct impact on the background timer that we program on the behalf of a vcpu. In particular, NTP performing a forward correction will result in a timer expiring sooner than expected from a guest point of view. Not a big deal, we kick the vcpu anyway. But on wake-up, the vcpu thread is going to perform a check to find out whether or not it should block. And at that point, the timer check is going to say "timer has not expired yet, go back to sleep". This results in the timer event being lost forever. There are multiple ways to handle this. One would be record that the timer has expired and let kvm_cpu_has_pending_timer return true in that case, but that would be fairly invasive. Another is to check for the "short sleep" condition in the hrtimer callback, and restart the timer for the remaining time when the condition is detected. This patch implements the latter, with a bit of refactoring in order to avoid too much code duplication. Reported-by: Alexander Graf Reviewed-by: Alexander Graf Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Greg Kroah-Hartman commit f99c7c1717f997db1ae89f6a14809f1312caeb3d Author: David Matlack Date: Wed Mar 30 12:24:47 2016 -0700 kvm: x86: do not leak guest xcr0 into host interrupt handlers commit fc5b7f3bf1e1414bd4e91db6918c85ace0c873a5 upstream. An interrupt handler that uses the fpu can kill a KVM VM, if it runs under the following conditions: - the guest's xcr0 register is loaded on the cpu - the guest's fpu context is not loaded - the host is using eagerfpu Note that the guest's xcr0 register and fpu context are not loaded as part of the atomic world switch into "guest mode". They are loaded by KVM while the cpu is still in "host mode". Usage of the fpu in interrupt context is gated by irq_fpu_usable(). The interrupt handler will look something like this: if (irq_fpu_usable()) { kernel_fpu_begin(); [... code that uses the fpu ...] kernel_fpu_end(); } As long as the guest's fpu is not loaded and the host is using eager fpu, irq_fpu_usable() returns true (interrupted_kernel_fpu_idle() returns true). The interrupt handler proceeds to use the fpu with the guest's xcr0 live. kernel_fpu_begin() saves the current fpu context. If this uses XSAVE[OPT], it may leave the xsave area in an undesirable state. According to the SDM, during XSAVE bit i of XSTATE_BV is not modified if bit i is 0 in xcr0. So it's possible that XSTATE_BV[i] == 1 and xcr0[i] == 0 following an XSAVE. kernel_fpu_end() restores the fpu context. Now if any bit i in XSTATE_BV == 1 while xcr0[i] == 0, XRSTOR generates a #GP. The fault is trapped and SIGSEGV is delivered to the current process. Only pre-4.2 kernels appear to be vulnerable to this sequence of events. Commit 653f52c ("kvm,x86: load guest FPU context more eagerly") from 4.2 forces the guest's fpu to always be loaded on eagerfpu hosts. This patch fixes the bug by keeping the host's xcr0 loaded outside of the interrupts-disabled region where KVM switches into guest mode. Suggested-by: Andy Lutomirski Signed-off-by: David Matlack [Move load after goto cancel_injection. - Paolo] Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 065b9de35b34f83af8a9391b1277f26bb351363d Author: Tony Luck Date: Wed Apr 6 10:05:16 2016 +0200 x86/mce: Avoid using object after free in genpool commit a3125494cff084b098c80bb36fbe2061ffed9d52 upstream. When we loop over all queued machine check error records to pass them to the registered notifiers we use llist_for_each_entry(). But the loop calls gen_pool_free() for the entry in the body of the loop - and then the iterator looks at node->next after the free. Use llist_for_each_entry_safe() instead. Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov Cc: Gong Chen Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-edac Link: http://lkml.kernel.org/r/0205920@agluck-desk.sc.intel.com Link: http://lkml.kernel.org/r/1459929916-12852-4-git-send-email-bp@alien8.de Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 7da29dd44f0240c6b52bacaed5cbf05c2b172364 Author: Ard Biesheuvel Date: Wed Mar 30 09:46:23 2016 +0200 efi/arm64: Don't apply MEMBLOCK_NOMAP to UEFI memory map mapping commit 7cc8cbcf82d165dd658d89a7a287140948e76413 upstream. Commit 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP") updated the mapping logic of both the RuntimeServices regions as well as the kernel's copy of the UEFI memory map to set the MEMBLOCK_NOMAP flag, which causes these regions to be omitted from the kernel direct mapping, and from being covered by a struct page. For the RuntimeServices regions, this is an obvious win, since the contents of these regions have significance to the firmware executable code itself, and are mapped in the EFI page tables using attributes that are described in the UEFI memory map, and which may differ from the attributes we use for mapping system RAM. It also prevents the contents from being modified inadvertently, since the EFI page tables are only live during runtime service invocations. None of these concerns apply to the allocation that covers the UEFI memory map, since it is entirely owned by the kernel. Setting the MEMBLOCK_NOMAP on the region did allow us to use ioremap_cache() to map it both on arm64 and on ARM, since the latter does not allow ioremap_cache() to be used on regions that are covered by a struct page. The ioremap_cache() on ARM restriction will be lifted in the v4.7 timeframe, but in the mean time, it has been reported that commit 4dffbfc48d65 causes a regression on 64k granule kernels. This is due to the fact that, given the 64 KB page size, the region that we end up removing from the kernel direct mapping is rounded up to 64 KB, and this 64 KB page frame may be shared with the initrd when booting via GRUB (which does not align its EFI_LOADER_DATA allocations to 64 KB like the stub does). This will crash the kernel as soon as it tries to access the initrd. Since the issue is specific to arm64, revert back to memblock_reserve()'ing the UEFI memory map when running on arm64. This is a temporary fix for v4.5 and v4.6, and will be superseded in the v4.7 timeframe when we will be able to move back to memblock_reserve() unconditionally. Fixes: 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP") Reported-by: Mark Salter Signed-off-by: Ard Biesheuvel Acked-by: Will Deacon Cc: Leif Lindholm Cc: Mark Rutland Cc: Jeremy Linton Cc: Mark Langsdorf Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit 3e0deff056c7ae5e868b8602ce887e98b943a181 Author: Ming Lei Date: Fri Apr 15 18:51:28 2016 +0800 block: loop: fix filesystem corruption in case of aio/dio commit a7297a6a3a3322b054592e8e988981d2f5f29cc4 upstream. Starting from commit e36f620428(block: split bios to max possible length), block core starts to split bio in the middle of bvec. Unfortunately loop dio/aio doesn't consider this situation, and always treat 'iter.iov_offset' as zero. Then filesystem corruption is observed. This patch figures out the offset of the base bvevc via 'bio->bi_iter.bi_bvec_done' and fixes the issue by passing the offset to iov iterator. Fixes: e36f6204288088f (block: split bios to max possible length) Cc: Keith Busch Cc: Al Viro Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit abe7c54ffae585e09df500aa310a992b2fb41dc8 Author: Ming Lei Date: Wed Mar 30 08:46:31 2016 +0800 block: partition: initialize percpuref before sending out KOBJ_ADD commit b30a337ca27c4f40439e4bfb290cba5f88d73bb7 upstream. The initialization of partition's percpu_ref should have been done before sending out KOBJ_ADD uevent, which may cause userspace to read partition table. So the uninitialized percpu_ref may be accessed in data path. This patch fixes this issue reported by Naveen. Reported-by: Naveen Kaje Tested-by: Naveen Kaje Fixes: 6c71013ecb7e2(block: partition: convert percpu ref) Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 58821da858919f93f85c7e6823b49d439722a9e9 Author: Ulf Hansson Date: Wed Apr 6 16:12:08 2016 +0200 mmc: block: Use the mmc host device index as the mmcblk device index commit 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d upstream. Commit 520bd7a8b415 ("mmc: core: Optimize boot time by detecting cards simultaneously") causes regressions for some platforms. These platforms relies on fixed mmcblk device indexes, instead of deploying the defacto standard with UUID/PARTUUID. In other words their rootfs needs to be available at hardcoded paths, like /dev/mmcblk0p2. Such guarantees have never been made by the kernel, but clearly the above commit changes the behaviour. More precisely, because of that the order changes of how cards becomes detected, so do their corresponding mmcblk device indexes. As the above commit significantly improves boot time for some platforms (magnitude of seconds), let's avoid reverting this change but instead restore the behaviour of how mmcblk device indexes becomes picked. By using the same index for the mmcblk device as for the corresponding mmc host device, the probe order of mmc host devices decides the index we get for the mmcblk device. For those platforms that suffers from a regression, one could expect that this updated behaviour should be sufficient to meet their expectations of "fixed" mmcblk device indexes. Another side effect from this change, is that the same index is used for the mmc host device, the mmcblk device and the mmc block queue. That should clarify their relationship. Reported-by: Peter Hurley Reported-by: Laszlo Fiat Cc: Linus Torvalds Fixes: 520bd7a8b415 ("mmc: core: Optimize boot time by detecting cards simultaneously") Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman