commit bf0679689d25a62f9e425fd51d682855bc04db9b Author: Alexandre Frade Date: Sat Jun 15 10:33:14 2019 -0300 4.19.51-xanmod26 Signed-off-by: Alexandre Frade commit ce73a157b12d51fae90741f19408110fcda4bdf7 Merge: 167decf03751 7aa823a959e1 Author: Alexandre Frade Date: Sat Jun 15 09:54:54 2019 -0300 Merge tag 'v4.19.51' into 4.19 This is the 4.19.51 stable release commit 7aa823a959e1f50c0dab9e01c1940235eccc04cc Author: Greg Kroah-Hartman Date: Sat Jun 15 11:54:11 2019 +0200 Linux 4.19.51 commit b323914cd033f975b5d544b188a3ed1948f02936 Author: Takashi Iwai Date: Fri Apr 12 11:37:19 2019 +0200 ALSA: seq: Cover unsubscribe_port() in list_mutex commit 7c32ae35fbf9cffb7aa3736f44dec10c944ca18e upstream. The call of unsubscribe_port() which manages the group count and module refcount from delete_and_unsubscribe_port() looks racy; it's not covered by the group list lock, and it's likely a cause of the reported unbalance at port deletion. Let's move the call inside the group list_mutex to plug the hole. Reported-by: syzbot+e4c8abb920efa77bace9@syzkaller.appspotmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3af96f3497b7ee087ce2bc5feae1390f57b87dc7 Author: Helen Koike Date: Mon Jun 3 13:56:09 2019 -0300 drm/vc4: fix fb references in async update commit c16b85559dcfb5a348cc085a7b4c75ed49b05e2c upstream. Async update callbacks are expected to set the old_fb in the new_state so prepare/cleanup framebuffers are balanced. Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new fb and put the old fb) is not required, as it's taken care by drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane(). Cc: # v4.19+ Fixes: 539c320bfa97 ("drm/vc4: update cursors asynchronously through atomic") Suggested-by: Boris Brezillon Signed-off-by: Helen Koike Reviewed-by: Boris Brezillon Signed-off-by: Boris Brezillon Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-5-helen.koike@collabora.com Signed-off-by: Greg Kroah-Hartman commit afec706807cd326ab2a5e4d08162cda98eb495a0 Author: Amir Goldstein Date: Wed Feb 27 13:32:11 2019 +0200 ovl: support stacked SEEK_HOLE/SEEK_DATA commit 9e46b840c7053b5f7a245e98cd239b60d189a96c upstream. Overlay file f_pos is the master copy that is preserved through copy up and modified on read/write, but only real fs knows how to SEEK_HOLE/SEEK_DATA and real fs may impose limitations that are more strict than ->s_maxbytes for specific files, so we use the real file to perform seeks. We do not call real fs for SEEK_CUR:0 query and for SEEK_SET:0 requests. Fixes: d1d04ef8572b ("ovl: stack file ops") Reported-by: Eddie Horng Signed-off-by: Amir Goldstein Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 22dac6cc9549fec8ceb82ec1cc6da24a9f5a6705 Author: Jiufei Xue Date: Mon May 6 15:41:02 2019 +0800 ovl: check the capability before cred overridden commit 98487de318a6f33312471ae1e2afa16fbf8361fe upstream. We found that it return success when we set IMMUTABLE_FL flag to a file in docker even though the docker didn't have the capability CAP_LINUX_IMMUTABLE. The commit d1d04ef8572b ("ovl: stack file ops") and dab5ca8fd9dd ("ovl: add lsattr/chattr support") implemented chattr operations on a regular overlay file. ovl_real_ioctl() overridden the current process's subjective credentials with ofs->creator_cred which have the capability CAP_LINUX_IMMUTABLE so that it will return success in vfs_ioctl()->cap_capable(). Fix this by checking the capability before cred overridden. And here we only care about APPEND_FL and IMMUTABLE_FL, so get these information from inode. [SzM: move check and call to underlying fs inside inode locked region to prevent two such calls from racing with each other] Signed-off-by: Jiufei Xue Signed-off-by: Miklos Szeredi Cc: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit b616b9dbc5f613d64224b2e430211211812eadd0 Author: Greg Kroah-Hartman Date: Thu Jun 13 09:36:32 2019 +0200 Revert "drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)" This reverts commit 610382337557bd2057d9b47f996af0b6ff827a2b which is commit b30a43ac7132cdda833ac4b13dd1ebd35ace14b7 upstream. Sven reports: Commit 1e07d63749 ("drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)") has caused a build failure for me when I actually tried that option (CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n): ,---- | Kernel: arch/x86/boot/bzImage is ready (#1) | Building modules, stage 2. | MODPOST 290 modules | ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined! | scripts/Makefile.modpost:91: recipe for target '__modpost' failed `---- Upstream does not have that problem, as commit bed2dd8421 ("drm/ttm: Quick-test mmap offset in ttm_bo_mmap()") has removed the use of drm_legacy_mmap from nouveau_ttm.c. Unfortunately that commit does not apply in 5.1.9. The ensuing discussion proposed a number of one-off patches, but no solid agreement was made, so just revert the commit for now to get people's systems building again. Reported-by: Sven Joachim Cc: Daniel Vetter Cc: Dave Airlie Cc: Thomas Backlund Signed-off-by: Greg Kroah-Hartman commit 8e5483aeae0df86346f975a06c5a381bc4dd97e7 Author: Greg Kroah-Hartman Date: Thu Jun 13 09:28:42 2019 +0200 Revert "Bluetooth: Align minimum encryption key size for LE and BR/EDR connections" This reverts commit 38f092c41cebaff589e88cc22686b289a6840559 which is commit d5bb334a8e171b262e48f378bd2096c0ea458265 upstream. Lots of people have reported issues with this patch, and as there does not seem to be a fix going into Linus's kernel tree any time soon, revert the commit in the stable trees so as to get people's machines working properly again. Reported-by: Vasily Khoruzhick Reported-by: Hans de Goede Cc: Jeremy Cline Cc: Marcel Holtmann Cc: Johan Hedberg Signed-off-by: Greg Kroah-Hartman commit 526972e95ef96cd55313686dbf14202815671f6f Author: Dennis Zhou Date: Thu Feb 21 15:54:11 2019 -0800 percpu: do not search past bitmap when allocating an area [ Upstream commit 8c43004af01635cc9fbb11031d070e5e0d327ef2 ] pcpu_find_block_fit() guarantees that a fit is found within PCPU_BITMAP_BLOCK_BITS. Iteration is used to determine the first fit as it compares against the block's contig_hint. This can lead to incorrectly scanning past the end of the bitmap. The behavior was okay given the check after for bit_off >= end and the correctness of the hints from pcpu_find_block_fit(). This patch fixes this by bounding the end offset by the number of bits in a chunk. Signed-off-by: Dennis Zhou Reviewed-by: Peng Fan Signed-off-by: Sasha Levin commit d4d5dce6d32961a0a2f86352a91b643bb2365d6f Author: Andrey Smirnov Date: Sun Mar 10 23:27:31 2019 -0700 gpio: vf610: Do not share irq_chip [ Upstream commit 338aa10750ba24d04beeaf5dc5efc032e5cf343f ] Fix the warning produced by gpiochip_set_irq_hooks() by allocating a dedicated IRQ chip per GPIO chip/port. Signed-off-by: Andrey Smirnov Cc: Linus Walleij Cc: Bartosz Golaszewski Cc: Chris Healy Cc: Andrew Lunn Cc: Heiner Kallweit Cc: Fabio Estevam Cc: linux-gpio@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-imx@nxp.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 28229df6ad13dd154b62c8c8218cc4a43f974aa3 Author: Takeshi Kihara Date: Thu Feb 28 12:00:48 2019 +0100 soc: renesas: Identify R-Car M3-W ES1.3 [ Upstream commit 15160f6de0bba712fcea078c5ac7571fe33fcd5d ] The Product Register of R-Car M3-W ES1.3 incorrectly identifies the SoC revision as ES2.1. Add a workaround to fix this. Signed-off-by: Takeshi Kihara Signed-off-by: Geert Uytterhoeven Signed-off-by: Simon Horman Signed-off-by: Sasha Levin commit db54e08c5832a74d8d035a38ebc2c37509272e00 Author: Hans de Goede Date: Mon Mar 11 11:48:14 2019 +0100 usb: typec: fusb302: Check vconn is off when we start toggling [ Upstream commit 32a155b1a83d6659e2272e8e1eec199667b1897e ] The datasheet says the vconn MUST be off when we start toggling. The tcpm.c state-machine is responsible to make sure vconn is off, but lets add a WARN to catch any cases where vconn is not off for some reason. Signed-off-by: Hans de Goede Acked-by: Heikki Krogerus Reviewed-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ce183fad3aa844379825372e3768e32c499d491e Author: Marek Szyprowski Date: Mon Feb 18 15:34:12 2019 +0100 ARM: exynos: Fix undefined instruction during Exynos5422 resume [ Upstream commit 4d8e3e951a856777720272ce27f2c738a3eeef8c ] During early system resume on Exynos5422 with performance counters enabled the following kernel oops happens: Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 PID: 1433 Comm: bash Tainted: G W 5.0.0-rc5-next-20190208-00023-gd5fb5a8a13e6-dirty #5480 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) ... Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 4451006a DAC: 00000051 Process bash (pid: 1433, stack limit = 0xb7e0e22f) ... (reset_ctrl_regs) from [] (dbg_cpu_pm_notify+0x1c/0x24) (dbg_cpu_pm_notify) from [] (notifier_call_chain+0x44/0x84) (notifier_call_chain) from [] (__atomic_notifier_call_chain+0x7c/0x128) (__atomic_notifier_call_chain) from [] (cpu_pm_notify+0x30/0x54) (cpu_pm_notify) from [] (syscore_resume+0x98/0x3f4) (syscore_resume) from [] (suspend_devices_and_enter+0x97c/0xe74) (suspend_devices_and_enter) from [] (pm_suspend+0x770/0xc04) (pm_suspend) from [] (state_store+0x6c/0xcc) (state_store) from [] (kobj_attr_store+0x14/0x20) (kobj_attr_store) from [] (sysfs_kf_write+0x4c/0x50) (sysfs_kf_write) from [] (kernfs_fop_write+0xfc/0x1e0) (kernfs_fop_write) from [] (__vfs_write+0x2c/0x160) (__vfs_write) from [] (vfs_write+0xa4/0x16c) (vfs_write) from [] (ksys_write+0x40/0x8c) (ksys_write) from [] (ret_fast_syscall+0x0/0x28) Undefined instruction is triggered during CP14 reset, because bits: #16 (Secure privileged invasive debug disabled) and #17 (Secure privileged noninvasive debug disable) are set in DSCR. Those bits depend on SPNIDEN and SPIDEN lines, which are provided by Secure JTAG hardware block. That block in turn is powered from cluster 0 (big/Eagle), but the Exynos5422 boots on cluster 1 (LITTLE/KFC). To fix this issue it is enough to turn on the power on the cluster 0 for a while. This lets the Secure JTAG block to propagate the needed signals to LITTLE/KFC cores and change their DSCR. Signed-off-by: Marek Szyprowski Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 384642ff64652bfd6cf7ce7eea9dc9702d92d526 Author: Phong Hoang Date: Tue Mar 19 19:40:08 2019 +0900 pwm: Fix deadlock warning when removing PWM device [ Upstream commit 347ab9480313737c0f1aaa08e8f2e1a791235535 ] This patch fixes deadlock warning if removing PWM device when CONFIG_PROVE_LOCKING is enabled. This issue can be reproceduced by the following steps on the R-Car H3 Salvator-X board if the backlight is disabled: # cd /sys/class/pwm/pwmchip0 # echo 0 > export # ls device export npwm power pwm0 subsystem uevent unexport # cd device/driver # ls bind e6e31000.pwm uevent unbind # echo e6e31000.pwm > unbind [ 87.659974] ====================================================== [ 87.666149] WARNING: possible circular locking dependency detected [ 87.672327] 5.0.0 #7 Not tainted [ 87.675549] ------------------------------------------------------ [ 87.681723] bash/2986 is trying to acquire lock: [ 87.686337] 000000005ea0e178 (kn->count#58){++++}, at: kernfs_remove_by_name_ns+0x50/0xa0 [ 87.694528] [ 87.694528] but task is already holding lock: [ 87.700353] 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c [ 87.707405] [ 87.707405] which lock already depends on the new lock. [ 87.707405] [ 87.715574] [ 87.715574] the existing dependency chain (in reverse order) is: [ 87.723048] [ 87.723048] -> #1 (pwm_lock){+.+.}: [ 87.728017] __mutex_lock+0x70/0x7e4 [ 87.732108] mutex_lock_nested+0x1c/0x24 [ 87.736547] pwm_request_from_chip.part.6+0x34/0x74 [ 87.741940] pwm_request_from_chip+0x20/0x40 [ 87.746725] export_store+0x6c/0x1f4 [ 87.750820] dev_attr_store+0x18/0x28 [ 87.754998] sysfs_kf_write+0x54/0x64 [ 87.759175] kernfs_fop_write+0xe4/0x1e8 [ 87.763615] __vfs_write+0x40/0x184 [ 87.767619] vfs_write+0xa8/0x19c [ 87.771448] ksys_write+0x58/0xbc [ 87.775278] __arm64_sys_write+0x18/0x20 [ 87.779721] el0_svc_common+0xd0/0x124 [ 87.783986] el0_svc_compat_handler+0x1c/0x24 [ 87.788858] el0_svc_compat+0x8/0x18 [ 87.792947] [ 87.792947] -> #0 (kn->count#58){++++}: [ 87.798260] lock_acquire+0xc4/0x22c [ 87.802353] __kernfs_remove+0x258/0x2c4 [ 87.806790] kernfs_remove_by_name_ns+0x50/0xa0 [ 87.811836] remove_files.isra.1+0x38/0x78 [ 87.816447] sysfs_remove_group+0x48/0x98 [ 87.820971] sysfs_remove_groups+0x34/0x4c [ 87.825583] device_remove_attrs+0x6c/0x7c [ 87.830197] device_del+0x11c/0x33c [ 87.834201] device_unregister+0x14/0x2c [ 87.838638] pwmchip_sysfs_unexport+0x40/0x4c [ 87.843509] pwmchip_remove+0xf4/0x13c [ 87.847773] rcar_pwm_remove+0x28/0x34 [ 87.852039] platform_drv_remove+0x24/0x64 [ 87.856651] device_release_driver_internal+0x18c/0x21c [ 87.862391] device_release_driver+0x14/0x1c [ 87.867175] unbind_store+0xe0/0x124 [ 87.871265] drv_attr_store+0x20/0x30 [ 87.875442] sysfs_kf_write+0x54/0x64 [ 87.879618] kernfs_fop_write+0xe4/0x1e8 [ 87.884055] __vfs_write+0x40/0x184 [ 87.888057] vfs_write+0xa8/0x19c [ 87.891887] ksys_write+0x58/0xbc [ 87.895716] __arm64_sys_write+0x18/0x20 [ 87.900154] el0_svc_common+0xd0/0x124 [ 87.904417] el0_svc_compat_handler+0x1c/0x24 [ 87.909289] el0_svc_compat+0x8/0x18 [ 87.913378] [ 87.913378] other info that might help us debug this: [ 87.913378] [ 87.921374] Possible unsafe locking scenario: [ 87.921374] [ 87.927286] CPU0 CPU1 [ 87.931808] ---- ---- [ 87.936331] lock(pwm_lock); [ 87.939293] lock(kn->count#58); [ 87.945120] lock(pwm_lock); [ 87.950599] lock(kn->count#58); [ 87.953908] [ 87.953908] *** DEADLOCK *** [ 87.953908] [ 87.959821] 4 locks held by bash/2986: [ 87.963563] #0: 00000000ace7bc30 (sb_writers#6){.+.+}, at: vfs_write+0x188/0x19c [ 87.971044] #1: 00000000287991b2 (&of->mutex){+.+.}, at: kernfs_fop_write+0xb4/0x1e8 [ 87.978872] #2: 00000000f739d016 (&dev->mutex){....}, at: device_release_driver_internal+0x40/0x21c [ 87.988001] #3: 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c [ 87.995481] [ 87.995481] stack backtrace: [ 87.999836] CPU: 0 PID: 2986 Comm: bash Not tainted 5.0.0 #7 [ 88.005489] Hardware name: Renesas Salvator-X board based on r8a7795 ES1.x (DT) [ 88.012791] Call trace: [ 88.015235] dump_backtrace+0x0/0x190 [ 88.018891] show_stack+0x14/0x1c [ 88.022204] dump_stack+0xb0/0xec [ 88.025514] print_circular_bug.isra.32+0x1d0/0x2e0 [ 88.030385] __lock_acquire+0x1318/0x1864 [ 88.034388] lock_acquire+0xc4/0x22c [ 88.037958] __kernfs_remove+0x258/0x2c4 [ 88.041874] kernfs_remove_by_name_ns+0x50/0xa0 [ 88.046398] remove_files.isra.1+0x38/0x78 [ 88.050487] sysfs_remove_group+0x48/0x98 [ 88.054490] sysfs_remove_groups+0x34/0x4c [ 88.058580] device_remove_attrs+0x6c/0x7c [ 88.062671] device_del+0x11c/0x33c [ 88.066154] device_unregister+0x14/0x2c [ 88.070070] pwmchip_sysfs_unexport+0x40/0x4c [ 88.074421] pwmchip_remove+0xf4/0x13c [ 88.078163] rcar_pwm_remove+0x28/0x34 [ 88.081906] platform_drv_remove+0x24/0x64 [ 88.085996] device_release_driver_internal+0x18c/0x21c [ 88.091215] device_release_driver+0x14/0x1c [ 88.095478] unbind_store+0xe0/0x124 [ 88.099048] drv_attr_store+0x20/0x30 [ 88.102704] sysfs_kf_write+0x54/0x64 [ 88.106359] kernfs_fop_write+0xe4/0x1e8 [ 88.110275] __vfs_write+0x40/0x184 [ 88.113757] vfs_write+0xa8/0x19c [ 88.117065] ksys_write+0x58/0xbc [ 88.120374] __arm64_sys_write+0x18/0x20 [ 88.124291] el0_svc_common+0xd0/0x124 [ 88.128034] el0_svc_compat_handler+0x1c/0x24 [ 88.132384] el0_svc_compat+0x8/0x18 The sysfs unexport in pwmchip_remove() is completely asymmetric to what we do in pwmchip_add_with_polarity() and commit 0733424c9ba9 ("pwm: Unexport children before chip removal") is a strong indication that this was wrong to begin with. We should just move pwmchip_sysfs_unexport() where it belongs, which is right after pwmchip_sysfs_unexport_children(). In that case, we do not need separate functions anymore either. We also really want to remove sysfs irrespective of whether or not the chip will be removed as a result of pwmchip_remove(). We can only assume that the driver will be gone after that, so we shouldn't leave any dangling sysfs files around. This warning disappears if we move pwmchip_sysfs_unexport() to the top of pwmchip_remove(), pwmchip_sysfs_unexport_children(). That way it is also outside of the pwm_lock section, which indeed doesn't seem to be needed. Moving the pwmchip_sysfs_export() call outside of that section also seems fine and it'd be perfectly symmetric with pwmchip_remove() again. So, this patch fixes them. Signed-off-by: Phong Hoang [shimoda: revise the commit log and code] Fixes: 76abbdde2d95 ("pwm: Add sysfs interface") Fixes: 0733424c9ba9 ("pwm: Unexport children before chip removal") Signed-off-by: Yoshihiro Shimoda Tested-by: Hoan Nguyen An Reviewed-by: Geert Uytterhoeven Reviewed-by: Simon Horman Reviewed-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 7905b2331338a4085971acfad1cf3fdf3ffc597b Author: Krzysztof Kozlowski Date: Thu Mar 14 21:02:17 2019 +0100 ARM: dts: exynos: Always enable necessary APIO_1V8 and ABB_1V8 regulators on Arndale Octa [ Upstream commit 5ab99cf7d5e96e3b727c30e7a8524c976bd3723d ] The PVDD_APIO_1V8 (LDO2) and PVDD_ABB_1V8 (LDO8) regulators were turned off by Linux kernel as unused. However they supply critical parts of SoC so they should be always on: 1. PVDD_APIO_1V8 supplies SYS pins (gpx[0-3], PSHOLD), HDMI level shift, RTC, VDD1_12 (DRAM internal 1.8 V logic), pull-up for PMIC interrupt lines, TTL/UARTR level shift, reset pins and SW-TACT1 button. It also supplies unused blocks like VDDQ_SRAM (for SROM controller) and VDDQ_GPIO (gpm7, gpy7). The LDO2 cannot be turned off (S2MPS11 keeps it on anyway) so marking it "always-on" only reflects its real status. 2. PVDD_ABB_1V8 supplies Adaptive Body Bias Generator for ARM cores, memory and Mali (G3D). Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 78002e383be74893741285821917d0689120762a Author: Christoph Vogtländer Date: Tue Mar 12 14:38:46 2019 +0530 pwm: tiehrpwm: Update shadow register for disabling PWMs [ Upstream commit b00ef53053191d3025c15e8041699f8c9d132daf ] It must be made sure that immediate mode is not already set, when modifying shadow register value in ehrpwm_pwm_disable(). Otherwise modifications to the action-qualifier continuous S/W force register(AQSFRC) will be done in the active register. This may happen when both channels are being disabled. In this case, only the first channel state will be recorded as disabled in the shadow register. Later, when enabling the first channel again, the second channel would be enabled as well. Setting RLDCSF to zero, first, ensures that the shadow register is updated as desired. Fixes: 38dabd91ff0b ("pwm: tiehrpwm: Fix disabling of output of PWMs") Signed-off-by: Christoph Vogtländer [vigneshr@ti.com: Improve commit message] Signed-off-by: Vignesh Raghavendra Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 9fdcb04e80e1d7a92c7eb23bc0ba1243bc30ddfd Author: Andy Shevchenko Date: Mon Mar 18 18:39:30 2019 +0300 dmaengine: idma64: Use actual device for DMA transfers [ Upstream commit 5ba846b1ee0792f5a596b9b0b86d6e8cdebfab06 ] Intel IOMMU, when enabled, tries to find the domain of the device, assuming it's a PCI one, during DMA operations, such as mapping or unmapping. Since we are splitting the actual PCI device to couple of children via MFD framework (see drivers/mfd/intel-lpss.c for details), the DMA device appears to be a platform one, and thus not an actual one that performs DMA. In a such situation IOMMU can't find or allocate a proper domain for its operations. As a result, all DMA operations are failed. In order to fix this, supply parent of the platform device to the DMA engine framework and fix filter functions accordingly. We may rely on the fact that parent is a real PCI device, because no other configuration is present in the wild. Signed-off-by: Andy Shevchenko Acked-by: Mark Brown Acked-by: Greg Kroah-Hartman [for tty parts] Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit da00c89fce7a04875d1ebdf3c9115226854ff0e6 Author: Brett Creeley Date: Tue Feb 19 15:04:06 2019 -0800 ice: Add missing case in print_link_msg for printing flow control [ Upstream commit 203a068ac9e2722e4d118116acaa3a5586f9468a ] Currently we aren't checking for the ICE_FC_NONE case for the current flow control mode. This is causing "Unknown" to be printed for the current flow control method if flow control is disabled. Fix this by adding the case for ICE_FC_NONE to print "None". Signed-off-by: Brett Creeley Signed-off-by: Anirudh Venkataramanan Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 456e3563725a9dd1e5520cfab897bb4ddd17fe5e Author: Tony Lindgren Date: Mon Mar 25 15:43:18 2019 -0700 gpio: gpio-omap: add check for off wake capable gpios [ Upstream commit da38ef3ed10a09248e13ae16530c2c6d448dc47d ] We are currently assuming all GPIOs are non-wakeup capable GPIOs as we not configuring the bank->non_wakeup_gpios like we used to earlier with platform_data. Let's add omap_gpio_is_off_wakeup_capable() to make the handling clearer while considering that later patches may want to configure SoC specific bank->non_wakeup_gpios for the GPIOs in wakeup domain. Cc: Aaro Koskinen Cc: Grygorii Strashko Cc: Keerthy Cc: Peter Ujfalusi Cc: Russell King Cc: Tero Kristo Reported-by: Grygorii Strashko Signed-off-by: Tony Lindgren Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 47d281bbbff9c7167332bea79bcedc08f863b02f Author: Kangjie Lu Date: Mon Mar 25 17:19:09 2019 -0500 PCI: xilinx: Check for __get_free_pages() failure [ Upstream commit 699ca30162686bf305cdf94861be02eb0cf9bda2 ] If __get_free_pages() fails, return -ENOMEM to avoid a NULL pointer dereference. Signed-off-by: Kangjie Lu Signed-off-by: Lorenzo Pieralisi Reviewed-by: Steven Price Reviewed-by: Mukesh Ojha Signed-off-by: Sasha Levin commit b5a185ee30d7ffe936c9a713779e7e7f05df441c Author: Paolo Valente Date: Tue Mar 12 09:59:27 2019 +0100 block, bfq: increase idling for weight-raised queues [ Upstream commit 778c02a236a8728bb992de10ed1f12c0be5b7b0e ] If a sync bfq_queue has a higher weight than some other queue, and remains temporarily empty while in service, then, to preserve the bandwidth share of the queue, it is necessary to plug I/O dispatching until a new request arrives for the queue. In addition, a timeout needs to be set, to avoid waiting for ever if the process associated with the queue has actually finished its I/O. Even with the above timeout, the device is however not fed with new I/O for a while, if the process has finished its I/O. If this happens often, then throughput drops and latencies grow. For this reason, the timeout is kept rather low: 8 ms is the current default. Unfortunately, such a low value may cause, on the opposite end, a violation of bandwidth guarantees for a process that happens to issue new I/O too late. The higher the system load, the higher the probability that this happens to some process. This is a problem in scenarios where service guarantees matter more than throughput. One important case are weight-raised queues, which need to be granted a very high fraction of the bandwidth. To address this issue, this commit lower-bounds the plugging timeout for weight-raised queues to 20 ms. This simple change provides relevant benefits. For example, on a PLEXTOR PX-256M5S, with which gnome-terminal starts in 0.6 seconds if there is no other I/O in progress, the same applications starts in - 0.8 seconds, instead of 1.2 seconds, if ten files are being read sequentially in parallel - 1 second, instead of 2 seconds, if, in parallel, five files are being read sequentially, and five more files are being written sequentially Tested-by: Holger Hoffstätte Tested-by: Oleksandr Natalenko Signed-off-by: Paolo Valente Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e06d7a92796c50673a07de4e840aac6e8fc6d9c0 Author: Kangjie Lu Date: Mon Apr 1 17:46:58 2019 +0200 video: imsttfb: fix potential NULL pointer dereferences [ Upstream commit 1d84353d205a953e2381044953b7fa31c8c9702d ] In case ioremap fails, the fix releases resources and returns -ENOMEM to avoid NULL pointer dereferences. Signed-off-by: Kangjie Lu Cc: Aditya Pakki Cc: Finn Thain Cc: Rob Herring Cc: Greg Kroah-Hartman [b.zolnierkie: minor patch summary fixup] Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Sasha Levin commit 1f2611af4581a556dff4e99c860e3d1c1c6c3024 Author: Kangjie Lu Date: Mon Apr 1 17:46:58 2019 +0200 video: hgafb: fix potential NULL pointer dereference [ Upstream commit ec7f6aad57ad29e4e66cc2e18e1e1599ddb02542 ] When ioremap fails, hga_vram should not be dereferenced. The fix check the failure to avoid NULL pointer dereference. Signed-off-by: Kangjie Lu Cc: Aditya Pakki Cc: Ferenc Bakonyi [b.zolnierkie: minor patch summary fixup] Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Sasha Levin commit 5957f6f5aaa67ced66e4a50264cfdbf6049f7a4b Author: Giridhar Malavali Date: Tue Apr 2 14:24:22 2019 -0700 scsi: qla2xxx: Reset the FCF_ASYNC_{SENT|ACTIVE} flags [ Upstream commit 0257eda08e806b82ee1fc90ef73583b6f022845c ] Driver maintains state machine for processing and completing switch commands. This patch resets FCF_ASYNC_{SENT|ACTIVE} flag to indicate if the previous command is active or sent, in order for next GPSC command to advance the state machine. [mkp: commit desc typo] Signed-off-by: Giridhar Malavali Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c2c7b6fee389ebf3606f400c30eaa72db6592f41 Author: Marek Vasut Date: Mon Mar 25 12:41:01 2019 +0100 PCI: rcar: Fix 64bit MSI message address handling [ Upstream commit 954b4b752a4c4e963b017ed8cef4c453c5ed308d ] The MSI message address in the RC address space can be 64 bit. The R-Car PCIe RC supports such a 64bit MSI message address as well. The code currently uses virt_to_phys(__get_free_pages()) to obtain a reserved page for the MSI message address, and the return value of which can be a 64 bit physical address on 64 bit system. However, the driver only programs PCIEMSIALR register with the bottom 32 bits of the virt_to_phys(__get_free_pages()) return value and does not program the top 32 bits into PCIEMSIAUR, but rather programs the PCIEMSIAUR register with 0x0. This worked fine on older 32 bit R-Car SoCs, however may fail on new 64 bit R-Car SoCs. Since from a PCIe controller perspective, an inbound MSI is a memory write to a special address (in case of this controller, defined by the value in PCIEMSIAUR:PCIEMSIALR), which triggers an interrupt, but never hits the DRAM _and_ because allocation of an MSI by a PCIe card driver obtains the MSI message address by reading PCIEMSIAUR:PCIEMSIALR in rcar_msi_setup_irqs(), incorrectly programmed PCIEMSIAUR cannot cause memory corruption or other issues. There is however the possibility that if virt_to_phys(__get_free_pages()) returned address above the 32bit boundary _and_ PCIEMSIAUR was programmed to 0x0 _and_ if the system had physical RAM at the address matching the value of PCIEMSIALR, a PCIe card driver could allocate a buffer with a physical address matching the value of PCIEMSIALR and a remote write to such a buffer by a PCIe card would trigger a spurious MSI. Fixes: e015f88c368d ("PCI: rcar: Add support for R-Car H3 to pcie-rcar") Signed-off-by: Marek Vasut Signed-off-by: Lorenzo Pieralisi Reviewed-by: Simon Horman Reviewed-by: Geert Uytterhoeven Cc: Geert Uytterhoeven Cc: Phil Edworthy Cc: Simon Horman Cc: Wolfram Sang Cc: linux-renesas-soc@vger.kernel.org Signed-off-by: Sasha Levin commit dd54e70c47de9ad5d2c966b374f635cad583b266 Author: Kangjie Lu Date: Fri Mar 15 02:29:43 2019 -0500 PCI: rcar: Fix a potential NULL pointer dereference [ Upstream commit f0d14edd2ba43b995bef4dd5da5ffe0ae19321a1 ] In case __get_free_pages() fails and returns NULL, fix the return value to -ENOMEM and release resources to avoid dereferencing a NULL pointer. Signed-off-by: Kangjie Lu Signed-off-by: Lorenzo Pieralisi Reviewed-by: Ulrich Hecht Reviewed-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Sasha Levin commit 272f8c3ddd31e54d33442c8990b084b39b2383ca Author: Peng Li Date: Thu Apr 4 16:17:51 2019 +0800 net: hns3: return 0 and print warning when hit duplicate MAC [ Upstream commit 72110b567479f0282489a9b3747e76d8c67d75f5 ] When set 2 same MAC to different function of one port, IMP will return error as the later one may modify the origin one. This will cause bond fail for 2 VFs of one port. Driver just print warning and return 0 with this patch, so if set same MAC address, it will return 0 but do not really configure HW. Signed-off-by: Peng Li Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5a286ced49117a29e65e47cb43fa878ade7a2a70 Author: Sven Van Asbroeck Date: Fri Feb 15 16:43:02 2019 -0500 power: supply: max14656: fix potential use-before-alloc [ Upstream commit 0cd0e49711556d2331a06b1117b68dd786cb54d2 ] Call order on probe(): - max14656_hw_init() enables interrupts on the chip - devm_request_irq() starts processing interrupts, isr could be called immediately - isr: schedules delayed work (irq_work) - irq_work: calls power_supply_changed() - devm_power_supply_register() registers the power supply Depending on timing, it's possible that power_supply_changed() is called on an unregistered power supply structure. Fix by registering the power supply before requesting the irq. Cc: Alexander Kurz Signed-off-by: Sven Van Asbroeck Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 901daed2f1739fb047aec14d5c2c6df9954874ae Author: Junxiao Chang Date: Mon Apr 8 17:40:22 2019 +0800 platform/x86: intel_pmc_ipc: adding error handling [ Upstream commit e61985d0550df8c2078310202aaad9b41049c36c ] If punit or telemetry device initialization fails, pmc driver should unregister and return failure. This change is to fix a kernel panic when removing kernel module intel_pmc_ipc. Fixes: 48c1917088ba ("platform:x86: Add Intel telemetry platform device") Signed-off-by: Junxiao Chang Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 613752b3a8fba736fb73e12e0e6fa61f0c0f13ea Author: Kabir Sahane Date: Tue Apr 9 08:05:17 2019 -0700 ARM: OMAP2+: pm33xx-core: Do not Turn OFF CEFUSE as PPA may be using it [ Upstream commit 72aff4ecf1cb85a3c6e6b42ccbda0bc631b090b3 ] This area is used to store keys by HSPPA in case of AM438x SOC. Leave it active. Signed-off-by: Kabir Sahane Signed-off-by: Andrew F. Davis Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 668440f6ee3f553252cb52da488d3ac3ba404382 Author: Nicholas Kazlauskas Date: Thu Mar 14 13:46:44 2019 -0400 drm/amd/display: Use plane->color_space for dpp if specified [ Upstream commit a1e07ba89d49581471d64c48152dbe03b42bd025 ] [Why] The input color space for the plane was previously ignored even if it was set. If a limited range YUV format was given to DC then the wrong color transformation matrix was being used since DC assumed that it was full range instead. [How] Respect the given color_space format for the plane if it isn't COLOR_SPACE_UNKNOWN. Otherwise, use the implicit default since DM didn't specify. Signed-off-by: Nicholas Kazlauskas Reviewed-by: Sun peng Li Acked-by: Aric Cyr Acked-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 671fc9007c480ed6e8edbb2126df29dcbb08f3b3 Author: Tyrel Datwyler Date: Fri Mar 22 13:27:21 2019 -0500 PCI: rpadlpar: Fix leaked device_node references in add/remove paths [ Upstream commit fb26228bfc4ce3951544848555c0278e2832e618 ] The find_dlpar_node() helper returns a device node with its reference incremented. Both the add and remove paths use this helper for find the appropriate node, but fail to release the reference when done. Annotate the find_dlpar_node() helper with a comment about the incremented reference count and call of_node_put() on the obtained device_node in the add and remove paths. Also, fixup a reference leak in the find_vio_slot() helper where we fail to call of_node_put() on the vdevice node after we iterate over its children. Signed-off-by: Tyrel Datwyler Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit b531acbd86d2ddb666da973b0441a685f9959115 Author: Andrey Smirnov Date: Thu Mar 28 23:49:16 2019 -0700 ARM: dts: imx6qdl: Specify IMX6QDL_CLK_IPG as "ipg" clock to SDMA [ Upstream commit b14c872eebc501b9640b04f4a152df51d6eaf2fc ] Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX6QDL_CLK_SDMA results in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality(this at least breaks RAVE SP serdev driver on RDU2). Fix the code to specify IMX6QDL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting incorrect clock ratio. Signed-off-by: Andrey Smirnov Reviewed-by: Lucas Stach Cc: Angus Ainslie (Purism) Cc: Chris Healy Cc: Lucas Stach Cc: Fabio Estevam Cc: Shawn Guo Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Tested-by: Adam Ford Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 584cabc69aee9a8ef857015a40d1febc73c75f48 Author: Andrey Smirnov Date: Thu Mar 28 23:49:17 2019 -0700 ARM: dts: imx6sx: Specify IMX6SX_CLK_IPG as "ipg" clock to SDMA [ Upstream commit 8979117765c19edc3b01cc0ef853537bf93eea4b ] Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX6SX_CLK_SDMA results in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality. Fix the code to specify IMX6SX_CLK_IPG as "ipg" clock for SDMA, to avoid detecting incorrect clock ratio. Signed-off-by: Andrey Smirnov Cc: Angus Ainslie (Purism) Cc: Chris Healy Cc: Lucas Stach Cc: Fabio Estevam Cc: Shawn Guo Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 02936545fbea865d6586eef6e13b767240448463 Author: Andrey Smirnov Date: Thu Mar 28 23:49:19 2019 -0700 ARM: dts: imx6ul: Specify IMX6UL_CLK_IPG as "ipg" clock to SDMA [ Upstream commit 7b3132ecefdd1fcdf6b86e62021d0e55ea8034db ] Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX6UL_CLK_SDMA results in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality. Fix the code to specify IMX6UL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting incorrect clock ratio. Signed-off-by: Andrey Smirnov Cc: Angus Ainslie (Purism) Cc: Chris Healy Cc: Lucas Stach Cc: Fabio Estevam Cc: Shawn Guo Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 36a7fda0595b680a6b1a47f85ba7e0bda821b2c3 Author: Andrey Smirnov Date: Thu Mar 28 23:49:18 2019 -0700 ARM: dts: imx7d: Specify IMX7D_CLK_IPG as "ipg" clock to SDMA [ Upstream commit 412b032a1dc72fc9d1c258800355efa6671b6315 ] Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX7D_CLK_SDMA results in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality. Fix the code to specify IMX7D_CLK_IPG as "ipg" clock for SDMA, to avoid detecting incorrect clock ratio. Signed-off-by: Andrey Smirnov Cc: Angus Ainslie (Purism) Cc: Chris Healy Cc: Lucas Stach Cc: Fabio Estevam Cc: Shawn Guo Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit c84911bb39d172be7d34b6593e9adb1919f78aab Author: Andrey Smirnov Date: Thu Mar 28 23:49:20 2019 -0700 ARM: dts: imx6sll: Specify IMX6SLL_CLK_IPG as "ipg" clock to SDMA [ Upstream commit c5ed5daa65d5f665e666b76c3dbfa503066defde ] Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX6SLL_CLK_SDMA result in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality. Fix the code to specify IMX6SLL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting incorrect clock ratio. Signed-off-by: Andrey Smirnov Cc: Angus Ainslie (Purism) Cc: Chris Healy Cc: Lucas Stach Cc: Fabio Estevam Cc: Shawn Guo Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit a2e661f99c4da6021e5f661f0abb705731c7b1ac Author: Andrey Smirnov Date: Thu Mar 28 23:49:21 2019 -0700 ARM: dts: imx6sx: Specify IMX6SX_CLK_IPG as "ahb" clock to SDMA [ Upstream commit cc839d0f8c284fcb7591780b568f13415bbb737c ] Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX6SL_CLK_SDMA results in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality. Fix the code to specify IMX6SL_CLK_AHB as "ahb" clock for SDMA, to avoid detecting incorrect clock ratio. Signed-off-by: Andrey Smirnov Cc: Angus Ainslie (Purism) Cc: Chris Healy Cc: Lucas Stach Cc: Fabio Estevam Cc: Shawn Guo Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 461f4183926caf97201d9c255e53c86173bad79e Author: Andrey Smirnov Date: Thu Mar 28 23:49:22 2019 -0700 ARM: dts: imx53: Specify IMX5_CLK_IPG as "ahb" clock to SDMA [ Upstream commit 28c168018e0902c67eb9c60d0fc4c8aa166c4efe ] Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX5_CLK_SDMA results in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality. Fix the code to specify IMX5_CLK_AHB as "ahb" clock for SDMA, to avoid detecting incorrect clock ratio. Signed-off-by: Andrey Smirnov Cc: Angus Ainslie (Purism) Cc: Chris Healy Cc: Lucas Stach Cc: Fabio Estevam Cc: Shawn Guo Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 998860d0384d3719d3e0fed665f8f192a1b79315 Author: Andrey Smirnov Date: Thu Mar 28 23:49:24 2019 -0700 ARM: dts: imx50: Specify IMX5_CLK_IPG as "ahb" clock to SDMA [ Upstream commit b7b4fda2636296471e29b78c2aa9535d7bedb7a0 ] Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX5_CLK_SDMA results in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality. Fix the code to specify IMX5_CLK_AHB as "ahb" clock for SDMA, to avoid detecting incorrect clock ratio. Signed-off-by: Andrey Smirnov Cc: Angus Ainslie (Purism) Cc: Chris Healy Cc: Lucas Stach Cc: Fabio Estevam Cc: Shawn Guo Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 70465bbbaeae2ed7f5359cd52704cae4fbdac63f Author: Andrey Smirnov Date: Thu Mar 28 23:49:23 2019 -0700 ARM: dts: imx51: Specify IMX5_CLK_IPG as "ahb" clock to SDMA [ Upstream commit 918bbde8085ae147a43dcb491953e0dd8f3e9d6a ] Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX5_CLK_SDMA results in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality. Fix the code to specify IMX5_CLK_AHB as "ahb" clock for SDMA, to avoid detecting incorrect clock ratio. Signed-off-by: Andrey Smirnov Cc: Angus Ainslie (Purism) Cc: Chris Healy Cc: Lucas Stach Cc: Fabio Estevam Cc: Shawn Guo Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 57f89084a7e15f6218b3a874d8fcfce4e632da5a Author: Douglas Anderson Date: Tue Apr 9 13:49:05 2019 -0700 soc: rockchip: Set the proper PWM for rk3288 [ Upstream commit bbdc00a7de24cc90315b1775fb74841373fe12f7 ] The rk3288 SoC has two PWM implementations available, the "old" implementation and the "new" one. You can switch between the two of them by flipping a bit in the grf. The "old" implementation is the default at chip power up but isn't the one that's officially supposed to be used. ...and, in fact, the driver that gets selected in Linux using the rk3288 device tree only supports the "new" implementation. Long ago I tried to get a switch to the right IP block landed in the PWM driver (search for "rk3288: Switch to use the proper PWM IP") but that got rejected. In the mean time the grf has grown a full-fledged driver that already sets other random bits like this. That means we can now get the fix landed. For those wondering how things could have possibly worked for the last 4.5 years, folks have mostly been relying on the bootloader to set this bit. ...but occasionally folks have pointed back to my old patch series [1] in downstream kernels. [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1391597.html Signed-off-by: Douglas Anderson Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit b16594860a304afde0c43876c327b967947aaabc Author: Douglas Anderson Date: Thu Apr 11 16:21:53 2019 -0700 clk: rockchip: Turn on "aclk_dmac1" for suspend on rk3288 [ Upstream commit 57a20248ef3e429dc822f0774bc4e00136c46c83 ] Experimentally it can be seen that going into deep sleep (specifically setting PMU_CLR_DMA and PMU_CLR_BUS in RK3288_PMU_PWRMODE_CON1) appears to fail unless "aclk_dmac1" is on. The failure is that the system never signals that it made it into suspend on the GLOBAL_PWROFF pin and it just hangs. NOTE that it's confirmed that it's the actual suspend that fails, not one of the earlier calls to read/write registers. Specifically if you comment out the "PMU_GLOBAL_INT_DISABLE" setting in rk3288_slp_mode_set() and then comment out the "cpu_do_idle()" call in rockchip_lpmode_enter() then you can exercise the whole suspend path without any crashing. This is currently not a problem with suspend upstream because there is no current way to exercise the deep suspend code. However, anyone trying to make it work will run into this issue. This was not a problem on shipping rk3288-based Chromebooks because those devices all ran on an old kernel based on 3.14. On that kernel "aclk_dmac1" appears to be left on all the time. There are several ways to skin this problem. A) We could add "aclk_dmac1" to the list of critical clocks and that apperas to work, but presumably that wastes power. B) We could keep a list of "struct clk" objects to enable at suspend time in clk-rk3288.c and use the standard clock APIs. C) We could make the rk3288-pmu driver keep a list of clocks to enable at suspend time. Presumably this would require a dts and bindings change. D) We could just whack the clock on in the existing syscore suspend function where we whack a bunch of other clocks. This is particularly easy because we know for sure that the clock's only parent ("aclk_cpu") is a critical clock so we don't need to do anything more than ungate it. In this case I have chosen D) because it seemed like the least work, but any of the other options would presumably also work fine. Signed-off-by: Douglas Anderson Reviewed-by: Elaine Zhang Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 8e9dd864d6a7a5b65d91cdd735b81cf5d1c3ea1b Author: Nathan Chancellor Date: Thu Mar 7 15:56:51 2019 -0700 soc: mediatek: pwrap: Zero initialize rdata in pwrap_init_cipher [ Upstream commit 89e28da82836530f1ac7a3a32fecc31f22d79b3e ] When building with -Wsometimes-uninitialized, Clang warns: drivers/soc/mediatek/mtk-pmic-wrap.c:1358:6: error: variable 'rdata' is used uninitialized whenever '||' condition is true [-Werror,-Wsometimes-uninitialized] If pwrap_write returns non-zero, pwrap_read will not be called to initialize rdata, meaning that we will use some random uninitialized stack value in our print statement. Zero initialize rdata in case this happens. Link: https://github.com/ClangBuiltLinux/linux/issues/401 Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Reviewed-by: Arnd Bergmann Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit f7c0e67054d82df072a3b315f0827b7eef4df3c4 Author: Kishon Vijay Abraham I Date: Mon Mar 25 15:09:33 2019 +0530 PCI: keystone: Prevent ARM32 specific code to be compiled for ARM64 [ Upstream commit f316a2b53cd7f37963ae20ec7072eb27a349a4ce ] hook_fault_code() is an ARM32 specific API for hooking into data abort. AM65X platforms (that integrate ARM v8 cores and select CONFIG_ARM64 as arch) rely on pci-keystone.c but on them the enumeration of a non-present BDF does not trigger a bus error, so the fixup exception provided by calling hook_fault_code() is not needed and can be guarded with CONFIG_ARM. Signed-off-by: Kishon Vijay Abraham I [lorenzo.pieralisi@arm.com: commit log] Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit a357310a5774305665a12af7aeb6828fc79bb4bc Author: Enrico Granata Date: Wed Apr 3 15:40:36 2019 -0700 platform/chrome: cros_ec_proto: check for NULL transfer function [ Upstream commit 94d4e7af14a1170e34cf082d92e4c02de9e9fb88 ] As new transfer mechanisms are added to the EC codebase, they may not support v2 of the EC protocol. If the v3 initial handshake transfer fails, the kernel will try and call cmd_xfer as a fallback. If v2 is not supported, cmd_xfer will be NULL, and the code will end up causing a kernel panic. Add a check for NULL before calling the transfer function, along with a helpful comment explaining how one might end up in this situation. Signed-off-by: Enrico Granata Reviewed-by: Jett Rink Signed-off-by: Enric Balletbo i Serra Signed-off-by: Sasha Levin commit b78a9b2818d5dd5888a5714556a7a34f9f645fc9 Author: Adam Ludkiewicz Date: Wed Feb 6 15:08:15 2019 -0800 i40e: Queues are reserved despite "Invalid argument" error [ Upstream commit 3e957b377bf4262aec2dd424f28ece94e36814d4 ] Added a new local variable in the i40e_setup_tc function named old_queue_pairs so num_queue_pairs can be restored to the correct value in case configuring queue channels fails. Additionally, moved the exit label in the i40e_setup_tc function so the if (need_reset) block can be executed. Also, fixed data packing in the i40e_setup_tc function. Signed-off-by: Adam Ludkiewicz Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit aeb743dbe9360aa8b37b725550df1b3811b21fa6 Author: Wenwen Wang Date: Wed Apr 17 09:18:50 2019 -0500 x86/PCI: Fix PCI IRQ routing table memory leak [ Upstream commit ea094d53580f40c2124cef3d072b73b2425e7bfd ] In pcibios_irq_init(), the PCI IRQ routing table 'pirq_table' is first found through pirq_find_routing_table(). If the table is not found and CONFIG_PCI_BIOS is defined, the table is then allocated in pcibios_get_irq_routing_table() using kmalloc(). Later, if the I/O APIC is used, this table is actually not used. In that case, the allocated table is not freed, which is a memory leak. Free the allocated table if it is not used. Signed-off-by: Wenwen Wang [bhelgaas: added Ingo's reviewed-by, since the only change since v1 was to use the irq_routing_table local variable name he suggested] Signed-off-by: Bjorn Helgaas Reviewed-by: Ingo Molnar Acked-by: Thomas Gleixner Signed-off-by: Sasha Levin commit 47e6a354e24881c89e936393459ae39a98c4c9de Author: Mika Westerberg Date: Fri Sep 28 12:21:17 2018 +0300 net: thunderbolt: Unregister ThunderboltIP protocol handler when suspending [ Upstream commit 9872760eb7b1d4f6066ad8b560714a5d0a728fdb ] The XDomain protocol messages may start as soon as Thunderbolt control channel is started. This means that if the other host starts sending ThunderboltIP packets early enough they will be passed to the network driver which then gets confused because its resume hook is not called yet. Fix this by unregistering the ThunderboltIP protocol handler when suspending and registering it back on resume. Signed-off-by: Mika Westerberg Acked-by: David S. Miller Signed-off-by: Sasha Levin commit 31aa2a7a8566fac337d976d9da62d12cfafa8611 Author: Wesley Sheng Date: Mon Apr 15 22:41:42 2019 +0800 switchtec: Fix unintended mask of MRPC event [ Upstream commit 083c1b5e50b701899dc32445efa8b153685260d5 ] When running application tool switchtec-user's `firmware update` and `event wait` commands concurrently, sometimes the firmware update speed reduced significantly. It is because when the MRPC event happened after MRPC event occurrence check but before the event mask loop reaches its header register in event ISR, the MRPC event would be masked unintentionally. Since there's no chance to enable it again except for a module reload, all the following MRPC execution completion checks time out. Fix this bug by skipping the mask operation for MRPC event in event ISR, same as what we already do for LINK event. Fixes: 52eabba5bcdb ("switchtec: Add IOCTLs to the Switchtec driver") Signed-off-by: Wesley Sheng Signed-off-by: Bjorn Helgaas Reviewed-by: Logan Gunthorpe Signed-off-by: Sasha Levin commit 4b19a45eed4d32ca9ec50da0ebc4ea582032e331 Author: Will Deacon Date: Tue Apr 23 11:59:36 2019 +0100 iommu/arm-smmu-v3: Don't disable SMMU in kdump kernel [ Upstream commit 3f54c447df34ff9efac7809a4a80fd3208efc619 ] Disabling the SMMU when probing from within a kdump kernel so that all incoming transactions are terminated can prevent the core of the crashed kernel from being transferred off the machine if all I/O devices are behind the SMMU. Instead, continue to probe the SMMU after it is disabled so that we can reinitialise it entirely and re-attach the DMA masters as they are reset. Since the kdump kernel may not have drivers for all of the active DMA masters, we suppress fault reporting to avoid spamming the console and swamping the IRQ threads. Reported-by: "Leizhen (ThunderTown)" Tested-by: "Leizhen (ThunderTown)" Tested-by: Bhupesh Sharma Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit f7883f9b5a6777f1b1a19c82aa42978181300f3b Author: Farhan Ali Date: Wed Apr 3 14:22:27 2019 -0400 vfio: Fix WARNING "do not call blocking ops when !TASK_RUNNING" [ Upstream commit 41be3e2618174fdf3361e49e64f2bf530f40c6b0 ] vfio_dev_present() which is the condition to wait_event_interruptible_timeout(), will call vfio_group_get_device and try to acquire the mutex group->device_lock. wait_event_interruptible_timeout() will set the state of the current task to TASK_INTERRUPTIBLE, before doing the condition check. This means that we will try to acquire the mutex while already in a sleeping state. The scheduler warns us by giving the following warning: [ 4050.264464] ------------[ cut here ]------------ [ 4050.264508] do not call blocking ops when !TASK_RUNNING; state=1 set at [<00000000b33c00e2>] prepare_to_wait_event+0x14a/0x188 [ 4050.264529] WARNING: CPU: 12 PID: 35924 at kernel/sched/core.c:6112 __might_sleep+0x76/0x90 .... 4050.264756] Call Trace: [ 4050.264765] ([<000000000017bbaa>] __might_sleep+0x72/0x90) [ 4050.264774] [<0000000000b97edc>] __mutex_lock+0x44/0x8c0 [ 4050.264782] [<0000000000b9878a>] mutex_lock_nested+0x32/0x40 [ 4050.264793] [<000003ff800d7abe>] vfio_group_get_device+0x36/0xa8 [vfio] [ 4050.264803] [<000003ff800d87c0>] vfio_del_group_dev+0x238/0x378 [vfio] [ 4050.264813] [<000003ff8015f67c>] mdev_remove+0x3c/0x68 [mdev] [ 4050.264825] [<00000000008e01b0>] device_release_driver_internal+0x168/0x268 [ 4050.264834] [<00000000008de692>] bus_remove_device+0x162/0x190 [ 4050.264843] [<00000000008daf42>] device_del+0x1e2/0x368 [ 4050.264851] [<00000000008db12c>] device_unregister+0x64/0x88 [ 4050.264862] [<000003ff8015ed84>] mdev_device_remove+0xec/0x130 [mdev] [ 4050.264872] [<000003ff8015f074>] remove_store+0x6c/0xa8 [mdev] [ 4050.264881] [<000000000046f494>] kernfs_fop_write+0x14c/0x1f8 [ 4050.264890] [<00000000003c1530>] __vfs_write+0x38/0x1a8 [ 4050.264899] [<00000000003c187c>] vfs_write+0xb4/0x198 [ 4050.264908] [<00000000003c1af2>] ksys_write+0x5a/0xb0 [ 4050.264916] [<0000000000b9e270>] system_call+0xdc/0x2d8 [ 4050.264925] 4 locks held by sh/35924: [ 4050.264933] #0: 000000001ef90325 (sb_writers#4){.+.+}, at: vfs_write+0x9e/0x198 [ 4050.264948] #1: 000000005c1ab0b3 (&of->mutex){+.+.}, at: kernfs_fop_write+0x1cc/0x1f8 [ 4050.264963] #2: 0000000034831ab8 (kn->count#297){++++}, at: kernfs_remove_self+0x12e/0x150 [ 4050.264979] #3: 00000000e152484f (&dev->mutex){....}, at: device_release_driver_internal+0x5c/0x268 [ 4050.264993] Last Breaking-Event-Address: [ 4050.265002] [<000000000017bbaa>] __might_sleep+0x72/0x90 [ 4050.265010] irq event stamp: 7039 [ 4050.265020] hardirqs last enabled at (7047): [<00000000001cee7a>] console_unlock+0x6d2/0x740 [ 4050.265029] hardirqs last disabled at (7054): [<00000000001ce87e>] console_unlock+0xd6/0x740 [ 4050.265040] softirqs last enabled at (6416): [<0000000000b8fe26>] __udelay+0xb6/0x100 [ 4050.265049] softirqs last disabled at (6415): [<0000000000b8fe06>] __udelay+0x96/0x100 [ 4050.265057] ---[ end trace d04a07d39d99a9f9 ]--- Let's fix this as described in the article https://lwn.net/Articles/628628/. Signed-off-by: Farhan Ali [remove now redundant vfio_dev_present()] Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 806e83958482b7f197e20fe965a05281998bd1fd Author: Arnd Bergmann Date: Fri Mar 22 15:07:11 2019 +0100 nfsd: avoid uninitialized variable warning [ Upstream commit 0ab88ca4bcf18ba21058d8f19220f60afe0d34d8 ] clang warns that 'contextlen' may be accessed without an initialization: fs/nfsd/nfs4xdr.c:2911:9: error: variable 'contextlen' is uninitialized when used here [-Werror,-Wuninitialized] contextlen); ^~~~~~~~~~ fs/nfsd/nfs4xdr.c:2424:16: note: initialize the variable 'contextlen' to silence this warning int contextlen; ^ = 0 Presumably this cannot happen, as FATTR4_WORD2_SECURITY_LABEL is set if CONFIG_NFSD_V4_SECURITY_LABEL is enabled. Adding another #ifdef like the other two in this function avoids the warning. Signed-off-by: Arnd Bergmann Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit b4330e4a7c129106070e244424f7fcfe30f80c0c Author: J. Bruce Fields Date: Fri Apr 12 16:37:30 2019 -0400 nfsd: allow fh_want_write to be called twice [ Upstream commit 0b8f62625dc309651d0efcb6a6247c933acd8b45 ] A fuzzer recently triggered lockdep warnings about potential sb_writers deadlocks caused by fh_want_write(). Looks like we aren't careful to pair each fh_want_write() with an fh_drop_write(). It's not normally a problem since fh_put() will call fh_drop_write() for us. And was OK for NFSv3 where we'd do one operation that might call fh_want_write(), and then put the filehandle. But an NFSv4 protocol fuzzer can do weird things like call unlink twice in a compound, and then we get into trouble. I'm a little worried about this approach of just leaving everything to fh_put(). But I think there are probably a lot of fh_want_write()/fh_drop_write() imbalances so for now I think we need it to be more forgiving. Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit ae35c325d8fda01844dc5ec64bcc1a9c9208e155 Author: Kirill Smelkov Date: Wed Mar 27 10:15:19 2019 +0000 fuse: retrieve: cap requested size to negotiated max_write [ Upstream commit 7640682e67b33cab8628729afec8ca92b851394f ] FUSE filesystem server and kernel client negotiate during initialization phase, what should be the maximum write size the client will ever issue. Correspondingly the filesystem server then queues sys_read calls to read requests with buffer capacity large enough to carry request header + that max_write bytes. A filesystem server is free to set its max_write in anywhere in the range between [1*page, fc->max_pages*page]. In particular go-fuse[2] sets max_write by default as 64K, wheres default fc->max_pages corresponds to 128K. Libfuse also allows users to configure max_write, but by default presets it to possible maximum. If max_write is < fc->max_pages*page, and in NOTIFY_RETRIEVE handler we allow to retrieve more than max_write bytes, corresponding prepared NOTIFY_REPLY will be thrown away by fuse_dev_do_read, because the filesystem server, in full correspondence with server/client contract, will be only queuing sys_read with ~max_write buffer capacity, and fuse_dev_do_read throws away requests that cannot fit into server request buffer. In turn the filesystem server could get stuck waiting indefinitely for NOTIFY_REPLY since NOTIFY_RETRIEVE handler returned OK which is understood by clients as that NOTIFY_REPLY was queued and will be sent back. Cap requested size to negotiate max_write to avoid the problem. This aligns with the way NOTIFY_RETRIEVE handler works, which already unconditionally caps requested retrieve size to fuse_conn->max_pages. This way it should not hurt NOTIFY_RETRIEVE semantic if we return less data than was originally requested. Please see [1] for context where the problem of stuck filesystem was hit for real, how the situation was traced and for more involving patch that did not make it into the tree. [1] https://marc.info/?l=linux-fsdevel&m=155057023600853&w=2 [2] https://github.com/hanwen/go-fuse Signed-off-by: Kirill Smelkov Cc: Han-Wen Nienhuys Cc: Jakob Unterwurzacher Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 1c2e974628d1edeb45896456b6f0ea7c5c4df340 Author: Chen-Yu Tsai Date: Sat Apr 13 11:32:53 2019 +0100 nvmem: sunxi_sid: Support SID on A83T and H5 [ Upstream commit da75b8909756160b8e785104ba421a20b756c975 ] The device tree binding already lists compatible strings for these two SoCs. They don't have the defect as seen on the H3, and the size and register layout is the same as the A64. Furthermore, the driver does not include nvmem cell definitions. Add support for these two compatible strings, re-using the config for the A64. Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard Signed-off-by: Srinivas Kandagatla Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0412a8857198b7ac749041cf7e825e6e13c63df5 Author: Jorge Ramirez-Ortiz Date: Sat Apr 13 11:32:58 2019 +0100 nvmem: core: fix read buffer in place [ Upstream commit 2fe518fecb3a4727393be286db9804cd82ee2d91 ] When the bit_offset in the cell is zero, the pointer to the msb will not be properly initialized (ie, will still be pointing to the first byte in the buffer). This being the case, if there are bits to clear in the msb, those will be left untouched while the mask will incorrectly clear bit positions on the first byte. This commit also makes sure that any byte unused in the cell is cleared. Signed-off-by: Jorge Ramirez-Ortiz Signed-off-by: Srinivas Kandagatla Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 962ce4023178b363beeb4ebe8218379b7ca36d6b Author: Takashi Iwai Date: Tue Apr 30 12:18:28 2019 +0200 ALSA: hda - Register irq handler after the chip initialization [ Upstream commit f495222e28275222ab6fd93813bd3d462e16d340 ] Currently the IRQ handler in HD-audio controller driver is registered before the chip initialization. That is, we have some window opened between the azx_acquire_irq() call and the CORB/RIRB setup. If an interrupt is triggered in this small window, the IRQ handler may access to the uninitialized RIRB buffer, which leads to a NULL dereference Oops. This is usually no big problem since most of Intel chips do register the IRQ via MSI, and we've already fixed the order of the IRQ enablement and the CORB/RIRB setup in the former commit b61749a89f82 ("sound: enable interrupt after dma buffer initialization"), hence the IRQ won't be triggered in that room. However, some platforms use a shared IRQ, and this may allow the IRQ trigger by another source. Another possibility is the kdump environment: a stale interrupt might be present in there, the IRQ handler can be falsely triggered as well. For covering this small race, let's move the azx_acquire_irq() call after hda_intel_init_chip() call. Although this is a bit radical change, it can cover more widely than checking the CORB/RIRB setup locally in the callee side. Reported-by: Liwei Song Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 028b3d8d549e276ffa34835aeb2c2a18c98e7ca3 Author: Taehee Yoo Date: Tue Apr 30 01:55:29 2019 +0900 netfilter: nf_flow_table: fix netdev refcnt leak [ Upstream commit 26a302afbe328ecb7507cae2035d938e6635131b ] flow_offload_alloc() calls nf_route() to get a dst_entry. Internally, nf_route() calls ip_route_output_key() that allocates a dst_entry and holds it. So, a dst_entry should be released by dst_release() if nf_route() is successful. Otherwise, netns exit routine cannot be finished and the following message is printed: [ 257.490952] unregister_netdevice: waiting for lo to become free. Usage count = 1 Fixes: ac2a66665e23 ("netfilter: add generic flow table infrastructure") Signed-off-by: Taehee Yoo Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 650a4b7c5d66f47b7adf0ce851ab2ff49248f4c0 Author: Taehee Yoo Date: Tue Apr 30 01:55:54 2019 +0900 netfilter: nf_flow_table: check ttl value in flow offload data path [ Upstream commit 33cc3c0cfa64c86b6c4bbee86997aea638534931 ] nf_flow_offload_ip_hook() and nf_flow_offload_ipv6_hook() do not check ttl value. So, ttl value overflow may occur. Fixes: 97add9f0d66d ("netfilter: flow table support for IPv4") Fixes: 0995210753a2 ("netfilter: flow table support for IPv6") Signed-off-by: Taehee Yoo Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 52d7b067fadf8b66eabd6101338a871e14e872df Author: Keith Busch Date: Tue Apr 30 09:33:40 2019 -0600 nvme-pci: shutdown on timeout during deletion [ Upstream commit 9dc1a38ef1925d23c2933c5867df816386d92ff8 ] We do not restart a controller in a deleting state for timeout errors. When in this state, unblock potential request dispatchers with failed completions by shutting down the controller on timeout detection. Reported-by: Yufen Yu Signed-off-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 6ce2ad24ae9c3f88692fbbe0d8223133c67b2aac Author: Keith Busch Date: Tue Apr 30 09:33:41 2019 -0600 nvme-pci: unquiesce admin queue on shutdown [ Upstream commit c8e9e9b7646ebe1c5066ddc420d7630876277eb4 ] Just like IO queues, the admin queue also will not be restarted after a controller shutdown. Unquiesce this queue so that we do not block request dispatch on a permanently disabled controller. Reported-by: Yufen Yu Signed-off-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit e9db931283fdebe67fc7372f4dc231f1a535b0b7 Author: Kishon Vijay Abraham I Date: Mon Mar 25 15:09:45 2019 +0530 PCI: designware-ep: Use aligned ATU window for raising MSI interrupts [ Upstream commit 6b7330303a8186fb211357e6d379237fe9d2ece1 ] Certain platforms like K2G reguires the outbound ATU window to be aligned. The alignment size is already present in mem->page_size. Use the alignment size present in mem->page_size to configure an aligned ATU window. In order to raise an interrupt, CPU has to write to address offset from the start of the window unlike before where writes were always to the beginning of the ATU window. Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit a7f27994b20709d27f83deda48a5d0eca427bf75 Author: Kishon Vijay Abraham I Date: Mon Mar 25 15:09:47 2019 +0530 misc: pci_endpoint_test: Fix test_reg_bar to be updated in pci_endpoint_test [ Upstream commit 8f220664570e755946db1282f48e07f26e1f2cb4 ] commit 834b90519925 ("misc: pci_endpoint_test: Add support for PCI_ENDPOINT_TEST regs to be mapped to any BAR") while adding test_reg_bar in order to map PCI_ENDPOINT_TEST regs to be mapped to any BAR failed to update test_reg_bar in pci_endpoint_test, resulting in test_reg_bar having invalid value when used outside probe. Fix it. Fixes: 834b90519925 ("misc: pci_endpoint_test: Add support for PCI_ENDPOINT_TEST regs to be mapped to any BAR") Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit ed6efdb74438e806ebb3b3857f6696acb610866b Author: Lu Baolu Date: Thu May 2 09:34:25 2019 +0800 iommu/vt-d: Set intel_iommu_gfx_mapped correctly [ Upstream commit cf1ec4539a50bdfe688caad4615ca47646884316 ] The intel_iommu_gfx_mapped flag is exported by the Intel IOMMU driver to indicate whether an IOMMU is used for the graphic device. In a virtualized IOMMU environment (e.g. QEMU), an include-all IOMMU is used for graphic device. This flag is found to be clear even the IOMMU is used. Cc: Ashok Raj Cc: Jacob Pan Cc: Kevin Tian Reported-by: Zhenyu Wang Fixes: c0771df8d5297 ("intel-iommu: Export a flag indicating that the IOMMU is used for iGFX.") Suggested-by: Kevin Tian Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 525b5265fd755a354e0eda67d9b73a4560e8e371 Author: Ming Lei Date: Tue Apr 30 09:52:24 2019 +0800 blk-mq: move cancel of requeue_work into blk_mq_release [ Upstream commit fbc2a15e3433058582e5635aabe48a3011a644a8 ] With holding queue's kobject refcount, it is safe for driver to schedule requeue. However, blk_mq_kick_requeue_list() may be called after blk_sync_queue() is done because of concurrent requeue activities, then requeue work may not be completed when freeing queue, and kernel oops is triggered. So moving the cancel of requeue_work into blk_mq_release() for avoiding race between requeue and freeing queue. Cc: Dongli Zhang Cc: James Smart Cc: Bart Van Assche Cc: linux-scsi@vger.kernel.org, Cc: Martin K . Petersen , Cc: Christoph Hellwig , Cc: James E . J . Bottomley , Reviewed-by: Bart Van Assche Reviewed-by: Johannes Thumshirn Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Tested-by: James Smart Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit d6c80b609d81520f00e2dca517813e393b75af91 Author: Vladimir Zapolskiy Date: Tue Mar 12 01:54:25 2019 +0200 watchdog: fix compile time error of pretimeout governors [ Upstream commit a223770bfa7b6647f3a70983257bd89f9cafce46 ] CONFIG_WATCHDOG_PRETIMEOUT_GOV build symbol adds watchdog_pretimeout.o object to watchdog.o, the latter is compiled only if CONFIG_WATCHDOG_CORE is selected, so it rightfully makes sense to add it as a dependency. The change fixes the next compilation errors, if CONFIG_WATCHDOG_CORE=n and CONFIG_WATCHDOG_PRETIMEOUT_GOV=y are selected: drivers/watchdog/pretimeout_noop.o: In function `watchdog_gov_noop_register': drivers/watchdog/pretimeout_noop.c:35: undefined reference to `watchdog_register_governor' drivers/watchdog/pretimeout_noop.o: In function `watchdog_gov_noop_unregister': drivers/watchdog/pretimeout_noop.c:40: undefined reference to `watchdog_unregister_governor' drivers/watchdog/pretimeout_panic.o: In function `watchdog_gov_panic_register': drivers/watchdog/pretimeout_panic.c:35: undefined reference to `watchdog_register_governor' drivers/watchdog/pretimeout_panic.o: In function `watchdog_gov_panic_unregister': drivers/watchdog/pretimeout_panic.c:40: undefined reference to `watchdog_unregister_governor' Reported-by: Kuo, Hsuan-Chi Fixes: ff84136cb6a4 ("watchdog: add watchdog pretimeout governor framework") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 0f50c30c8470e0866792981870002d797f83715e Author: Georg Hofmann Date: Mon Apr 8 21:25:54 2019 +0200 watchdog: imx2_wdt: Fix set_timeout for big timeout values [ Upstream commit b07e228eee69601addba98b47b1a3850569e5013 ] The documentated behavior is: if max_hw_heartbeat_ms is implemented, the minimum of the set_timeout argument and max_hw_heartbeat_ms should be used. This patch implements this behavior. Previously only the first 7bits were used and the input argument was returned. Signed-off-by: Georg Hofmann Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit dc58e4027430c6344fb11f2509fe84fd374a1eab Author: Florian Westphal Date: Tue Apr 30 14:33:22 2019 +0200 netfilter: nf_tables: fix base chain stat rcu_dereference usage [ Upstream commit edbd82c5fba009f68d20b5db585be1e667c605f6 ] Following splat gets triggered when nfnetlink monitor is running while xtables-nft selftests are running: net/netfilter/nf_tables_api.c:1272 suspicious rcu_dereference_check() usage! other info that might help us debug this: 1 lock held by xtables-nft-mul/27006: #0: 00000000e0f85be9 (&net->nft.commit_mutex){+.+.}, at: nf_tables_valid_genid+0x1a/0x50 Call Trace: nf_tables_fill_chain_info.isra.45+0x6cc/0x6e0 nf_tables_chain_notify+0xf8/0x1a0 nf_tables_commit+0x165c/0x1740 nf_tables_fill_chain_info() can be called both from dumps (rcu read locked) or from the transaction path if a userspace process subscribed to nftables notifications. In the 'table dump' case, rcu_access_pointer() cannot be used: We do not hold transaction mutex so the pointer can be NULLed right after the check. Just unconditionally fetch the value, then have the helper return immediately if its NULL. In the notification case we don't hold the rcu read lock, but updates are prevented due to transaction mutex. Use rcu_dereference_check() to make lockdep aware of this. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 2d433cc9bd31aa9c7c632b207a1bfc885df3b344 Author: Serge Semin Date: Fri May 3 20:50:40 2019 +0300 mips: Make sure dt memory regions are valid [ Upstream commit 93fa5b280761a4dbb14c5330f260380385ab2b49 ] There are situations when memory regions coming from dts may be too big for the platform physical address space. This especially concerns XPA-capable systems. Bootloader may determine more than 4GB memory available and pass it to the kernel over dts memory node, while kernel is built without XPA/64BIT support. In this case the region may either simply be truncated by add_memory_region() method or by u64->phys_addr_t type casting. But in worst case the method can even drop the memory region if it exceeds PHYS_ADDR_MAX size. So lets make sure the retrieved from dts memory regions are valid, and if some of them aren't, just manually truncate them with a warning printed out. Signed-off-by: Serge Semin Signed-off-by: Paul Burton Cc: Ralf Baechle Cc: James Hogan Cc: Mike Rapoport Cc: Andrew Morton Cc: Michal Hocko Cc: Greg Kroah-Hartman Cc: Thomas Bogendoerfer Cc: Huacai Chen Cc: Stefan Agner Cc: Stephen Rothwell Cc: Alexandre Belloni Cc: Juergen Gross Cc: Serge Semin Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Sasha Levin commit 2aed9dfe1e5da6daf4c3c4f3a2f05f1c9575abfd Author: Jakub Jankowski Date: Thu Apr 25 23:46:50 2019 +0200 netfilter: nf_conntrack_h323: restore boundary check correctness [ Upstream commit f5e85ce8e733c2547827f6268136b70b802eabdb ] Since commit bc7d811ace4a ("netfilter: nf_ct_h323: Convert CHECK_BOUND macro to function"), NAT traversal for H.323 doesn't work, failing to parse H323-UserInformation. nf_h323_error_boundary() compares contents of the bitstring, not the addresses, preventing valid H.323 packets from being conntrack'd. This looks like an oversight from when CHECK_BOUND macro was converted to a function. To fix it, stop dereferencing bs->cur and bs->end. Fixes: bc7d811ace4a ("netfilter: nf_ct_h323: Convert CHECK_BOUND macro to function") Signed-off-by: Jakub Jankowski Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit d0941980fd81bf795400abd533831d348f08a8e2 Author: Taehee Yoo Date: Fri May 3 01:56:38 2019 +0900 netfilter: nf_flow_table: fix missing error check for rhashtable_insert_fast [ Upstream commit 43c8f131184faf20c07221f3e09724611c6525d8 ] rhashtable_insert_fast() may return an error value when memory allocation fails, but flow_offload_add() does not check for errors. This patch just adds missing error checking. Fixes: ac2a66665e23 ("netfilter: add generic flow table infrastructure") Signed-off-by: Taehee Yoo Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 217ec4a6e4ef075a784957b1adcb5c1e3283e911 Author: Ludovic Barre Date: Fri Apr 26 09:46:35 2019 +0200 mmc: mmci: Prevent polling for busy detection in IRQ context [ Upstream commit 8520ce1e17799b220ff421d4f39438c9c572ade3 ] The IRQ handler, mmci_irq(), loops until all status bits have been cleared. However, the status bit signaling busy in variant->busy_detect_flag, may be set even if busy detection isn't monitored for the current request. This may be the case for the CMD11 when switching the I/O voltage, which leads to that mmci_irq() busy loops in IRQ context. Fix this problem, by clearing the status bit for busy, before continuing to validate the condition for the loop. This is safe, because the busy status detection has already been taken care of by mmci_cmd_irq(). Signed-off-by: Ludovic Barre Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 06382ad6cf31fe628eae072e65b61a8b767b7828 Author: Amir Goldstein Date: Wed Apr 24 19:39:50 2019 +0300 ovl: do not generate duplicate fsnotify events for "fake" path [ Upstream commit d989903058a83e8536cc7aadf9256a47d5c173fe ] Overlayfs "fake" path is used for stacked file operations on underlying files. Operations on files with "fake" path must not generate fsnotify events with path data, because those events have already been generated at overlayfs layer and because the reported event->fd for fanotify marks on underlying inode/filesystem will have the wrong path (the overlayfs path). Link: https://lore.kernel.org/linux-fsdevel/20190423065024.12695-1-jencce.kernel@gmail.com/ Reported-by: Murphy Zhou Fixes: d1d04ef8572b ("ovl: stack file ops") Signed-off-by: Amir Goldstein Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 5fbe39bfd1e027387ff65ada3584cd836b84c659 Author: Jisheng Zhang Date: Fri Mar 29 11:57:17 2019 +0000 PCI: dwc: Free MSI IRQ page in dw_pcie_free_msi() [ Upstream commit dc69a3d567941784c3d00e1d0834582b42b0b3e7 ] To avoid a memory leak, free the page allocated for MSI IRQ in dw_pcie_free_msi(). Signed-off-by: Jisheng Zhang Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Acked-by: Gustavo Pimentel Signed-off-by: Sasha Levin commit a6b79e2c7c02d63c58f30979b6032d7367594693 Author: Jisheng Zhang Date: Fri Mar 29 11:57:54 2019 +0000 PCI: dwc: Free MSI in dw_pcie_host_init() error path [ Upstream commit 9e2b5de5604a6ff2626c51e77014d92c9299722c ] If we ever did MSI-related initializations, we need to call dw_pcie_free_msi() in the error code path. Remove the IS_ENABLED(CONFIG_PCI_MSI) check for MSI init because pci_msi_enabled() already has a stub for !CONFIG_PCI_MSI. Signed-off-by: Jisheng Zhang Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Acked-by: Gustavo Pimentel Signed-off-by: Sasha Levin commit a4aa028267019df11696077507994510a0d84726 Author: Maciej Żenczykowski Date: Wed Apr 10 11:11:23 2019 -0700 uml: fix a boot splat wrt use of cpu_all_mask [ Upstream commit 689a58605b63173acb0a8cf954af6a8f60440c93 ] Memory: 509108K/542612K available (3835K kernel code, 919K rwdata, 1028K rodata, 129K init, 211K bss, 33504K reserved, 0K cma-reserved) NR_IRQS: 15 clocksource: timer: mask: 0xffffffffffffffff max_cycles: 0x1cd42e205, max_idle_ns: 881590404426 ns ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at kernel/time/clockevents.c:458 clockevents_register_device+0x72/0x140 posix-timer cpumask == cpu_all_mask, using cpu_possible_mask instead Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 5.1.0-rc4-00048-ged79cc87302b #4 Stack: 604ebda0 603c5370 604ebe20 6046fd17 00000000 6006fcbb 604ebdb0 603c53b5 604ebe10 6003bfc4 604ebdd0 9000001ca Call Trace: [<6006fcbb>] ? printk+0x0/0x94 [<60083160>] ? clockevents_register_device+0x72/0x140 [<6001f16e>] show_stack+0x13b/0x155 [<603c5370>] ? dump_stack_print_info+0xe2/0xeb [<6006fcbb>] ? printk+0x0/0x94 [<603c53b5>] dump_stack+0x2a/0x2c [<6003bfc4>] __warn+0x10e/0x13e [<60070320>] ? vprintk_func+0xc8/0xcf [<60030fd6>] ? block_signals+0x0/0x16 [<6006fcbb>] ? printk+0x0/0x94 [<6003c08b>] warn_slowpath_fmt+0x97/0x99 [<600311a1>] ? set_signals+0x0/0x3f [<6003bff4>] ? warn_slowpath_fmt+0x0/0x99 [<600842cb>] ? tick_oneshot_mode_active+0x44/0x4f [<60030fd6>] ? block_signals+0x0/0x16 [<6006fcbb>] ? printk+0x0/0x94 [<6007d2d5>] ? __clocksource_select+0x20/0x1b1 [<60030fd6>] ? block_signals+0x0/0x16 [<6006fcbb>] ? printk+0x0/0x94 [<60083160>] clockevents_register_device+0x72/0x140 [<60031192>] ? get_signals+0x0/0xf [<60030fd6>] ? block_signals+0x0/0x16 [<6006fcbb>] ? printk+0x0/0x94 [<60002eec>] um_timer_setup+0xc8/0xca [<60001b59>] start_kernel+0x47f/0x57e [<600035bc>] start_kernel_proc+0x49/0x4d [<6006c483>] ? kmsg_dump_register+0x82/0x8a [<6001de62>] new_thread_handler+0x81/0xb2 [<60003571>] ? kmsg_dumper_stdout_init+0x1a/0x1c [<60020c75>] uml_finishsetup+0x54/0x59 random: get_random_bytes called from init_oops_id+0x27/0x34 with crng_init=0 ---[ end trace 00173d0117a88acb ]--- Calibrating delay loop... 6941.90 BogoMIPS (lpj=34709504) Signed-off-by: Maciej Żenczykowski Cc: Jeff Dike Cc: Richard Weinberger Cc: Anton Ivanov Cc: linux-um@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 4dc146d47feaddd3760de3d1ebeb889c8145dcb2 Author: YueHaibing Date: Sun May 5 11:03:12 2019 +0800 configfs: fix possible use-after-free in configfs_register_group [ Upstream commit 35399f87e271f7cf3048eab00a421a6519ac8441 ] In configfs_register_group(), if create_default_group() failed, we forget to unlink the group. It will left a invalid item in the parent list, which may trigger the use-after-free issue seen below: BUG: KASAN: use-after-free in __list_add_valid+0xd4/0xe0 lib/list_debug.c:26 Read of size 8 at addr ffff8881ef61ae20 by task syz-executor.0/5996 CPU: 1 PID: 5996 Comm: syz-executor.0 Tainted: G C 5.0.0+ #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xa9/0x10e lib/dump_stack.c:113 print_address_description+0x65/0x270 mm/kasan/report.c:187 kasan_report+0x149/0x18d mm/kasan/report.c:317 __list_add_valid+0xd4/0xe0 lib/list_debug.c:26 __list_add include/linux/list.h:60 [inline] list_add_tail include/linux/list.h:93 [inline] link_obj+0xb0/0x190 fs/configfs/dir.c:759 link_group+0x1c/0x130 fs/configfs/dir.c:784 configfs_register_group+0x56/0x1e0 fs/configfs/dir.c:1751 configfs_register_default_group+0x72/0xc0 fs/configfs/dir.c:1834 ? 0xffffffffc1be0000 iio_sw_trigger_init+0x23/0x1000 [industrialio_sw_trigger] do_one_initcall+0xbc/0x47d init/main.c:887 do_init_module+0x1b5/0x547 kernel/module.c:3456 load_module+0x6405/0x8c10 kernel/module.c:3804 __do_sys_finit_module+0x162/0x190 kernel/module.c:3898 do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x462e99 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f494ecbcc58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99 RDX: 0000000000000000 RSI: 0000000020000180 RDI: 0000000000000003 RBP: 00007f494ecbcc70 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f494ecbd6bc R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004 Allocated by task 5987: set_track mm/kasan/common.c:87 [inline] __kasan_kmalloc.constprop.3+0xa0/0xd0 mm/kasan/common.c:497 kmalloc include/linux/slab.h:545 [inline] kzalloc include/linux/slab.h:740 [inline] configfs_register_default_group+0x4c/0xc0 fs/configfs/dir.c:1829 0xffffffffc1bd0023 do_one_initcall+0xbc/0x47d init/main.c:887 do_init_module+0x1b5/0x547 kernel/module.c:3456 load_module+0x6405/0x8c10 kernel/module.c:3804 __do_sys_finit_module+0x162/0x190 kernel/module.c:3898 do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 5987: set_track mm/kasan/common.c:87 [inline] __kasan_slab_free+0x130/0x180 mm/kasan/common.c:459 slab_free_hook mm/slub.c:1429 [inline] slab_free_freelist_hook mm/slub.c:1456 [inline] slab_free mm/slub.c:3003 [inline] kfree+0xe1/0x270 mm/slub.c:3955 configfs_register_default_group+0x9a/0xc0 fs/configfs/dir.c:1836 0xffffffffc1bd0023 do_one_initcall+0xbc/0x47d init/main.c:887 do_init_module+0x1b5/0x547 kernel/module.c:3456 load_module+0x6405/0x8c10 kernel/module.c:3804 __do_sys_finit_module+0x162/0x190 kernel/module.c:3898 do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff8881ef61ae00 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 32 bytes inside of 192-byte region [ffff8881ef61ae00, ffff8881ef61aec0) The buggy address belongs to the page: page:ffffea0007bd8680 count:1 mapcount:0 mapping:ffff8881f6c03000 index:0xffff8881ef61a700 flags: 0x2fffc0000000200(slab) raw: 02fffc0000000200 ffffea0007ca4740 0000000500000005 ffff8881f6c03000 raw: ffff8881ef61a700 000000008010000c 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881ef61ad00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8881ef61ad80: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc >ffff8881ef61ae00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881ef61ae80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ffff8881ef61af00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb Fixes: 5cf6a51e6062 ("configfs: allow dynamic group creation") Reported-by: Hulk Robot Signed-off-by: YueHaibing Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 5329dcafead20f6b5c19f1918fc0f027ad492fa0 Author: John Sperbeck Date: Tue May 7 18:43:20 2019 -0700 percpu: remove spurious lock dependency between percpu and sched [ Upstream commit 198790d9a3aeaef5792d33a560020861126edc22 ] In free_percpu() we sometimes call pcpu_schedule_balance_work() to queue a work item (which does a wakeup) while holding pcpu_lock. This creates an unnecessary lock dependency between pcpu_lock and the scheduler's pi_lock. There are other places where we call pcpu_schedule_balance_work() without hold pcpu_lock, and this case doesn't need to be different. Moving the call outside the lock prevents the following lockdep splat when running tools/testing/selftests/bpf/{test_maps,test_progs} in sequence with lockdep enabled: ====================================================== WARNING: possible circular locking dependency detected 5.1.0-dbg-DEV #1 Not tainted ------------------------------------------------------ kworker/23:255/18872 is trying to acquire lock: 000000000bc79290 (&(&pool->lock)->rlock){-.-.}, at: __queue_work+0xb2/0x520 but task is already holding lock: 00000000e3e7a6aa (pcpu_lock){..-.}, at: free_percpu+0x36/0x260 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (pcpu_lock){..-.}: lock_acquire+0x9e/0x180 _raw_spin_lock_irqsave+0x3a/0x50 pcpu_alloc+0xfa/0x780 __alloc_percpu_gfp+0x12/0x20 alloc_htab_elem+0x184/0x2b0 __htab_percpu_map_update_elem+0x252/0x290 bpf_percpu_hash_update+0x7c/0x130 __do_sys_bpf+0x1912/0x1be0 __x64_sys_bpf+0x1a/0x20 do_syscall_64+0x59/0x400 entry_SYSCALL_64_after_hwframe+0x49/0xbe -> #3 (&htab->buckets[i].lock){....}: lock_acquire+0x9e/0x180 _raw_spin_lock_irqsave+0x3a/0x50 htab_map_update_elem+0x1af/0x3a0 -> #2 (&rq->lock){-.-.}: lock_acquire+0x9e/0x180 _raw_spin_lock+0x2f/0x40 task_fork_fair+0x37/0x160 sched_fork+0x211/0x310 copy_process.part.43+0x7b1/0x2160 _do_fork+0xda/0x6b0 kernel_thread+0x29/0x30 rest_init+0x22/0x260 arch_call_rest_init+0xe/0x10 start_kernel+0x4fd/0x520 x86_64_start_reservations+0x24/0x26 x86_64_start_kernel+0x6f/0x72 secondary_startup_64+0xa4/0xb0 -> #1 (&p->pi_lock){-.-.}: lock_acquire+0x9e/0x180 _raw_spin_lock_irqsave+0x3a/0x50 try_to_wake_up+0x41/0x600 wake_up_process+0x15/0x20 create_worker+0x16b/0x1e0 workqueue_init+0x279/0x2ee kernel_init_freeable+0xf7/0x288 kernel_init+0xf/0x180 ret_from_fork+0x24/0x30 -> #0 (&(&pool->lock)->rlock){-.-.}: __lock_acquire+0x101f/0x12a0 lock_acquire+0x9e/0x180 _raw_spin_lock+0x2f/0x40 __queue_work+0xb2/0x520 queue_work_on+0x38/0x80 free_percpu+0x221/0x260 pcpu_freelist_destroy+0x11/0x20 stack_map_free+0x2a/0x40 bpf_map_free_deferred+0x3c/0x50 process_one_work+0x1f7/0x580 worker_thread+0x54/0x410 kthread+0x10f/0x150 ret_from_fork+0x24/0x30 other info that might help us debug this: Chain exists of: &(&pool->lock)->rlock --> &htab->buckets[i].lock --> pcpu_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(pcpu_lock); lock(&htab->buckets[i].lock); lock(pcpu_lock); lock(&(&pool->lock)->rlock); *** DEADLOCK *** 3 locks held by kworker/23:255/18872: #0: 00000000b36a6e16 ((wq_completion)events){+.+.}, at: process_one_work+0x17a/0x580 #1: 00000000dfd966f0 ((work_completion)(&map->work)){+.+.}, at: process_one_work+0x17a/0x580 #2: 00000000e3e7a6aa (pcpu_lock){..-.}, at: free_percpu+0x36/0x260 stack backtrace: CPU: 23 PID: 18872 Comm: kworker/23:255 Not tainted 5.1.0-dbg-DEV #1 Hardware name: ... Workqueue: events bpf_map_free_deferred Call Trace: dump_stack+0x67/0x95 print_circular_bug.isra.38+0x1c6/0x220 check_prev_add.constprop.50+0x9f6/0xd20 __lock_acquire+0x101f/0x12a0 lock_acquire+0x9e/0x180 _raw_spin_lock+0x2f/0x40 __queue_work+0xb2/0x520 queue_work_on+0x38/0x80 free_percpu+0x221/0x260 pcpu_freelist_destroy+0x11/0x20 stack_map_free+0x2a/0x40 bpf_map_free_deferred+0x3c/0x50 process_one_work+0x1f7/0x580 worker_thread+0x54/0x410 kthread+0x10f/0x150 ret_from_fork+0x24/0x30 Signed-off-by: John Sperbeck Signed-off-by: Dennis Zhou Signed-off-by: Sasha Levin commit 8d7ebdd109b4654ec5e0e9c3c6f08b06d6558f10 Author: Chao Yu Date: Mon Apr 15 15:28:35 2019 +0800 f2fs: fix to do checksum even if inode page is uptodate [ Upstream commit b42b179bda9ff11075a6fc2bac4d9e400513679a ] As Jungyeon reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203221 - Overview When mounting the attached crafted image and running program, this error is reported. The image is intentionally fuzzed from a normal f2fs image for testing and I enabled option CONFIG_F2FS_CHECK_FS on. - Reproduces cc poc_07.c mkdir test mount -t f2fs tmp.img test cp a.out test cd test sudo ./a.out - Messages kernel BUG at fs/f2fs/node.c:1279! RIP: 0010:read_node_page+0xcf/0xf0 Call Trace: __get_node_page+0x6b/0x2f0 f2fs_iget+0x8f/0xdf0 f2fs_lookup+0x136/0x320 __lookup_slow+0x92/0x140 lookup_slow+0x30/0x50 walk_component+0x1c1/0x350 path_lookupat+0x62/0x200 filename_lookup+0xb3/0x1a0 do_fchmodat+0x3e/0xa0 __x64_sys_chmod+0x12/0x20 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 On below paths, we can have opportunity to readahead inode page - gc_node_segment -> f2fs_ra_node_page - gc_data_segment -> f2fs_ra_node_page - f2fs_fill_dentries -> f2fs_ra_node_page Unlike synchronized read, on readahead path, we can set page uptodate before verifying page's checksum, then read_node_page() will trigger kernel panic once it encounters a uptodated page w/ incorrect checksum. So considering readahead scenario, we have to do checksum each time when loading inode page even if it is uptodated. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 64024854543630a02429584d7adc4f71b1139bf4 Author: Chao Yu Date: Mon Apr 15 15:30:51 2019 +0800 f2fs: fix to do sanity check on valid block count of segment [ Upstream commit e95bcdb2fefa129f37bd9035af1d234ca92ee4ef ] As Jungyeon reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203233 - Overview When mounting the attached crafted image and running program, following errors are reported. Additionally, it hangs on sync after running program. The image is intentionally fuzzed from a normal f2fs image for testing. Compile options for F2FS are as follows. CONFIG_F2FS_FS=y CONFIG_F2FS_STAT_FS=y CONFIG_F2FS_FS_XATTR=y CONFIG_F2FS_FS_POSIX_ACL=y CONFIG_F2FS_CHECK_FS=y - Reproduces cc poc_13.c mkdir test mount -t f2fs tmp.img test cp a.out test cd test sudo ./a.out sync - Kernel messages F2FS-fs (sdb): Bitmap was wrongly set, blk:4608 kernel BUG at fs/f2fs/segment.c:2102! RIP: 0010:update_sit_entry+0x394/0x410 Call Trace: f2fs_allocate_data_block+0x16f/0x660 do_write_page+0x62/0x170 f2fs_do_write_node_page+0x33/0xa0 __write_node_page+0x270/0x4e0 f2fs_sync_node_pages+0x5df/0x670 f2fs_write_checkpoint+0x372/0x1400 f2fs_sync_fs+0xa3/0x130 f2fs_do_sync_file+0x1a6/0x810 do_fsync+0x33/0x60 __x64_sys_fsync+0xb/0x10 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 sit.vblocks and sum valid block count in sit.valid_map may be inconsistent, segment w/ zero vblocks will be treated as free segment, while allocating in free segment, we may allocate a free block, if its bitmap is valid previously, it can cause kernel crash due to bitmap verification failure. Anyway, to avoid further serious metadata inconsistence and corruption, it is necessary and worth to detect SIT inconsistence. So let's enable check_block_count() to verify vblocks and valid_map all the time rather than do it only CONFIG_F2FS_CHECK_FS is enabled. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 101e48feb661fa2dfd829b83bf3eb71b45fabe30 Author: Chao Yu Date: Thu Apr 11 11:48:10 2019 +0800 f2fs: fix to use inline space only if inline_xattr is enable [ Upstream commit 622927f3b8809206f6da54a6a7ed4df1a7770fce ] With below mkfs and mount option: MKFS_OPTIONS -- -O extra_attr -O project_quota -O inode_checksum -O flexible_inline_xattr -O inode_crtime -f MOUNT_OPTIONS -- -o noinline_xattr We may miss xattr data with below testcase: - mkdir dir - setfattr -n "user.name" -v 0 dir - for ((i = 0; i < 190; i++)) do touch dir/$i; done - umount - mount - getfattr -n "user.name" dir user.name: No such attribute The root cause is that we persist xattr data into reserved inline xattr space, even if inline_xattr is not enable in inline directory inode, after inline dentry conversion, reserved space no longer exists, so that xattr data missed. Let's use inline xattr space only if inline_xattr flag is set on inode to fix this iusse. Fixes: 6afc662e68b5 ("f2fs: support flexible inline xattr size") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 45624f0e8142470724227292603f9a8fd72cc1d6 Author: Chao Yu Date: Mon Apr 15 15:28:30 2019 +0800 f2fs: fix to avoid panic in dec_valid_block_count() [ Upstream commit 5e159cd349bf3a31fb7e35c23a93308eb30f4f71 ] As Jungyeon reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203209 - Overview When mounting the attached crafted image and running program, I got this error. Additionally, it hangs on sync after the this script. The image is intentionally fuzzed from a normal f2fs image for testing and I enabled option CONFIG_F2FS_CHECK_FS on. - Reproduces cc poc_01.c ./run.sh f2fs sync kernel BUG at fs/f2fs/f2fs.h:1788! RIP: 0010:f2fs_truncate_data_blocks_range+0x342/0x350 Call Trace: f2fs_truncate_blocks+0x36d/0x3c0 f2fs_truncate+0x88/0x110 f2fs_setattr+0x3e1/0x460 notify_change+0x2da/0x400 do_truncate+0x6d/0xb0 do_sys_ftruncate+0xf1/0x160 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The reason is dec_valid_block_count() will trigger kernel panic due to inconsistent count in between inode.i_blocks and actual block. To avoid panic, let's just print debug message and set SBI_NEED_FSCK to give a hint to fsck for latter repairing. Signed-off-by: Chao Yu [Jaegeuk Kim: fix build warning and add unlikely] Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 47a92acf9ebf34599f1e8450fc7614b8c06cf3d5 Author: Chao Yu Date: Mon Apr 15 15:28:33 2019 +0800 f2fs: fix to clear dirty inode in error path of f2fs_iget() [ Upstream commit 546d22f070d64a7b96f57c93333772085d3a5e6d ] As Jungyeon reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203217 - Overview When mounting the attached crafted image and running program, I got this error. Additionally, it hangs on sync after running the program. The image is intentionally fuzzed from a normal f2fs image for testing and I enabled option CONFIG_F2FS_CHECK_FS on. - Reproduces cc poc_test_05.c mkdir test mount -t f2fs tmp.img test sudo ./a.out sync - Messages kernel BUG at fs/f2fs/inode.c:707! RIP: 0010:f2fs_evict_inode+0x33f/0x3a0 Call Trace: evict+0xba/0x180 f2fs_iget+0x598/0xdf0 f2fs_lookup+0x136/0x320 __lookup_slow+0x92/0x140 lookup_slow+0x30/0x50 walk_component+0x1c1/0x350 path_lookupat+0x62/0x200 filename_lookup+0xb3/0x1a0 do_readlinkat+0x56/0x110 __x64_sys_readlink+0x16/0x20 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 During inode loading, __recover_inline_status() can recovery inode status and set inode dirty, once we failed in following process, it will fail the check in f2fs_evict_inode, result in trigger BUG_ON(). Let's clear dirty inode in error path of f2fs_iget() to avoid panic. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit ca9fcbc5a5f554108444cef219ec17cd0396fdb7 Author: Chao Yu Date: Mon Apr 15 15:28:36 2019 +0800 f2fs: fix to do sanity check on free nid [ Upstream commit 626bcf2b7ce87211dba565f2bfa7842ba5be5c1b ] As Jungyeon reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203225 - Overview When mounting the attached crafted image and unmounting it, following errors are reported. Additionally, it hangs on sync after unmounting. The image is intentionally fuzzed from a normal f2fs image for testing. Compile options for F2FS are as follows. CONFIG_F2FS_FS=y CONFIG_F2FS_STAT_FS=y CONFIG_F2FS_FS_XATTR=y CONFIG_F2FS_FS_POSIX_ACL=y CONFIG_F2FS_CHECK_FS=y - Reproduces mkdir test mount -t f2fs tmp.img test touch test/t umount test sync - Messages kernel BUG at fs/f2fs/node.c:3073! RIP: 0010:f2fs_destroy_node_manager+0x2f0/0x300 Call Trace: f2fs_put_super+0xf4/0x270 generic_shutdown_super+0x62/0x110 kill_block_super+0x1c/0x50 kill_f2fs_super+0xad/0xd0 deactivate_locked_super+0x35/0x60 cleanup_mnt+0x36/0x70 task_work_run+0x75/0x90 exit_to_usermode_loop+0x93/0xa0 do_syscall_64+0xba/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0010:f2fs_destroy_node_manager+0x2f0/0x300 NAT table is corrupted, so reserved meta/node inode ids were added into free list incorrectly, during file creation, since reserved id has cached in inode hash, so it fails the creation and preallocated nid can not be released later, result in kernel panic. To fix this issue, let's do nid boundary check during free nid loading. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit f3aa313d0d4f8c1316d23f164dd1cec8672abe32 Author: Chao Yu Date: Mon Apr 15 15:28:34 2019 +0800 f2fs: fix to avoid panic in f2fs_remove_inode_page() [ Upstream commit 8b6810f8acfe429fde7c7dad4714692cc5f75651 ] As Jungyeon reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203219 - Overview When mounting the attached crafted image and running program, I got this error. Additionally, it hangs on sync after running the program. The image is intentionally fuzzed from a normal f2fs image for testing and I enabled option CONFIG_F2FS_CHECK_FS on. - Reproduces cc poc_06.c mkdir test mount -t f2fs tmp.img test cp a.out test cd test sudo ./a.out sync - Messages kernel BUG at fs/f2fs/node.c:1183! RIP: 0010:f2fs_remove_inode_page+0x294/0x2d0 Call Trace: f2fs_evict_inode+0x2a3/0x3a0 evict+0xba/0x180 __dentry_kill+0xbe/0x160 dentry_kill+0x46/0x180 dput+0xbb/0x100 do_renameat2+0x3c9/0x550 __x64_sys_rename+0x17/0x20 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The reason is f2fs_remove_inode_page() will trigger kernel panic due to inconsistent i_blocks value of inode. To avoid panic, let's just print debug message and set SBI_NEED_FSCK to give a hint to fsck for latter repairing of potential image corruption. Signed-off-by: Chao Yu [Jaegeuk Kim: fix build warning and add unlikely] Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 0325c5cce54411819eabefabb836451c5d0b276a Author: Chao Yu Date: Mon Apr 15 15:30:52 2019 +0800 f2fs: fix to avoid panic in f2fs_inplace_write_data() [ Upstream commit 05573d6ccf702df549a7bdeabef31e4753df1a90 ] As Jungyeon reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203239 - Overview When mounting the attached crafted image and running program, following errors are reported. Additionally, it hangs on sync after running program. The image is intentionally fuzzed from a normal f2fs image for testing. Compile options for F2FS are as follows. CONFIG_F2FS_FS=y CONFIG_F2FS_STAT_FS=y CONFIG_F2FS_FS_XATTR=y CONFIG_F2FS_FS_POSIX_ACL=y CONFIG_F2FS_CHECK_FS=y - Reproduces cc poc_15.c ./run.sh f2fs sync - Kernel messages ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:3162! RIP: 0010:f2fs_inplace_write_data+0x12d/0x160 Call Trace: f2fs_do_write_data_page+0x3c1/0x820 __write_data_page+0x156/0x720 f2fs_write_cache_pages+0x20d/0x460 f2fs_write_data_pages+0x1b4/0x300 do_writepages+0x15/0x60 __filemap_fdatawrite_range+0x7c/0xb0 file_write_and_wait_range+0x2c/0x80 f2fs_do_sync_file+0x102/0x810 do_fsync+0x33/0x60 __x64_sys_fsync+0xb/0x10 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The reason is f2fs_inplace_write_data() will trigger kernel panic due to data block locates in node type segment. To avoid panic, let's just return error code and set SBI_NEED_FSCK to give a hint to fsck for latter repairing. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 8490bf2d6176d3a5c1515b12d13a0fcc5b6cf893 Author: Chao Yu Date: Mon Apr 15 15:28:37 2019 +0800 f2fs: fix to avoid panic in do_recover_data() [ Upstream commit 22d61e286e2d9097dae36f75ed48801056b77cac ] As Jungyeon reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203227 - Overview When mounting the attached crafted image, following errors are reported. Additionally, it hangs on sync after trying to mount it. The image is intentionally fuzzed from a normal f2fs image for testing. Compile options for F2FS are as follows. CONFIG_F2FS_FS=y CONFIG_F2FS_STAT_FS=y CONFIG_F2FS_FS_XATTR=y CONFIG_F2FS_FS_POSIX_ACL=y CONFIG_F2FS_CHECK_FS=y - Reproduces mkdir test mount -t f2fs tmp.img test sync - Messages kernel BUG at fs/f2fs/recovery.c:549! RIP: 0010:recover_data+0x167a/0x1780 Call Trace: f2fs_recover_fsync_data+0x613/0x710 f2fs_fill_super+0x1043/0x1aa0 mount_bdev+0x16d/0x1a0 mount_fs+0x4a/0x170 vfs_kern_mount+0x5d/0x100 do_mount+0x200/0xcf0 ksys_mount+0x79/0xc0 __x64_sys_mount+0x1c/0x20 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 During recovery, if ofs_of_node is inconsistent in between recovered node page and original checkpointed node page, let's just fail recovery instead of making kernel panic. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 0b50d08c5d854f9052e4a50769d897c6d97dc0ad Author: Miroslav Lichvar Date: Wed Apr 17 10:48:33 2019 +0200 ntp: Allow TAI-UTC offset to be set to zero [ Upstream commit fdc6bae940ee9eb869e493990540098b8c0fd6ab ] The ADJ_TAI adjtimex mode sets the TAI-UTC offset of the system clock. It is typically set by NTP/PTP implementations and it is automatically updated by the kernel on leap seconds. The initial value is zero (which applications may interpret as unknown), but this value cannot be set by adjtimex. This limitation seems to go back to the original "nanokernel" implementation by David Mills. Change the ADJ_TAI check to accept zero as a valid TAI-UTC offset in order to allow setting it back to the initial value. Fixes: 153b5d054ac2 ("ntp: support for TAI") Suggested-by: Ondrej Mosnacek Signed-off-by: Miroslav Lichvar Signed-off-by: Thomas Gleixner Cc: John Stultz Cc: Richard Cochran Cc: Prarit Bhargava Link: https://lkml.kernel.org/r/20190417084833.7401-1-mlichvar@redhat.com Signed-off-by: Sasha Levin commit 102f6e1249fb37639b5d5e1bc8230dfe46f3e49c Author: Fabien Dessenne Date: Wed Apr 24 17:51:05 2019 +0200 mailbox: stm32-ipcc: check invalid irq [ Upstream commit 68a1c8485cf83734d4da9d81cd3b5d2ae7c0339b ] On failure of_irq_get() returns a negative value or zero, which is not handled as an error in the existing implementation. Instead of using this API, use platform_get_irq() that returns exclusively a negative value on failure. Also, do not output an error log in case of defer probe error. Signed-off-by: Fabien Dessenne Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit c5b2c8249ff356e366883fdab1227576d7fb91cb Author: Martin Blumenstingl Date: Mon Apr 1 19:57:48 2019 +0200 pwm: meson: Use the spin-lock only to protect register modifications [ Upstream commit f173747fffdf037c791405ab4f1ec0eb392fc48e ] Holding the spin-lock for all of the code in meson_pwm_apply() can result in a "BUG: scheduling while atomic". This can happen because clk_get_rate() (which is called from meson_pwm_calc()) may sleep. Only hold the spin-lock when modifying registers to solve this. The reason why we need a spin-lock in the driver is because the REG_MISC_AB register is shared between the two channels provided by one PWM controller. The only functions where REG_MISC_AB is modified are meson_pwm_enable() and meson_pwm_disable() so the register reads/writes in there need to be protected by the spin-lock. The original code also used the spin-lock to protect the values in struct meson_pwm_channel. This could be necessary if two consumers can use the same PWM channel. However, PWM core doesn't allow this so we don't need to protect the values in struct meson_pwm_channel with a lock. Fixes: 211ed630753d2f ("pwm: Add support for Meson PWM Controller") Signed-off-by: Martin Blumenstingl Reviewed-by: Uwe Kleine-König Reviewed-by: Neil Armstrong Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 689fe88d51aad521295bf89711fba463325006ec Author: Michael Ellerman Date: Fri May 3 00:19:41 2019 +1000 EDAC/mpc85xx: Prevent building as a module [ Upstream commit 2b8358a951b1e2a534a54924cd8245e58a1c5fb8 ] The mpc85xx EDAC driver can be configured as a module but then fails to build because it uses two unexported symbols: ERROR: ".pci_find_hose_for_OF_device" [drivers/edac/mpc85xx_edac_mod.ko] undefined! ERROR: ".early_find_capability" [drivers/edac/mpc85xx_edac_mod.ko] undefined! We don't want to export those symbols just for this driver, so make the driver only configurable as a built-in. This seems to have been broken since at least c92132f59806 ("edac/85xx: Add PCIe error interrupt edac support") (Nov 2013). [ bp: make it depend on EDAC=y so that the EDAC core doesn't get built as a module. ] Signed-off-by: Michael Ellerman Signed-off-by: Borislav Petkov Acked-by: Johannes Thumshirn Cc: James Morse Cc: Mauro Carvalho Chehab Cc: linux-edac Cc: linuxppc-dev@ozlabs.org Cc: morbidrsa@gmail.com Link: https://lkml.kernel.org/r/20190502141941.12927-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit f9ee13ce21dbaf99d2a6876ee8bd77a179ae788e Author: Krzesimir Nowak Date: Wed May 8 18:08:58 2019 +0200 bpf: fix undefined behavior in narrow load handling [ Upstream commit e2f7fc0ac6957cabff4cecf6c721979b571af208 ] Commit 31fd85816dbe ("bpf: permits narrower load from bpf program context fields") made the verifier add AND instructions to clear the unwanted bits with a mask when doing a narrow load. The mask is computed with (1 << size * 8) - 1 where "size" is the size of the narrow load. When doing a 4 byte load of a an 8 byte field the verifier shifts the literal 1 by 32 places to the left. This results in an overflow of a signed integer, which is an undefined behavior. Typically, the computed mask was zero, so the result of the narrow load ended up being zero too. Cast the literal to long long to avoid overflows. Note that narrow load of the 4 byte fields does not have the undefined behavior, because the load size can only be either 1 or 2 bytes, so shifting 1 by 8 or 16 places will not overflow it. And reading 4 bytes would not be a narrow load of a 4 bytes field. Fixes: 31fd85816dbe ("bpf: permits narrower load from bpf program context fields") Reviewed-by: Alban Crequy Reviewed-by: Iago López Galeiras Signed-off-by: Krzesimir Nowak Cc: Yonghong Song Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 991b51048c498ede516a51d10ec0dc470af34e45 Author: Ben Skeggs Date: Fri May 3 12:23:55 2019 +1000 drm/nouveau/kms/gv100-: fix spurious window immediate interlocks [ Upstream commit d2434e4d942c32cadcbdbcd32c58f35098f3b604 ] Cursor position updates were accidentally causing us to attempt to interlock window with window immediate, and without a matching window immediate update, NVDisplay could hang forever in some circumstances. Fixes suspend/resume on (at least) Quadro RTX4000 (TU104). Reported-by: Lyude Paul Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit 20e1a16702d988a609d8f0122f7f294031169e9c Author: Josh Poimboeuf Date: Mon May 13 12:01:31 2019 -0500 objtool: Don't use ignore flag for fake jumps [ Upstream commit e6da9567959e164f82bc81967e0d5b10dee870b4 ] The ignore flag is set on fake jumps in order to keep add_jump_destinations() from setting their jump_dest, since it already got set when the fake jump was created. But using the ignore flag is a bit of a hack. It's normally used to skip validation of an instruction, which doesn't really make sense for fake jumps. Also, after the next patch, using the ignore flag for fake jumps can trigger a false "why am I validating an ignored function?" warning. Instead just add an explicit check in add_jump_destinations() to skip fake jumps. Signed-off-by: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/71abc072ff48b2feccc197723a9c52859476c068.1557766718.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 124c23dca3ac1d786022cd0e62f483a7961ed124 Author: Matt Redfearn Date: Wed Apr 24 13:22:27 2019 +0000 drm/bridge: adv7511: Fix low refresh rate selection [ Upstream commit 67793bd3b3948dc8c8384b6430e036a30a0ecb43 ] The driver currently sets register 0xfb (Low Refresh Rate) based on the value of mode->vrefresh. Firstly, this field is specified to be in Hz, but the magic numbers used by the code are Hz * 1000. This essentially leads to the low refresh rate always being set to 0x01, since the vrefresh value will always be less than 24000. Fix the magic numbers to be in Hz. Secondly, according to the comment in drm_modes.h, the field is not supposed to be used in a functional way anyway. Instead, use the helper function drm_mode_vrefresh(). Fixes: 9c8af882bf12 ("drm: Add adv7511 encoder driver") Reviewed-by: Laurent Pinchart Signed-off-by: Matt Redfearn Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20190424132210.26338-1-matt.redfearn@thinci.com Signed-off-by: Sasha Levin commit 2a3f2b43a9e3b7fe802400ba80ae56533a8c66f9 Author: Ben Skeggs Date: Wed May 8 14:54:34 2019 +1000 drm/nouveau/kms/gf119-gp10x: push HeadSetControlOutputResource() mthd when encoders change [ Upstream commit a0b694d0af21c9993d1a39a75fd814bd48bf7eb4 ] HW has error checks in place which check that pixel depth is explicitly provided on DP, while HDMI has a "default" setting that we use. In multi-display configurations with identical modelines, but different protocols (HDMI + DP, in this case), it was possible for the DP head to get swapped to the head which previously drove the HDMI output, without updating HeadSetControlOutputResource(), triggering the error check and hanging the core update. Reported-by: Lyude Paul Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit f9706dd945e9e6fbd7a13fe9813811a5c16442cb Author: Stephane Eranian Date: Mon May 13 17:34:00 2019 -0700 perf/x86/intel: Allow PEBS multi-entry in watermark mode [ Upstream commit c7a286577d7592720c2f179aadfb325a1ff48c95 ] This patch fixes a restriction/bug introduced by: 583feb08e7f7 ("perf/x86/intel: Fix handling of wakeup_events for multi-entry PEBS") The original patch prevented using multi-entry PEBS when wakeup_events != 0. However given that wakeup_events is part of a union with wakeup_watermark, it means that in watermark mode, PEBS multi-entry is also disabled which is not the intent. This patch fixes this by checking is watermark mode is enabled. Signed-off-by: Stephane Eranian Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: jolsa@redhat.com Cc: kan.liang@intel.com Cc: vincent.weaver@maine.edu Fixes: 583feb08e7f7 ("perf/x86/intel: Fix handling of wakeup_events for multi-entry PEBS") Link: http://lkml.kernel.org/r/20190514003400.224340-1-eranian@google.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 5540d0146151fb96d3eb065381b5f620641b384f Author: Tony Lindgren Date: Thu Feb 14 08:03:45 2019 -0800 mfd: twl6040: Fix device init errors for ACCCTL register [ Upstream commit 48171d0ea7caccf21c9ee3ae75eb370f2a756062 ] I noticed that we can get a -EREMOTEIO errors on at least omap4 duovero: twl6040 0-004b: Failed to write 2d = 19: -121 And then any following register access will produce errors. There 2d offset above is register ACCCTL that gets written on twl6040 powerup. With error checking added to the related regcache_sync() call, the -EREMOTEIO error is reproducable on twl6040 powerup at least duovero. To fix the error, we need to wait until twl6040 is accessible after the powerup. Based on tests on omap4 duovero, we need to wait over 8ms after powerup before register write will complete without failures. Let's also make sure we warn about possible errors too. Note that we have twl6040_patch[] reg_sequence with the ACCCTL register configuration and regcache_sync() will write the new value to ACCCTL. Signed-off-by: Tony Lindgren Acked-by: Peter Ujfalusi Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 3b8892bea9eb4f7569b64887195ee70b5cfa941c Author: Ben Skeggs Date: Fri May 10 11:57:04 2019 +1000 drm/nouveau/disp/dp: respect sink limits when selecting failsafe link configuration [ Upstream commit 13d03e9daf70dab032c03dc172e75bb98ad899c4 ] Where possible, we want the failsafe link configuration (one which won't hang the OR during modeset because of not enough bandwidth for the mode) to also be supported by the sink. This prevents "link rate unsupported by sink" messages when link training fails. Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit e9a8c9805f5860f7aa2119c6a2b172438cc51d5b Author: Binbin Wu Date: Mon Apr 8 16:09:10 2019 +0800 mfd: intel-lpss: Set the device in reset state when init [ Upstream commit dad06532292d77f37fbe831a02948a593500f682 ] In virtualized setup, when system reboots due to warm reset interrupt storm is seen. Call Trace: dump_stack+0x70/0xa5 __report_bad_irq+0x2e/0xc0 note_interrupt+0x248/0x290 ? add_interrupt_randomness+0x30/0x220 handle_irq_event_percpu+0x54/0x80 handle_irq_event+0x39/0x60 handle_fasteoi_irq+0x91/0x150 handle_irq+0x108/0x180 do_IRQ+0x52/0xf0 common_interrupt+0xf/0xf RIP: 0033:0x76fc2cfabc1d Code: 24 28 bf 03 00 00 00 31 c0 48 8d 35 63 77 0e 00 48 8d 15 2e 94 0e 00 4c 89 f9 49 89 d9 4c 89 d3 e8 b8 e2 01 00 48 8b 54 24 18 <48> 89 ef 48 89 de 4c 89 e1 e8 d5 97 01 00 84 c0 74 2d 48 8b 04 24 RSP: 002b:00007ffd247c1fc0 EFLAGS: 00000293 ORIG_RAX: ffffffffffffffda RAX: 0000000000000000 RBX: 00007ffd247c1ff0 RCX: 000000000003d3ce RDX: 0000000000000000 RSI: 00007ffd247c1ff0 RDI: 000076fc2cbb6010 RBP: 000076fc2cded010 R08: 00007ffd247c2210 R09: 00007ffd247c22a0 R10: 000076fc29465470 R11: 0000000000000000 R12: 00007ffd247c1fc0 R13: 000076fc2ce8e470 R14: 000076fc27ec9960 R15: 0000000000000414 handlers: [<000000000d3fa913>] idma64_irq Disabling IRQ #27 To avoid interrupt storm, set the device in reset state before bringing out the device from reset state. Changelog v2: - correct the subject line by adding "mfd: " Signed-off-by: Binbin Wu Acked-by: Mika Westerberg Reviewed-by: Andy Shevchenko Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 12c57327a12890e5120fdf2c94f16d7896d63528 Author: Daniel Gomez Date: Mon Apr 22 21:09:50 2019 +0200 mfd: tps65912-spi: Add missing of table registration [ Upstream commit 9e364e87ad7f2c636276c773d718cda29d62b741 ] MODULE_DEVICE_TABLE(of, should be called to complete DT OF mathing mechanism and register it. Before this patch: modinfo drivers/mfd/tps65912-spi.ko | grep alias alias: spi:tps65912 After this patch: modinfo drivers/mfd/tps65912-spi.ko | grep alias alias: of:N*T*Cti,tps65912C* alias: of:N*T*Cti,tps65912 alias: spi:tps65912 Reported-by: Javier Martinez Canillas Signed-off-by: Daniel Gomez Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 1196b79a20f7d3c78562312230584a46c9bd3f55 Author: Amit Kucheria Date: Wed Mar 20 18:47:52 2019 +0530 drivers: thermal: tsens: Don't print error message on -EPROBE_DEFER [ Upstream commit fc7d18cf6a923cde7f5e7ba2c1105bb106d3e29a ] We print a calibration failure message on -EPROBE_DEFER from nvmem/qfprom as follows: [ 3.003090] qcom-tsens 4a9000.thermal-sensor: version: 1.4 [ 3.005376] qcom-tsens 4a9000.thermal-sensor: tsens calibration failed [ 3.113248] qcom-tsens 4a9000.thermal-sensor: version: 1.4 This confuses people when, in fact, calibration succeeds later when nvmem/qfprom device is available. Don't print this message on a -EPROBE_DEFER. Signed-off-by: Amit Kucheria Signed-off-by: Eduardo Valentin Signed-off-by: Sasha Levin commit fd77a5117721d5c8da427f0767c016a326e2bd04 Author: Jiada Wang Date: Wed Apr 24 14:11:45 2019 +0900 thermal: rcar_gen3_thermal: disable interrupt in .remove [ Upstream commit 63f55fcea50c25ae5ad45af92d08dae3b84534c2 ] Currently IRQ remains enabled after .remove, later if device is probed, IRQ is requested before .thermal_init, this may cause IRQ function be called before device is initialized. this patch disables interrupt in .remove, to ensure irq function only be called after device is fully initialized. Signed-off-by: Jiada Wang Reviewed-by: Simon Horman Reviewed-by: Daniel Lezcano Signed-off-by: Eduardo Valentin Signed-off-by: Sasha Levin commit c50c4fb0cb62cbacfe45694f99f2de09b86d62df Author: Cyrill Gorcunov Date: Mon May 13 17:15:40 2019 -0700 kernel/sys.c: prctl: fix false positive in validate_prctl_map() [ Upstream commit a9e73998f9d705c94a8dca9687633adc0f24a19a ] While validating new map we require the @start_data to be strictly less than @end_data, which is fine for regular applications (this is why this nit didn't trigger for that long). These members are set from executable loaders such as elf handers, still it is pretty valid to have a loadable data section with zero size in file, in such case the start_data is equal to end_data once kernel loader finishes. As a result when we're trying to restore such programs the procedure fails and the kernel returns -EINVAL. From the image dump of a program: | "mm_start_code": "0x400000", | "mm_end_code": "0x8f5fb4", | "mm_start_data": "0xf1bfb0", | "mm_end_data": "0xf1bfb0", Thus we need to change validate_prctl_map from strictly less to less or equal operator use. Link: http://lkml.kernel.org/r/20190408143554.GY1421@uranus.lan Fixes: f606b77f1a9e3 ("prctl: PR_SET_MM -- introduce PR_SET_MM_MAP operation") Signed-off-by: Cyrill Gorcunov Cc: Andrey Vagin Cc: Dmitry Safonov <0x7f454c46@gmail.com> Cc: Pavel Emelyanov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 515d18ced8e1212f700ff08eeb932fd8cca661a0 Author: Qian Cai Date: Mon May 13 17:16:31 2019 -0700 mm/slab.c: fix an infinite loop in leaks_show() [ Upstream commit 745e10146c31b1c6ed3326286704ae251b17f663 ] "cat /proc/slab_allocators" could hang forever on SMP machines with kmemleak or object debugging enabled due to other CPUs running do_drain() will keep making kmemleak_object or debug_objects_cache dirty and unable to escape the first loop in leaks_show(), do { set_store_user_clean(cachep); drain_cpu_caches(cachep); ... } while (!is_store_user_clean(cachep)); For example, do_drain slabs_destroy slab_destroy kmem_cache_free __cache_free ___cache_free kmemleak_free_recursive delete_object_full __delete_object put_object free_object_rcu kmem_cache_free cache_free_debugcheck --> dirty kmemleak_object One approach is to check cachep->name and skip both kmemleak_object and debug_objects_cache in leaks_show(). The other is to set store_user_clean after drain_cpu_caches() which leaves a small window between drain_cpu_caches() and set_store_user_clean() where per-CPU caches could be dirty again lead to slightly wrong information has been stored but could also speed up things significantly which sounds like a good compromise. For example, # cat /proc/slab_allocators 0m42.778s # 1st approach 0m0.737s # 2nd approach [akpm@linux-foundation.org: tweak comment] Link: http://lkml.kernel.org/r/20190411032635.10325-1-cai@lca.pw Fixes: d31676dfde25 ("mm/slab: alternative implementation for DEBUG_SLAB_LEAK") Signed-off-by: Qian Cai Reviewed-by: Andrew Morton Cc: Vlastimil Babka Cc: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 13e1ea0881da64ea5d216f363fe08c44c37c65f0 Author: Yue Hu Date: Mon May 13 17:16:37 2019 -0700 mm/cma_debug.c: fix the break condition in cma_maxchunk_get() [ Upstream commit f0fd50504a54f5548eb666dc16ddf8394e44e4b7 ] If not find zero bit in find_next_zero_bit(), it will return the size parameter passed in, so the start bit should be compared with bitmap_maxno rather than cma->count. Although getting maxchunk is working fine due to zero value of order_per_bit currently, the operation will be stuck if order_per_bit is set as non-zero. Link: http://lkml.kernel.org/r/20190319092734.276-1-zbestahu@gmail.com Signed-off-by: Yue Hu Reviewed-by: Andrew Morton Cc: Michal Hocko Cc: Joe Perches Cc: David Rientjes Cc: Dmitry Safonov Cc: Joonsoo Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 38c5fce7fc488af2c3c6387a49f0c4ca02eecb8d Author: Aneesh Kumar K.V Date: Mon May 13 17:19:11 2019 -0700 mm: page_mkclean vs MADV_DONTNEED race [ Upstream commit 024eee0e83f0df52317be607ca521e0fc572aa07 ] MADV_DONTNEED is handled with mmap_sem taken in read mode. We call page_mkclean without holding mmap_sem. MADV_DONTNEED implies that pages in the region are unmapped and subsequent access to the pages in that range is handled as a new page fault. This implies that if we don't have parallel access to the region when MADV_DONTNEED is run we expect those range to be unallocated. w.r.t page_mkclean() we need to make sure that we don't break the MADV_DONTNEED semantics. MADV_DONTNEED check for pmd_none without holding pmd_lock. This implies we skip the pmd if we temporarily mark pmd none. Avoid doing that while marking the page clean. Keep the sequence same for dax too even though we don't support MADV_DONTNEED for dax mapping The bug was noticed by code review and I didn't observe any failures w.r.t test run. This is similar to commit 58ceeb6bec86d9140f9d91d71a710e963523d063 Author: Kirill A. Shutemov Date: Thu Apr 13 14:56:26 2017 -0700 thp: fix MADV_DONTNEED vs. MADV_FREE race commit ced108037c2aa542b3ed8b7afd1576064ad1362a Author: Kirill A. Shutemov Date: Thu Apr 13 14:56:20 2017 -0700 thp: fix MADV_DONTNEED vs. numa balancing race Link: http://lkml.kernel.org/r/20190321040610.14226-1-aneesh.kumar@linux.ibm.com Signed-off-by: Aneesh Kumar K.V Reviewed-by: Andrew Morton Cc: Dan Williams Cc:"Kirill A . Shutemov" Cc: Andrea Arcangeli Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 77a01e33570cc602525ee481dc6b6badb5f4e9bb Author: Yue Hu Date: Mon May 13 17:17:41 2019 -0700 mm/cma.c: fix the bitmap status to show failed allocation reason [ Upstream commit 2b59e01a3aa665f751d1410b99fae9336bd424e1 ] Currently one bit in cma bitmap represents number of pages rather than one page, cma->count means cma size in pages. So to find available pages via find_next_zero_bit()/find_next_bit() we should use cma size not in pages but in bits although current free pages number is correct due to zero value of order_per_bit. Once order_per_bit is changed the bitmap status will be incorrect. The size input in cma_debug_show_areas() is not correct. It will affect the available pages at some position to debug the failure issue. This is an example with order_per_bit = 1 Before this change: [ 4.120060] cma: number of available pages: 1@93+4@108+7@121+7@137+7@153+7@169+7@185+7@201+3@213+3@221+3@229+3@237+3@245+3@253+3@261+3@269+3@277+3@285+3@293+3@301+3@309+3@317+3@325+19@333+15@369+512@512=> 638 free of 1024 total pages After this change: [ 4.143234] cma: number of available pages: 2@93+8@108+14@121+14@137+14@153+14@169+14@185+14@201+6@213+6@221+6@229+6@237+6@245+6@253+6@261+6@269+6@277+6@285+6@293+6@301+6@309+6@317+6@325+38@333+30@369=> 252 free of 1024 total pages Obviously the bitmap status before is incorrect. Link: http://lkml.kernel.org/r/20190320060829.9144-1-zbestahu@gmail.com Signed-off-by: Yue Hu Reviewed-by: Andrew Morton Cc: Joonsoo Kim Cc: Ingo Molnar Cc: Vlastimil Babka Cc: Mike Rapoport Cc: Randy Dunlap Cc: Laura Abbott Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 25511676362d8f7d4b8805730a3d29484ceab1ec Author: Christoph Hellwig Date: Mon May 13 17:18:17 2019 -0700 initramfs: free initrd memory if opening /initrd.image fails [ Upstream commit 54c7a8916a887f357088f99e9c3a7720cd57d2c8 ] Patch series "initramfs tidyups". I've spent some time chasing down behavior in initramfs and found plenty of opportunity to improve the code. A first stab on that is contained in this series. This patch (of 7): We free the initrd memory for all successful or error cases except for the case where opening /initrd.image fails, which looks like an oversight. Steven said: : This also changes the behaviour when CONFIG_INITRAMFS_FORCE is enabled : - specifically it means that the initrd is freed (previously it was : ignored and never freed). But that seems like reasonable behaviour and : the previous behaviour looks like another oversight. Link: http://lkml.kernel.org/r/20190213174621.29297-3-hch@lst.de Signed-off-by: Christoph Hellwig Reviewed-by: Steven Price Acked-by: Mike Rapoport Cc: Catalin Marinas [arm64] Cc: Geert Uytterhoeven [m68k] Cc: Alexander Viro Cc: Russell King Cc: Will Deacon Cc: Guan Xuetao Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit e5f8857ea972ef84a27a7990989d3388bc2d09c9 Author: Yue Hu Date: Mon May 13 17:18:14 2019 -0700 mm/cma.c: fix crash on CMA allocation if bitmap allocation fails [ Upstream commit 1df3a339074e31db95c4790ea9236874b13ccd87 ] f022d8cb7ec7 ("mm: cma: Don't crash on allocation if CMA area can't be activated") fixes the crash issue when activation fails via setting cma->count as 0, same logic exists if bitmap allocation fails. Link: http://lkml.kernel.org/r/20190325081309.6004-1-zbestahu@gmail.com Signed-off-by: Yue Hu Reviewed-by: Anshuman Khandual Cc: Joonsoo Kim Cc: Laura Abbott Cc: Mike Rapoport Cc: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 5094a85d6d930beeb023e1185b94ae00ba2c3f47 Author: Linxu Fang Date: Mon May 13 17:19:17 2019 -0700 mem-hotplug: fix node spanned pages when we have a node with only ZONE_MOVABLE [ Upstream commit 299c83dce9ea3a79bb4b5511d2cb996b6b8e5111 ] 342332e6a925 ("mm/page_alloc.c: introduce kernelcore=mirror option") and later patches rewrote the calculation of node spanned pages. e506b99696a2 ("mem-hotplug: fix node spanned pages when we have a movable node"), but the current code still has problems, When we have a node with only zone_movable and the node id is not zero, the size of node spanned pages is double added. That's because we have an empty normal zone, and zone_start_pfn or zone_end_pfn is not between arch_zone_lowest_possible_pfn and arch_zone_highest_possible_pfn, so we need to use clamp to constrain the range just like the commit <96e907d13602> (bootmem: Reimplement __absent_pages_in_range() using for_each_mem_pfn_range()). e.g. Zone ranges: DMA [mem 0x0000000000001000-0x0000000000ffffff] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] Normal [mem 0x0000000100000000-0x000000023fffffff] Movable zone start for each node Node 0: 0x0000000100000000 Node 1: 0x0000000140000000 Early memory node ranges node 0: [mem 0x0000000000001000-0x000000000009efff] node 0: [mem 0x0000000000100000-0x00000000bffdffff] node 0: [mem 0x0000000100000000-0x000000013fffffff] node 1: [mem 0x0000000140000000-0x000000023fffffff] node 0 DMA spanned:0xfff present:0xf9e absent:0x61 node 0 DMA32 spanned:0xff000 present:0xbefe0 absent:0x40020 node 0 Normal spanned:0 present:0 absent:0 node 0 Movable spanned:0x40000 present:0x40000 absent:0 On node 0 totalpages(node_present_pages): 1048446 node_spanned_pages:1310719 node 1 DMA spanned:0 present:0 absent:0 node 1 DMA32 spanned:0 present:0 absent:0 node 1 Normal spanned:0x100000 present:0x100000 absent:0 node 1 Movable spanned:0x100000 present:0x100000 absent:0 On node 1 totalpages(node_present_pages): 2097152 node_spanned_pages:2097152 Memory: 6967796K/12582392K available (16388K kernel code, 3686K rwdata, 4468K rodata, 2160K init, 10444K bss, 5614596K reserved, 0K cma-reserved) It shows that the current memory of node 1 is double added. After this patch, the problem is fixed. node 0 DMA spanned:0xfff present:0xf9e absent:0x61 node 0 DMA32 spanned:0xff000 present:0xbefe0 absent:0x40020 node 0 Normal spanned:0 present:0 absent:0 node 0 Movable spanned:0x40000 present:0x40000 absent:0 On node 0 totalpages(node_present_pages): 1048446 node_spanned_pages:1310719 node 1 DMA spanned:0 present:0 absent:0 node 1 DMA32 spanned:0 present:0 absent:0 node 1 Normal spanned:0 present:0 absent:0 node 1 Movable spanned:0x100000 present:0x100000 absent:0 On node 1 totalpages(node_present_pages): 1048576 node_spanned_pages:1048576 memory: 6967796K/8388088K available (16388K kernel code, 3686K rwdata, 4468K rodata, 2160K init, 10444K bss, 1420292K reserved, 0K cma-reserved) Link: http://lkml.kernel.org/r/1554178276-10372-1-git-send-email-fanglinxu@huawei.com Signed-off-by: Linxu Fang Cc: Taku Izumi Cc: Xishi Qiu Cc: Michal Hocko Cc: Vlastimil Babka Cc: Pavel Tatashin Cc: Oscar Salvador Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ffaafd27b06799693b610ea67ba922e1622824fe Author: Mike Kravetz Date: Mon May 13 17:19:38 2019 -0700 hugetlbfs: on restore reserve error path retain subpool reservation [ Upstream commit 0919e1b69ab459e06df45d3ba6658d281962db80 ] When a huge page is allocated, PagePrivate() is set if the allocation consumed a reservation. When freeing a huge page, PagePrivate is checked. If set, it indicates the reservation should be restored. PagePrivate being set at free huge page time mostly happens on error paths. When huge page reservations are created, a check is made to determine if the mapping is associated with an explicitly mounted filesystem. If so, pages are also reserved within the filesystem. The default action when freeing a huge page is to decrement the usage count in any associated explicitly mounted filesystem. However, if the reservation is to be restored the reservation/use count within the filesystem should not be decrementd. Otherwise, a subsequent page allocation and free for the same mapping location will cause the file filesystem usage to go 'negative'. Filesystem Size Used Avail Use% Mounted on nodev 4.0G -4.0M 4.1G - /opt/hugepool To fix, when freeing a huge page do not adjust filesystem usage if PagePrivate() is set to indicate the reservation should be restored. I did not cc stable as the problem has been around since reserves were added to hugetlbfs and nobody has noticed. Link: http://lkml.kernel.org/r/20190328234704.27083-2-mike.kravetz@oracle.com Signed-off-by: Mike Kravetz Reviewed-by: Naoya Horiguchi Cc: Davidlohr Bueso Cc: Joonsoo Kim Cc: Michal Hocko Cc: "Kirill A . Shutemov" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 85e1a6c4b3e5eb384b842582f2126a8af0de5189 Author: Jérôme Glisse Date: Mon May 13 17:19:45 2019 -0700 mm/hmm: select mmu notifier when selecting HMM [ Upstream commit 734fb89968900b5c5f8edd5038bd4cdeab8c61d2 ] To avoid random config build issue, select mmu notifier when HMM is selected. In any cases when HMM get selected it will be by users that will also wants the mmu notifier. Link: http://lkml.kernel.org/r/20190403193318.16478-2-jglisse@redhat.com Signed-off-by: Jérôme Glisse Acked-by: Balbir Singh Cc: Ralph Campbell Cc: John Hubbard Cc: Dan Williams Cc: Arnd Bergmann Cc: Dan Carpenter Cc: Ira Weiny Cc: Matthew Wilcox Cc: Souptick Joarder Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit e0c3fc1f8fe3516529d2d399c6858846f895083b Author: Arnd Bergmann Date: Tue May 14 15:41:48 2019 -0700 ARM: prevent tracing IPI_CPU_BACKTRACE [ Upstream commit be167862ae7dd85c56d385209a4890678e1b0488 ] Patch series "compiler: allow all arches to enable CONFIG_OPTIMIZE_INLINING", v3. This patch (of 11): When function tracing for IPIs is enabled, we get a warning for an overflow of the ipi_types array with the IPI_CPU_BACKTRACE type as triggered by raise_nmi(): arch/arm/kernel/smp.c: In function 'raise_nmi': arch/arm/kernel/smp.c:489:2: error: array subscript is above array bounds [-Werror=array-bounds] trace_ipi_raise(target, ipi_types[ipinr]); This is a correct warning as we actually overflow the array here. This patch raise_nmi() to call __smp_cross_call() instead of smp_cross_call(), to avoid calling into ftrace. For clarification, I'm also adding a two new code comments describing how this one is special. The warning appears to have shown up after commit e7273ff49acf ("ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI"), which changed the number assignment from '15' to '8', but as far as I can tell has existed since the IPI tracepoints were first introduced. If we decide to backport this patch to stable kernels, we probably need to backport e7273ff49acf as well. [yamada.masahiro@socionext.com: rebase on v5.1-rc1] Link: http://lkml.kernel.org/r/20190423034959.13525-2-yamada.masahiro@socionext.com Fixes: e7273ff49acf ("ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI") Fixes: 365ec7b17327 ("ARM: add IPI tracepoints") # v3.17 Signed-off-by: Arnd Bergmann Signed-off-by: Masahiro Yamada Cc: Heiko Carstens Cc: Arnd Bergmann Cc: Ingo Molnar Cc: Christophe Leroy Cc: Mathieu Malaterre Cc: "H. Peter Anvin" Cc: Thomas Gleixner Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Ralf Baechle Cc: Stefan Agner Cc: Boris Brezillon Cc: Miquel Raynal Cc: Richard Weinberger Cc: David Woodhouse Cc: Brian Norris Cc: Marek Vasut Cc: Russell King Cc: Borislav Petkov Cc: Mark Rutland Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 4d3811a60e104bc7dc532b8081bcfe590e7ce5fc Author: Guenter Roeck Date: Mon May 13 07:46:21 2019 -0700 drm/pl111: Initialize clock spinlock early [ Upstream commit 3e01ae2612bdd7975c74ec7123d7f8f5e6eed795 ] The following warning is seen on systems with broken clock divider. INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 0 PID: 1 Comm: swapper Not tainted 5.1.0-09698-g1fb3b52 #1 Hardware name: ARM Integrator/CP (Device Tree) [] (unwind_backtrace) from [] (show_stack+0x10/0x18) [] (show_stack) from [] (dump_stack+0x18/0x24) [] (dump_stack) from [] (register_lock_class+0x674/0x6f8) [] (register_lock_class) from [] (__lock_acquire+0x68/0x2128) [] (__lock_acquire) from [] (lock_acquire+0x110/0x21c) [] (lock_acquire) from [] (_raw_spin_lock+0x34/0x48) [] (_raw_spin_lock) from [] (pl111_display_enable+0xf8/0x5fc) [] (pl111_display_enable) from [] (drm_atomic_helper_commit_modeset_enables+0x1ec/0x244) Since commit eedd6033b4c8 ("drm/pl111: Support variants with broken clock divider"), the spinlock is not initialized if the clock divider is broken. Initialize it earlier to fix the problem. Fixes: eedd6033b4c8 ("drm/pl111: Support variants with broken clock divider") Cc: Linus Walleij Signed-off-by: Guenter Roeck Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/1557758781-23586-1-git-send-email-linux@roeck-us.net Signed-off-by: Sasha Levin commit 20de754a7d8852eb25a952b5181a278600a1698b Author: Li Rongqing Date: Tue May 14 15:46:20 2019 -0700 ipc: prevent lockup on alloc_msg and free_msg [ Upstream commit d6a2946a88f524a47cc9b79279667137899db807 ] msgctl10 of ltp triggers the following lockup When CONFIG_KASAN is enabled on large memory SMP systems, the pages initialization can take a long time, if msgctl10 requests a huge block memory, and it will block rcu scheduler, so release cpu actively. After adding schedule() in free_msg, free_msg can not be called when holding spinlock, so adding msg to a tmp list, and free it out of spinlock rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: Tasks blocked on level-1 rcu_node (CPUs 16-31): P32505 rcu: Tasks blocked on level-1 rcu_node (CPUs 48-63): P34978 rcu: (detected by 11, t=35024 jiffies, g=44237529, q=16542267) msgctl10 R running task 21608 32505 2794 0x00000082 Call Trace: preempt_schedule_irq+0x4c/0xb0 retint_kernel+0x1b/0x2d RIP: 0010:__is_insn_slot_addr+0xfb/0x250 Code: 82 1d 00 48 8b 9b 90 00 00 00 4c 89 f7 49 c1 ee 03 e8 59 83 1d 00 48 b8 00 00 00 00 00 fc ff df 4c 39 eb 48 89 9d 58 ff ff ff <41> c6 04 06 f8 74 66 4c 8d 75 98 4c 89 f1 48 c1 e9 03 48 01 c8 48 RSP: 0018:ffff88bce041f758 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13 RAX: dffffc0000000000 RBX: ffffffff8471bc50 RCX: ffffffff828a2a57 RDX: dffffc0000000000 RSI: dffffc0000000000 RDI: ffff88bce041f780 RBP: ffff88bce041f828 R08: ffffed15f3f4c5b3 R09: ffffed15f3f4c5b3 R10: 0000000000000001 R11: ffffed15f3f4c5b2 R12: 000000318aee9b73 R13: ffffffff8471bc50 R14: 1ffff1179c083ef0 R15: 1ffff1179c083eec kernel_text_address+0xc1/0x100 __kernel_text_address+0xe/0x30 unwind_get_return_address+0x2f/0x50 __save_stack_trace+0x92/0x100 create_object+0x380/0x650 __kmalloc+0x14c/0x2b0 load_msg+0x38/0x1a0 do_msgsnd+0x19e/0xcf0 do_syscall_64+0x117/0x400 entry_SYSCALL_64_after_hwframe+0x49/0xbe rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: Tasks blocked on level-1 rcu_node (CPUs 0-15): P32170 rcu: (detected by 14, t=35016 jiffies, g=44237525, q=12423063) msgctl10 R running task 21608 32170 32155 0x00000082 Call Trace: preempt_schedule_irq+0x4c/0xb0 retint_kernel+0x1b/0x2d RIP: 0010:lock_acquire+0x4d/0x340 Code: 48 81 ec c0 00 00 00 45 89 c6 4d 89 cf 48 8d 6c 24 20 48 89 3c 24 48 8d bb e4 0c 00 00 89 74 24 0c 48 c7 44 24 20 b3 8a b5 41 <48> c1 ed 03 48 c7 44 24 28 b4 25 18 84 48 c7 44 24 30 d0 54 7a 82 RSP: 0018:ffff88af83417738 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff13 RAX: dffffc0000000000 RBX: ffff88bd335f3080 RCX: 0000000000000002 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88bd335f3d64 RBP: ffff88af83417758 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: ffffed13f3f745b2 R12: 0000000000000000 R13: 0000000000000002 R14: 0000000000000000 R15: 0000000000000000 is_bpf_text_address+0x32/0xe0 kernel_text_address+0xec/0x100 __kernel_text_address+0xe/0x30 unwind_get_return_address+0x2f/0x50 __save_stack_trace+0x92/0x100 save_stack+0x32/0xb0 __kasan_slab_free+0x130/0x180 kfree+0xfa/0x2d0 free_msg+0x24/0x50 do_msgrcv+0x508/0xe60 do_syscall_64+0x117/0x400 entry_SYSCALL_64_after_hwframe+0x49/0xbe Davidlohr said: "So after releasing the lock, the msg rbtree/list is empty and new calls will not see those in the newly populated tmp_msg list, and therefore they cannot access the delayed msg freeing pointers, which is good. Also the fact that the node_cache is now freed before the actual messages seems to be harmless as this is wanted for msg_insert() avoiding GFP_ATOMIC allocations, and after releasing the info->lock the thing is freed anyway so it should not change things" Link: http://lkml.kernel.org/r/1552029161-4957-1-git-send-email-lirongqing@baidu.com Signed-off-by: Li RongQing Signed-off-by: Zhang Yu Reviewed-by: Davidlohr Bueso Cc: Manfred Spraul Cc: Arnd Bergmann Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 91ae202e2c88a026eb2065fbee10b8e80591a27d Author: Christian Brauner Date: Tue May 14 15:44:55 2019 -0700 sysctl: return -EINVAL if val violates minmax [ Upstream commit e260ad01f0aa9e96b5386d5cd7184afd949dc457 ] Currently when userspace gives us a values that overflow e.g. file-max and other callers of __do_proc_doulongvec_minmax() we simply ignore the new value and leave the current value untouched. This can be problematic as it gives the illusion that the limit has indeed be bumped when in fact it failed. This commit makes sure to return EINVAL when an overflow is detected. Please note that this is a userspace facing change. Link: http://lkml.kernel.org/r/20190210203943.8227-4-christian@brauner.io Signed-off-by: Christian Brauner Acked-by: Luis Chamberlain Cc: Kees Cook Cc: Alexey Dobriyan Cc: Al Viro Cc: Dominik Brodowski Cc: "Eric W. Biederman" Cc: Joe Lawrence Cc: Waiman Long Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 5b6619b4d206662f0f6df20fa660f468f56bb75d Author: Hou Tao Date: Tue May 14 15:44:32 2019 -0700 fs/fat/file.c: issue flush after the writeback of FAT [ Upstream commit bd8309de0d60838eef6fb575b0c4c7e95841cf73 ] fsync() needs to make sure the data & meta-data of file are persistent after the return of fsync(), even when a power-failure occurs later. In the case of fat-fs, the FAT belongs to the meta-data of file, so we need to issue a flush after the writeback of FAT instead before. Also bail out early when any stage of fsync fails. Link: http://lkml.kernel.org/r/20190409030158.136316-1-houtao1@huawei.com Signed-off-by: Hou Tao Acked-by: OGAWA Hirofumi Cc: Al Viro Cc: Jan Kara Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 2a89e4c5ee2ee5964bc8b974f120e1a8eded25e9 Author: Kangjie Lu Date: Tue May 14 15:44:49 2019 -0700 rapidio: fix a NULL pointer dereference when create_workqueue() fails [ Upstream commit 23015b22e47c5409620b1726a677d69e5cd032ba ] In case create_workqueue fails, the fix releases resources and returns -ENOMEM to avoid NULL pointer dereference. Signed-off-by: Kangjie Lu Acked-by: Alexandre Bounine Cc: Matt Porter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin