linux.git, branch v5.16.4

Linux 5.16.4

2022-01-29T09:59:25+00:00

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

drm/vmwgfx: Fix stale file descriptors on failed usercopy

2022-01-29T09:59:24+00:00

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

arm64/bpf: Remove 128MB limit for BPF JIT programs

2022-01-29T09:59:24+00:00

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

select: Fix indefinitely sleeping task in poll_schedule_timeout()

2022-01-29T09:59:24+00:00

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

rcu: Tighten rcu_advance_cbs_nowake() checks

2022-01-29T09:59:24+00:00

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

memcg: better bounds on the memcg stats updates

2022-01-29T09:59:24+00:00

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

bnx2x: Invalidate fastpath HSI version for VFs

2022-01-29T09:59:24+00:00

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

bnx2x: Utilize firmware 7.13.21.0

2022-01-29T09:59:24+00:00

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

io_uring: fix not released cached task refs

2022-01-29T09:59:24+00:00

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

drm/amd/display: reset dcn31 SMU mailbox on failures

2022-01-29T09:59:24+00:00

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