commit 7cdf2951f80d189e9a0a5b6836664ccc8bfb2e7e Author: Greg Kroah-Hartman Date: Sat Jan 29 10:25:11 2022 +0100 Linux 5.4.175 Link: https://lore.kernel.org/r/20220127180258.362000607@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 84b1259fe36ae0915f3d6ddcea6377779de48b82 Author: Mathias Krause Date: Thu Jan 27 18:34:19 2022 +1000 drm/vmwgfx: Fix stale file descriptors on failed usercopy commit a0f90c8815706981c483a652a6aefca51a5e191c upstream. A failing usercopy of the fence_rep object will lead to a stale entry in the file descriptor table as put_unused_fd() won't release it. This enables userland to refer to a dangling 'file' object through that still valid file descriptor, leading to all kinds of use-after-free exploitation scenarios. Fix this by deferring the call to fd_install() until after the usercopy has succeeded. Fixes: c906965dee22 ("drm/vmwgfx: Add export fence to file descriptor support") Signed-off-by: Mathias Krause Signed-off-by: Zack Rusin Signed-off-by: Dave Airlie Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 16895e4eac364487a1f1060004a4f3b6c571be27 Author: Jan Kara Date: Mon Jan 10 19:19:23 2022 +0100 select: Fix indefinitely sleeping task in poll_schedule_timeout() commit 68514dacf2715d11b91ca50d88de047c086fea9c upstream. A task can end up indefinitely sleeping in do_select() -> poll_schedule_timeout() when the following race happens: TASK1 (thread1) TASK2 TASK1 (thread2) do_select() setup poll_wqueues table with 'fd' write data to 'fd' pollwake() table->triggered = 1 closes 'fd' thread1 is waiting for poll_schedule_timeout() - sees table->triggered table->triggered = 0 return -EINTR loop back in do_select() But at this point when TASK1 loops back, the fdget() in the setup of poll_wqueues fails. So now so we never find 'fd' is ready for reading and sleep in poll_schedule_timeout() indefinitely. Treat an fd that got closed as a fd on which some event happened. This makes sure cannot block indefinitely in do_select(). Another option would be to return -EBADF in this case but that has a potential of subtly breaking applications that excercise this behavior and it happens to work for them. So returning fd as active seems like a safer choice. Suggested-by: Linus Torvalds CC: stable@vger.kernel.org Signed-off-by: Jan Kara Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 53d5b08d8e98c9b0067c87aacd376b226ae9c4af Author: Tim Harvey Date: Wed Nov 3 09:54:15 2021 -0700 mmc: sdhci-esdhc-imx: disable CMDQ support commit adab993c25191b839b415781bdc7173a77315240 upstream. On IMX SoC's which support CMDQ the following can occur during high a high cpu load: mmc2: cqhci: ============ CQHCI REGISTER DUMP =========== mmc2: cqhci: Caps: 0x0000310a | Version: 0x00000510 mmc2: cqhci: Config: 0x00001001 | Control: 0x00000000 mmc2: cqhci: Int stat: 0x00000000 | Int enab: 0x00000006 mmc2: cqhci: Int sig: 0x00000006 | Int Coal: 0x00000000 mmc2: cqhci: TDL base: 0x8003f000 | TDL up32: 0x00000000 mmc2: cqhci: Doorbell: 0xbf01dfff | TCN: 0x00000000 mmc2: cqhci: Dev queue: 0x00000000 | Dev Pend: 0x08000000 mmc2: cqhci: Task clr: 0x00000000 | SSC1: 0x00011000 mmc2: cqhci: SSC2: 0x00000001 | DCMD rsp: 0x00000800 mmc2: cqhci: RED mask: 0xfdf9a080 | TERRI: 0x00000000 mmc2: cqhci: Resp idx: 0x0000000d | Resp arg: 0x00000000 mmc2: sdhci: ============ SDHCI REGISTER DUMP =========== mmc2: sdhci: Sys addr: 0x7c722000 | Version: 0x00000002 mmc2: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000020 mmc2: sdhci: Argument: 0x00018000 | Trn mode: 0x00000023 mmc2: sdhci: Present: 0x01f88008 | Host ctl: 0x00000030 mmc2: sdhci: Power: 0x00000002 | Blk gap: 0x00000080 mmc2: sdhci: Wake-up: 0x00000008 | Clock: 0x0000000f mmc2: sdhci: Timeout: 0x0000008f | Int stat: 0x00000000 mmc2: sdhci: Int enab: 0x107f4000 | Sig enab: 0x107f4000 mmc2: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000502 mmc2: sdhci: Caps: 0x07eb0000 | Caps_1: 0x8000b407 mmc2: sdhci: Cmd: 0x00000d1a | Max curr: 0x00ffffff mmc2: sdhci: Resp[0]: 0x00000000 | Resp[1]: 0xffc003ff mmc2: sdhci: Resp[2]: 0x328f5903 | Resp[3]: 0x00d07f01 mmc2: sdhci: Host ctl2: 0x00000088 mmc2: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0xfe179020 mmc2: sdhci-esdhc-imx: ========= ESDHC IMX DEBUG STATUS DUMP ==== mmc2: sdhci-esdhc-imx: cmd debug status: 0x2120 mmc2: sdhci-esdhc-imx: data debug status: 0x2200 mmc2: sdhci-esdhc-imx: trans debug status: 0x2300 mmc2: sdhci-esdhc-imx: dma debug status: 0x2400 mmc2: sdhci-esdhc-imx: adma debug status: 0x2510 mmc2: sdhci-esdhc-imx: fifo debug status: 0x2680 mmc2: sdhci-esdhc-imx: async fifo debug status: 0x2750 mmc2: sdhci: ============================================ For now, disable CMDQ support on the imx8qm/imx8qxp/imx8mm until the issue is found and resolved. Fixes: bb6e358169bf6 ("mmc: sdhci-esdhc-imx: add CMDQ support") Fixes: cde5e8e9ff146 ("mmc: sdhci-esdhc-imx: Add an new esdhc_soc_data for i.MX8MM") Cc: stable@vger.kernel.org Signed-off-by: Tim Harvey Reviewed-by: Haibo Chen Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20211103165415.2016-1-tharvey@gateworks.com Signed-off-by: Ulf Hansson Signed-off-by: Andrey Zhizhikin Signed-off-by: Greg Kroah-Hartman commit c3fa7ce43cddf8eacf8d0c04e1467d68449547c9 Author: Phil Elwell Date: Tue Jan 25 11:42:22 2022 -0800 ARM: dts: gpio-ranges property is now required commit c8013355ead68dce152cf426686f8a5f80d88b40 upstream Since [1], added in 5.7, the absence of a gpio-ranges property has prevented GPIOs from being restored to inputs when released. Add those properties for BCM283x and BCM2711 devices. [1] commit 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges") Link: https://lore.kernel.org/r/20220104170247.956760-1-linus.walleij@linaro.org Fixes: 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges") Fixes: 266423e60ea1 ("pinctrl: bcm2835: Change init order for gpio hogs") Reported-by: Stefan Wahren Reported-by: Florian Fainelli Reported-by: Jan Kiszka Signed-off-by: Phil Elwell Acked-by: Florian Fainelli Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20211206092237.4105895-3-phil@raspberrypi.com Signed-off-by: Linus Walleij Acked-by: Florian Fainelli Signed-off-by: Olof Johansson [florian: Remove bcm2711.dtsi hunk which does not exist in 5.4] Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 75278f1aff5e14c904d3503c6f836c42a7afb441 Author: Phil Elwell Date: Tue Jan 25 11:42:21 2022 -0800 pinctrl: bcm2835: Change init order for gpio hogs commit 266423e60ea1b953fcc0cd97f3dad85857e434d1 upstream ...and gpio-ranges pinctrl-bcm2835 is a combined pinctrl/gpio driver. Currently the gpio side is registered first, but this breaks gpio hogs (which are configured during gpiochip_add_data). Part of the hog initialisation is a call to pinctrl_gpio_request, and since the pinctrl driver hasn't yet been registered this results in an -EPROBE_DEFER from which it can never recover. Change the initialisation sequence to register the pinctrl driver first. This also solves a similar problem with the gpio-ranges property, which is required in order for released pins to be returned to inputs. Fixes: 73345a18d464b ("pinctrl: bcm2835: Pass irqchip when adding gpiochip") Signed-off-by: Phil Elwell Reviewed-by: Florian Fainelli Link: https://lore.kernel.org/r/20211206092237.4105895-2-phil@raspberrypi.com Signed-off-by: Linus Walleij Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 0d006bb08d760e5c8a124a55b85020e22cc2ee27 Author: Florian Fainelli Date: Tue Jan 25 11:42:20 2022 -0800 pinctrl: bcm2835: Add support for wake-up interrupts commit 920fecc1aa4591da27ef9dcb338fc5da86b404d7 upstream Leverage the IRQCHIP_MASK_ON_SUSPEND flag in order to avoid having to specifically treat the GPIO interrupts during suspend and resume, and simply implement an irq_set_wake() callback that is responsible for enabling the parent wake-up interrupt as a wake-up interrupt. To avoid allocating unnecessary resources for other chips, the wake-up interrupts are only initialized if we have a brcm,bcm7211-gpio compatibility string. Signed-off-by: Florian Fainelli Link: https://lore.kernel.org/r/20200531001101.24945-5-f.fainelli@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 08fd6274380af2365e6f2aadf3264ff817400a80 Author: Florian Fainelli Date: Tue Jan 25 11:42:19 2022 -0800 pinctrl: bcm2835: Match BCM7211 compatible string commit 562c856f96d22ef1204b0a314bc52e85617199b4 upstream The BCM7211 SoC uses the same pinconf_ops as the ones defined for the BCM2711 SoC, match the compatible string and use the correct set of options. Signed-off-by: Florian Fainelli Link: https://lore.kernel.org/r/20200531001101.24945-4-f.fainelli@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit ac3daf50c150e96e4cdf79f417821356eb3fe677 Author: Stefan Wahren Date: Tue Jan 25 11:42:18 2022 -0800 pinctrl: bcm2835: Add support for all GPIOs on BCM2711 commit b1d84a3d0a26c5844a22bc09a42704b9371208bb upstream The BCM2711 supports 58 GPIOs. So extend pinctrl and GPIOs accordingly. Signed-off-by: Stefan Wahren Link: https://lore.kernel.org/r/1581166975-22949-4-git-send-email-stefan.wahren@i2se.com Reviewed-by: Nicolas Saenz Julienne Signed-off-by: Linus Walleij Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit e5237171117c20ac9fff5795e2523ea9efd883ee Author: Stefan Wahren Date: Tue Jan 25 11:42:17 2022 -0800 pinctrl: bcm2835: Refactor platform data commit 90bfaf028d61a6d523c685b63c2bcc94eebb8057 upstream This prepares the platform data to be easier to extend for more GPIOs. Except of this there is no functional change. Signed-off-by: Stefan Wahren Link: https://lore.kernel.org/r/1581166975-22949-3-git-send-email-stefan.wahren@i2se.com Reviewed-by: Nicolas Saenz Julienne Signed-off-by: Linus Walleij Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 33e48b5305eb8078cddec7ee44b7c659210108f3 Author: Stefan Wahren Date: Tue Jan 25 11:42:16 2022 -0800 pinctrl: bcm2835: Drop unused define commit be30d5de0a5a52c6ee2cc453a51301037ab94aa upstream There is no usage for this define, so drop it. Signed-off-by: Stefan Wahren Link: https://lore.kernel.org/r/1580148908-4863-2-git-send-email-stefan.wahren@i2se.com Reviewed-by: Nicolas Saenz Julienne Signed-off-by: Linus Walleij Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 75ca9c1d96c7e819c8a36ec8941e0602940701a5 Author: Paul E. McKenney Date: Fri Sep 17 15:04:48 2021 -0700 rcu: Tighten rcu_advance_cbs_nowake() checks commit 614ddad17f22a22e035e2ea37a04815f50362017 upstream. Currently, rcu_advance_cbs_nowake() checks that a grace period is in progress, however, that grace period could end just after the check. This commit rechecks that a grace period is still in progress while holding the rcu_node structure's lock. The grace period cannot end while the current CPU's rcu_node structure's ->lock is held, thus avoiding false positives from the WARN_ON_ONCE(). As Daniel Vacek noted, it is not necessary for the rcu_node structure to have a CPU that has not yet passed through its quiescent state. Tested-by: Guillaume Morin Signed-off-by: Paul E. McKenney Signed-off-by: Greg Kroah-Hartman commit 1b5553c79d52f17e735cd924ff2178a2409e6d0b Author: Tvrtko Ursulin Date: Tue Oct 19 13:27:10 2021 +0100 drm/i915: Flush TLBs before releasing backing store commit 7938d61591d33394a21bdd7797a245b65428f44c upstream. We need to flush TLBs before releasing backing store otherwise userspace is able to encounter stale entries if a) it is not declaring access to certain buffers and b) it races with the backing store release from a such undeclared execution already executing on the GPU in parallel. The approach taken is to mark any buffer objects which were ever bound to the GPU and to trigger a serialized TLB flush when their backing store is released. Alternatively the flushing could be done on VMA unbind, at which point we would be able to ascertain whether there is potential a parallel GPU execution (which could race), but essentially it boils down to paying the cost of TLB flushes potentially needlessly at VMA unbind time (when the backing store is not known to be going away so not needed for safety), versus potentially needlessly at backing store relase time (since we at that point cannot tell whether there is anything executing on the GPU which uses that object). Thereforce simplicity of implementation has been chosen for now with scope to benchmark and refine later as required. Signed-off-by: Tvrtko Ursulin Reported-by: Sushma Venkatesh Reddy Reviewed-by: Daniel Vetter Acked-by: Dave Airlie Cc: Daniel Vetter Cc: Jon Bloomfield Cc: Joonas Lahtinen Cc: Jani Nikula Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman