commit 1cdd9ce77b756ce540febb4006e234b3ef084a31 Author: Greg Kroah-Hartman Date: Sat Jan 29 10:59:25 2022 +0100 Linux 5.16.4 Link: https://lore.kernel.org/r/20220127180258.892788582@linuxfoundation.org Tested-by: Shuah Khan Tested-by: Florian Fainelli Tested-by: Zan Aziz Tested-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Tested-by: Rudi Heitbaum Tested-by: Ron Economos Tested-by: Ronald Warsow Tested-by: Fox Chen Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 1d833b27fb708d6fdf5de9f6b3a8be4bd4321565 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 f8b6cb05dc3ff29977daee64ba1900211e65824f Author: Russell King Date: Fri Nov 5 16:50:45 2021 +0000 arm64/bpf: Remove 128MB limit for BPF JIT programs commit b89ddf4cca43f1269093942cf5c4e457fd45c335 upstream. Commit 91fc957c9b1d ("arm64/bpf: don't allocate BPF JIT programs in module memory") restricts BPF JIT program allocation to a 128MB region to ensure BPF programs are still in branching range of each other. However this restriction should not apply to the aarch64 JIT, since BPF_JMP | BPF_CALL are implemented as a 64-bit move into a register and then a BLR instruction - which has the effect of being able to call anything without proximity limitation. The practical reason to relax this restriction on JIT memory is that 128MB of JIT memory can be quickly exhausted, especially where PAGE_SIZE is 64KB - one page is needed per program. In cases where seccomp filters are applied to multiple VMs on VM launch - such filters are classic BPF but converted to BPF - this can severely limit the number of VMs that can be launched. In a world where we support BPF JIT always on, turning off the JIT isn't always an option either. Fixes: 91fc957c9b1d ("arm64/bpf: don't allocate BPF JIT programs in module memory") Suggested-by: Ard Biesheuvel Signed-off-by: Russell King Signed-off-by: Daniel Borkmann Tested-by: Alan Maguire Link: https://lore.kernel.org/bpf/1636131046-5982-2-git-send-email-alan.maguire@oracle.com Signed-off-by: Greg Kroah-Hartman commit 0c919af28a1b3b94393bebd1750912c80e61148f 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 332d29c8c562ff60c390601afc02a670d4e6a3a8 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 ead51b4bbfd6341f9e437726ee3b8fb28043c84e Author: Shakeel Butt Date: Fri Jan 14 14:05:39 2022 -0800 memcg: better bounds on the memcg stats updates commit 5b3be698a872c490dbed524f3e2463701ab21339 upstream. Commit 11192d9c124d ("memcg: flush stats only if updated") added tracking of memcg stats updates which is used by the readers to flush only if the updates are over a certain threshold. However each individual update can correspond to a large value change for a given stat. For example adding or removing a hugepage to an LRU changes the stat by thp_nr_pages (512 on x86_64). Treating the update related to THP as one can keep the stat off, in theory, by (thp_nr_pages * nr_cpus * CHARGE_BATCH) before flush. To handle such scenarios, this patch adds consideration of the stat update value as well instead of just the update event. In addition let the asyn flusher unconditionally flush the stats to put time limit on the stats skew and hopefully a lot less readers would need to flush. Link: https://lkml.kernel.org/r/20211118065350.697046-1-shakeelb@google.com Signed-off-by: Shakeel Butt Cc: Johannes Weiner Cc: Michal Hocko Cc: "Michal Koutný" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Ivan Babrou Signed-off-by: Greg Kroah-Hartman commit c0c6cc80e5f9bb11ddb73f40979a196af8648a4e Author: Manish Chopra Date: Tue Jan 25 10:57:49 2022 -0800 bnx2x: Invalidate fastpath HSI version for VFs commit 802d4d207e75d7208ff75adb712b556c1e91cf1c upstream Commit 0a6890b9b4df ("bnx2x: Utilize FW 7.13.15.0.") added validation for fastpath HSI versions for different client init which was not meant for SR-IOV VF clients, which resulted in firmware asserts when running VF clients with different fastpath HSI version. This patch along with the new firmware support in patch #1 fixes this behavior in order to not validate fastpath HSI version for the VFs. Fixes: 0a6890b9b4df ("bnx2x: Utilize FW 7.13.15.0.") Signed-off-by: Manish Chopra Signed-off-by: Prabhakar Kushwaha Signed-off-by: Alok Prasad Signed-off-by: Ariel Elior Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 54bee93452753eb10ee990ef484d62abe6e50f07 Author: Manish Chopra Date: Tue Jan 25 10:57:48 2022 -0800 bnx2x: Utilize firmware 7.13.21.0 commit b7a49f73059fe6147b6b78e8f674ce0d21237432 upstream This new firmware addresses few important issues and enhancements as mentioned below - - Support direct invalidation of FP HSI Ver per function ID, required for invalidating FP HSI Ver prior to each VF start, as there is no VF start - BRB hardware block parity error detection support for the driver - Fix the FCOE underrun flow - Fix PSOD during FCoE BFS over the NIC ports after preboot driver - Maintains backward compatibility This patch incorporates this new firmware 7.13.21.0 in bnx2x driver. Signed-off-by: Manish Chopra Signed-off-by: Prabhakar Kushwaha Signed-off-by: Alok Prasad Signed-off-by: Ariel Elior Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9f793ce7b8f5e98a44b18eba06fe6919538ba81c Author: Pavel Begunkov Date: Sun Jan 9 00:53:22 2022 +0000 io_uring: fix not released cached task refs commit 3cc7fdb9f90a25ae92250bf9e6cf3b9556b230e9 upstream. tctx_task_work() may get run after io_uring cancellation and so there will be no one to put cached in tctx task refs that may have been added back by tw handlers using inline completion infra, Call io_uring_drop_tctx_refs() at the end of the main tw handler to release them. Cc: stable@vger.kernel.org # 5.15+ Reported-by: Lukas Bulwahn Fixes: e98e49b2bbf7 ("io_uring: extend task put optimisations") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/69f226b35fbdb996ab799a8bbc1c06bf634ccec1.1641688805.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 5a440ead57de48c2ac66b04b8e07c8730cc0cf0f Author: Mario Limonciello Date: Fri Jan 7 15:40:10 2022 -0600 drm/amd/display: reset dcn31 SMU mailbox on failures commit 83293f7f3d15fc56e86bd5067a2c88b6b233ac3a upstream. Otherwise future commands may fail as well leading to downstream problems that look like they stemmed from a timeout the first time but really didn't. Signed-off-by: Mario Limonciello Reviewed-by: Nicholas Kazlauskas Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit ec1b6497a2bc0293c064337e981ea1f6cbe57930 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