Re: [LTP] syscalls: add v7.3 syscall numbers

[linuxtestproject.agent@gmail.com]

Hi Andrea,

On Fri, 28 Aug 2026, Andrea Cervesato wrote:
> syscalls: add v7.3 syscall numbers

--- [PATCH 4/15] ---

> fchroot01: test fchroot() with a directory fd

Since 7.2 is the latest stable kernel and this test targets a 7.3 feature,
could the subject start with "[STAGING]" as required for unreleased kernel
features?

--- [PATCH 5/15] ---

> fchroot02: test fchroot() invalid arguments

Since 7.2 is the latest stable kernel and this test targets a 7.3 feature,
could the subject start with "[STAGING]" as required for unreleased kernel
features?

--- [PATCH 6/15] ---

> fchroot03: test fchroot() permission checks

Since 7.2 is the latest stable kernel and this test targets a 7.3 feature,
could the subject start with "[STAGING]" as required for unreleased kernel
features?

--- [PATCH 7/15] ---

> fchroot04: test fchroot() into failfs as root

Since 7.2 is the latest stable kernel and this test targets a 7.3 feature,
could the subject start with "[STAGING]" as required for unreleased kernel
features?

--- [PATCH 8/15] ---

> fchroot05: test failfs root can not be referenced

Since 7.2 is the latest stable kernel and this test targets a 7.3 feature,
could the subject start with "[STAGING]" as required for unreleased kernel
features?

--- [PATCH 9/15] ---

> fchroot06: test path walks under failfs root

Since 7.2 is the latest stable kernel and this test targets a 7.3 feature,
could the subject start with "[STAGING]" as required for unreleased kernel
features?

--- [PATCH 10/15] ---

> fchroot07: test execve blocked by failfs root

Since 7.2 is the latest stable kernel and these tests target a 7.3 feature,
could the subject start with "[STAGING]" as required for unreleased kernel
features?

> +fchroot07 fchroot07
> +fchroot08 fchroot08

The subject and body describe only the fchroot07 exec test. Could fchroot08,
which tests inheritance across fork(), be split into its own patch or
documented in a subject and body that cover both tests?

> The exec runs in a
> grandchild so a wrongly successful exec is still detected through
> the exit code.

Could this explanation be corrected to match the implementation?
fchroot07_child reports TFAIL and returns 0, while SAFE_WAIT(NULL) does not
inspect an exit status. The failure is propagated through the reinitialized
LTP result channel rather than through the exit code.

--- [PATCH 11/15] ---

> fchroot09: test setns escape from failfs root

Since 7.2 is the latest stable kernel and this test targets a 7.3 feature,
could the subject start with "[STAGING]" as required for unreleased kernel
features?

>  * Entering failfs with :manpage:`fchroot(2)` is hard to undo: a process
>  * inside counts as chrooted, so :manpage:`chroot(2)` and fchroot() back
>  * out require ``CAP_SYS_CHROOT``. The remaining way out is a pre-opened mount
>  * namespace file descriptor: setns() into it resets both the root and the

Could the raw fchroot() and setns() references use
:manpage:`fchroot(2)` and :manpage:`setns(2)`? Test documentation requires
the man-page role for raw syscall references.

--- [PATCH 12/15] ---

> fchroot10: test failfs entry without no_new_privs

Since 7.2 is the latest stable kernel and this test targets a 7.3 feature,
could the subject start with "[STAGING]" as required for unreleased kernel
features?

> +	SAFE_SETRESUID(ltpuser->pw_uid, ltpuser->pw_uid,
> +		ltpuser->pw_uid);
> +
> +	TST_EXP_FAIL(tst_syscall(__NR_fchroot, FD_FAILFS_ROOT, 0),
> +		EPERM, "unprivileged fchroot() without no_new_privs");

Could setup first verify that PR_GET_NO_NEW_PRIVS is zero and report TCONF
when it is already set? The bit is inherited and cannot be cleared. If LTP
is launched under a no-new-privileges policy, this child retains the bit,
the kernel permits this fchroot() case, and the test reports a false failure
without exercising the documented precondition.

--- [PATCH 13/15] ---

> fchroot11: test failfs entry with no_new_privs

Since 7.2 is the latest stable kernel and this test targets a 7.3 feature,
could the subject start with "[STAGING]" as required for unreleased kernel
features?

> +	TST_EXP_FAIL(unshare(CLONE_NEWUSER), EPERM,
> +		"user namespace creation blocked by the failfs root");

Could a separate unprivileged child establish that user namespace creation
succeeds before entering failfs? CONFIG_USER_NS=y only proves kernel support.
Runtime policy such as kernel.unprivileged_userns_clone=0, an LSM, or seccomp
can already return EPERM for nobody. In that case this assertion reports
TPASS without exercising the claimed chroot restriction.

--- [PATCH 14/15] ---

> fchroot12: test failfs entry with shared fs_struct

Since 7.2 is the latest stable kernel and this test targets a 7.3 feature,
could the subject start with "[STAGING]" as required for unreleased kernel
features?

--- [PATCH 15/15] ---

> fchroot13: test failfs entry when chrooted

Since 7.2 is the latest stable kernel and this test targets a 7.3 feature,
could the subject start with "[STAGING]" as required for unreleased kernel
features?

>  * of a chrooted task into failfs would allow it to escape its chroot via
>  * ``openat(fd, "..")`` with a pre-opened directory fd, so the kernel refuses

Could the raw openat() reference use :manpage:`openat(2)` and describe the
arguments separately? Test documentation requires the man-page role for raw
syscall references.

Verdict - Needs revision

---
Note:

The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.

Regards,
LTP AI Reviewer

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp