linux-stable.git/tools, branch v7.2.4

selftests/mm: fix on-fault-limit false failure under sudo-rs

2026-09-07T15:37:28+00:00

commit 98df164036bed307a16e7c124ad023c2c13c4b76 upstream.

run_vmtests.sh runs on-fault-limit as the nobody user via "sudo -u nobody
./on-fault-limit", guarded by a check that nobody can access the binary
("sudo -u nobody ls ./on-fault-limit").

The guard resolves the relative path from the inherited working directory,
which only requires search permission on the test directory itself.
Classic sudo passes the relative path through to execve() the same way, so
the two agree.  However, sudo-rs (the default sudo implementation since
Ubuntu 25.10) canonicalizes the command to an absolute path before
executing it, which requires search permission on every ancestor
directory.  When the kernel tree lives under a private home directory
(mode 0750, the Ubuntu default for new users since 21.04), the guard
passes but the execution fails with "command not found", and the test is
reported as a false FAIL:

  # running sudo -u nobody ./on-fault-limit
  sudo: './on-fault-limit': command not found
  # [FAIL]

Wrap the command in "sh -c" so that sudo only resolves the shell binary,
and the relative path is resolved by nobody's shell from the inherited
working directory, matching what the guard checks.  This is the only "sudo
-u nobody" invocation in the script; uid, cwd, rlimits (including
RLIMIT_MEMLOCK, which this test exercises) and the exit status are
unchanged through sh.

Verified on Ubuntu 26.04 (sudo-rs 0.2.13): the test now runs and passes
instead of failing.  Verified on Ubuntu 24.04 (sudo 1.9.15p5): behavior is
unchanged.

Link: https://lore.kernel.org/20260713092700.464376-1-injaeryou@gmail.com
Fixes: 5d2146a3354f ("selftests/mm: skip mlock tests if nobody user can't read it")
Signed-off-by: Injae Ryou 
Cc: Brendan Jackman 
Cc: Brendan Jackman 
Cc: David Hildenbrand 
Cc: Lorenzo Stoakes 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

sched_ext: Fix scx_bpf_dsq_reenq___compat kfunc extern prototype

2026-09-07T15:37:04+00:00

commit 62f3d531e41a7e6e0dc8d37ea377c50488decb56 upstream.

scx_bpf_dsq_reenq() is registered with KF_IMPLICIT_ARGS and its kernel BTF
prototype omits the trailing bpf_prog_aux argument. The ___compat extern
declares the argument explicitly, so libbpf never matches the prototype and
the weak extern silently stays unresolved on every kernel. The wrapper
always takes the old fallback path, which disables generic reenq users like
scx_qmap's lowpri mechanism and fails non-local reenq with "kernel too old"
even on kernels that have the kfunc.

Drop the explicit aux argument. Also correct the stale v6.20 reference, the
kfunc was added in v7.1.

Fixes: 9c34c5074d1b ("sched_ext: Introduce scx_bpf_dsq_reenq() for remote local DSQ reenqueue")
Cc: stable@vger.kernel.org # v7.1+
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

sched_ext: Fix inverted ops.core_sched_before() invocation

2026-09-07T15:37:03+00:00

commit f7b6d128dd49a6eec09066ecfd29095f12588786 upstream.

scx_prio_less() implements prio_less() semantics - %true means that @a is
the lower priority and should run after @b. ops.core_sched_before() is
documented to return %true when @a should run before @b. scx_prio_less()
returns the op's value as-is, inverting the documented semantics at runtime.

Call the op with the arguments swapped.

scx_qmap followed the wiring instead of the documentation and returned %true
for the younger task, so the two inversions canceled out and it behaved as
intended. Flip its comparison to match. scx_qmap is likely the only current
user in or out of the kernel tree. Any scheduler written the same way needs
the same flip, while schedulers following the documentation are fixed by
this change.

Fixes: 7b0888b7cc19 ("sched_ext: Implement core-sched support")
Cc: stable@vger.kernel.org # v6.12+
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

sched_ext: Fix scx_bpf_dsq_move_to_local___v2 compat detection

2026-09-07T15:37:03+00:00

commit 56bbc91219c0711f1580a8ba7cd60471b6e1684e upstream.

libbpf strips the last ___flavor suffix when resolving kfunc externs, so
the bare ___v2 declaration resolves to scx_bpf_dsq_move_to_local, whose
BTF proto lacks @enq_flags. The extern never matches, bpf_ksym_exists()
returns false on every kernel that has the ___v2 kfunc, and the macro
falls back to ___v1, silently dropping @enq_flags.

Add the trailing ___compat suffix used by the other versioned externs in
this file (scx_bpf_dsq_insert___v2, scx_bpf_reenqueue_local___v2).

Any caller passing non-zero @enq_flags through the compat macro silently
loses them.

Fixes: 860683763ebf ("sched_ext: Add enq_flags to scx_bpf_dsq_move_to_local()")
Cc: stable@vger.kernel.org # v7.1+
Assisted-by: Z.ai:glm-5.2
Signed-off-by: fangqiurong 
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

sched_ext: Replace SCX_RQ_BAL_KEEP with a dispatch verdict return

2026-09-07T15:37:03+00:00

commit ffaab58d217581cb75353168f8812a16e10463fc upstream.

SCX_RQ_BAL_KEEP tells the pick to keep running the previous task, a leftover
from when balancing and picking were separate operations. An rq-level flag
only works while dispatches and picks pair up one to one, which core
scheduling breaks: selections interleave through dispatch's lock drops and a
pick can consume a stale flag, keeping a task that has since been dequeued.
Fixing core scheduling support requires the decision to travel with the
dispatch that made it. Make scx_dispatch_sched() and balance_one() return an
explicit verdict instead and drop the flag's plumbing from the tools autogen
enum headers.

Also factor the pick-side invocation, its follow-up queueing and the
post-dispatch checks out of do_pick_task_scx() into dispatch_pick(). No
functional changes intended.

v2: Drop the SCX_RQ_BAL_KEEP plumbing from the tools autogen enum headers
    as well (Andrea).

Fixes: 4c95380701f5 ("sched/ext: Fold balance_scx() into pick_task_scx()")
Cc: stable@vger.kernel.org # v6.19+
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

tools/compiler: match glibc 2.42 definition of __attribute_const__

2026-09-07T15:36:36+00:00

commit 8700a4761beb219873956666cf91776a2c61e698 upstream.

glibc 2.42 added __attribute_const__ to sys/cdefs.h:

    # define __attribute_const__ __attribute__ ((__const__))

GCC 15 warns when a macro is redefined to a different replacement list
(-Wbuiltin-macro-redefined). Since host tool Makefiles (resolve_btfids,
objtool) pass -Werror, this conflict becomes fatal.

The warning is suppressed on standard native builds because GCC treats
/usr/include as a system header path (-isystem), and macro-redefinition
warnings from system headers are silently suppressed by GCC. It fires
when glibc headers are on a regular include path (-I) instead, which
is the case in cross-compilation setups such as NixOS, where the
sysroot's glibc is passed explicitly via -I rather than -isystem.

Per (C11 6.10.3), identical replacement lists are accepted silently.
Match the glibc definition exactly, including the space before "((", so
the redefinition is accepted without warning regardless of whether
glibc headers are treated as system or non-system includes.

Link: https://lore.kernel.org/20260701200635.3992767-1-rkr0k0r@gmail.com
Signed-off-by: Joy H.J. Lee 
Cc: Nathan Chancellor 
Cc: David Laight 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

objtool/rust: add one more `noreturn` Rust function

2026-09-07T15:36:31+00:00

commit 993f235c4af49d0e912cc28abe6d733531600237 upstream.

When the pointer formatting series [1] is applied and KUnit tests
are enabled, `objtool` would report an error with any of our
supported Rust versions. For instance, with Rust 1.97.1:

    rust/kernel.o: error: objtool: _R..._4core3fmt7Pointer3fmtB7_()
    falls through to next function _R..._4core7convert5AsRefNtB5_4BStrE6as_ref()

Or, with Rust 1.85.0:

    rust/kernel.o: error: objtool: _R..._4core3fmt7Pointer3fmtB7_()
    falls through to next function _R..._4core3ffi5c_str4CStrENtNtBS_3fmt7Display3fmtB7_()

This happens due to calls to the `noreturn` symbol:

    core::str::slice_error_fail

Thus add the mangled one to the list so that `objtool` knows it is
actually `noreturn`.

See commit 56d680dd23c3 ("objtool/rust: list `noreturn` Rust functions")
for more details.

[ While the series [1] mentioned above was not applied in a way
  that triggered this, Gary found another case [2]:

    I am seeing this function causing issue on my 1.85.1 -Os build, although the
    error message is different this time:

        rust/kernel.o: warning: objtool: _R..._5range9RangeFromjEE5indexCsldbe0TGTmNx_6kernel+0x1d:
        stack state mismatch: cfa1=4+8 cfa2=4+16

    Disassembly shows that the function call before the warning location
    is a call to _4core3str16slice_error_fail, and objtool thought it can
    return (which will end up with a unbalanced stack if it does return).

  Thus apply it. - Miguel ]

Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
Cc: Josh Poimboeuf 
Cc: Peter Zijlstra 
Reported-by: Alice Ryhl 
Link: https://lore.kernel.org/rust-for-linux/anLxXvCKBcAVf91_@google.com/
Link: https://lore.kernel.org/rust-for-linux/20260706-hashedptr-v13-0-377a07f2f78d@kylinos.cn/ [1]
Link: https://lore.kernel.org/rust-for-linux/DKS7U9UHY6XR.2JC0EBIPCI06Z@garyguo.net/ [2]
Link: https://patch.msgid.link/20260805144524.233362-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

objtool/rust: add one more `noreturn` Rust function for Rust 1.99.0

2026-09-07T15:36:30+00:00

commit 16861ca3508e0deac70d3bcacb6dcf435b49d9ef upstream.

Starting with Rust 1.99.0 (expected 2026-10-01), `objtool` may report:

    rust/kernel.o: warning: objtool: _R..._6kernel3str9parse_intaNtNtB2_7private12FromStrRadix14from_str_radix()
    falls through to next function _R..._6kernel3str9parse_intaNtNtB2_7private12FromStrRadix16from_u64_negated()

due to calls to the `noreturn` symbol:

    core::num::from_ascii_bytes_radix_panic

The function was renamed from `from_ascii_radix_panic` [1], which is
already in the list.

Thus add the new one to the list so that `objtool` knows it is actually
`noreturn`.

See commit 56d680dd23c3 ("objtool/rust: list `noreturn` Rust functions")
for more details.

Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
Cc: Josh Poimboeuf 
Cc: Peter Zijlstra 
Link: https://github.com/rust-lang/rust/pull/159554 [1]
Tested-by: Alice Ryhl 
Link: https://patch.msgid.link/20260728191448.349241-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

selftests/bpf: Fix test_maps sockmap failure

2026-09-02T12:33:17+00:00

[ Upstream commit 27a0f3635d862919dd7e5e93e19f3f5d1b240e57 ]

test_maps fails in the sockmap test because sockmap_verdict_prog.c
drops the packet when the first 8 bytes are not directly accessible:
	  if (data + 8 > data_end)
			  return SK_DROP;

The blamed commit removed bpf_skb_pull_data() from the stream parser
program so that the parser no longer modifies the skb. That was needed,
but it also removed an implicit side effect: bpf_skb_pull_data()
linearized enough of the skb for later direct packet access.

In this test, the send side goes through the sockmap SK_MSG path. The
skb can have skb->len == 20 while its linear area is empty, so the
verdict program sees data == data_end and drops the packet even though
the payload length is sufficient.

Keep the parser read-only, and pull the first 8 bytes in the verdict
program before reading or writing them. Reload data/data_end after
bpf_skb_pull_data() as required.

Fixes: 22a0cc10dacb ("selftests/bpf: don't modify the skb in the strparser parser prog")
Reported-by: Ihor Solodrai 
Closes: https://lore.kernel.org/bpf/e3a91acd-2b4d-4e93-a3bb-a0e9ee5ede0f@linux.dev/
Link: https://lore.kernel.org/bpf/20260701071501.39628-1-jiayuan.chen@linux.dev
Signed-off-by: Jiayuan Chen 
Signed-off-by: Andrii Nakryiko 
Signed-off-by: Ricardo B. Marlière (SUSE) 
Signed-off-by: Sasha Levin

Merge tag 'vfs-7.2-rc8.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs

2026-08-14T14:58:01+00:00

Pull vfs fixes from Christian Brauner:

 - Don't warn when a mount is completed from another user namespace.

   fsopen() records the caller's user namespace in fc->user_ns and
   hands back an ordinary file descriptor. The task that calls
   fsconfig(FSCONFIG_CMD_CREATE) doesn't have to be the one that
   created the context, and mount_capable() lets it through as long
   as the caller has CAP_SYS_ADMIN over fc->user_ns, which anyone in
   an ancestor namespace does. So fc->user_ns != current_user_ns()
   is something an unprivileged user can arrange.

   Both overlayfs and binfmt_misc WARN_ON() that. Overlayfs already
   has the same check as a plain error return in ovl_parse_param().

   Drop the WARN_ON() and just refuse. Add selftests for both cases.

 - Reject pid allocations through dead ancestor pid namespaces.

   Require PIDNS_ADDING in every namespace that will receive the pid
   before publishing any of them. That preserves the invariant that
   free_pid() never decrements pid_allocated in a namespace whose
   child_reaper is no longer live. The existing ENOMEM behavior is
   unchanged.

* tag 'vfs-7.2-rc8.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
  pid: reject allocations through dead ancestor pid namespaces
  selftests/filesystems: test completing a context from another user namespace
  binfmt_misc: don't warn when the mount is completed from another user namespace
  ovl: don't warn when the mount is completed from another user namespace