Re: [PATCH] syscall_user_dispatch: Introduce ARCH_SUPPORTS_SYSCALL_USER_DISPATCH

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Critical] The Kconfig symbol `ARCH_SUPPORTS_SYSCALL_USER_DISPATCH` is referenced in `depends on` and `select` but is never defined anywhere, silently disabling Syscall User Dispatch globally.

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but pre-exists in the state restoration logic: tasks that configure Syscall User Dispatch with `PR_SYS_DISPATCH_INCLUSIVE_ON` cannot have their configuration restored via ptrace, breaking Checkpoint/Restore (CRIU).
--

--- Patch [1]: [PATCH] syscall_user_dispatch: Introduce ARCH_SUPPORTS_SYSCALL_USER_DISPATCH ---
commit 46bd6e141d4dc4cf13cdaf9787b9a2959d21a56a
Author: Jinjie Ruan <ruanjinjie@huawei.com>

syscall_user_dispatch: Introduce ARCH_SUPPORTS_SYSCALL_USER_DISPATCH

This commit introduces ARCH_SUPPORTS_SYSCALL_USER_DISPATCH to decouple
Syscall User Dispatch from GENERIC_ENTRY. It selects the new config
exclusively on x86 and removes redundant stub functions from other
architectures.

Link: https://lore.kernel.org/linux-arm-kernel/akZgV0Y4YAmB43_g@J2N7QTR9R3.cambridge.arm.com/

> diff --git a/arch/Kconfig b/arch/Kconfig
> index 0c01521c2f3f2..393d0fb75eac4 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -116,6 +116,7 @@ config GENERIC_ENTRY
>  
>  config SYSCALL_USER_DISPATCH
>  	bool "Syscall User Dispatch"
> +	depends on ARCH_SUPPORTS_SYSCALL_USER_DISPATCH

[Severity: Critical]
Does this regression disable Syscall User Dispatch globally? It appears
ARCH_SUPPORTS_SYSCALL_USER_DISPATCH is referenced here but never defined in
any Kconfig file. Since the symbol is undefined, Kconfig evaluates it to
false, which prevents CONFIG_SYSCALL_USER_DISPATCH from being enabled and
could break the userspace ABI where prctl(PR_SET_SYSCALL_USER_DISPATCH)
returns -EINVAL.

>  	depends on GENERIC_ENTRY
>  	default y
>  	help

[ ... ]

> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index b5571667a89b2..2bff333d29e84 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -336,6 +336,7 @@ config X86
>  	select SCHED_SMT			if SMP
>  	select ARCH_SUPPORTS_SCHED_CLUSTER	if SMP
>  	select ARCH_SUPPORTS_SCHED_MC		if SMP
> +	select ARCH_SUPPORTS_SYSCALL_USER_DISPATCH

[Severity: Critical]
Could this select statement be ineffective? Since
ARCH_SUPPORTS_SYSCALL_USER_DISPATCH is not defined anywhere, selecting it
here has no effect.

>  	select HAVE_SINGLE_FTRACE_DIRECT_OPS	if X86_64 && DYNAMIC_FTRACE_WITH_DIRECT_CALLS
>  
>  config INSTRUCTION_DECODER

[ ... ]

[Severity: High]
This is a pre-existing issue, but does the state restoration logic break for
tasks configuring Syscall User Dispatch with PR_SYS_DISPATCH_INCLUSIVE_ON?

When a task configures PR_SYS_DISPATCH_INCLUSIVE_ON,
task_set_syscall_user_dispatch() inverts offset and len:

kernel/entry/syscall_user_dispatch.c:task_set_syscall_user_dispatch() {
    ...
	case PR_SYS_DISPATCH_INCLUSIVE_ON:
		/* ... */
		offset += len;
		len = -len;
    ...
}

However, syscall_user_dispatch_get_config() reads these inverted values but
sets the mode to PR_SYS_DISPATCH_ON (which is EXCLUSIVE_ON), losing the
INCLUSIVE_ON distinction:

kernel/entry/syscall_user_dispatch.c:syscall_user_dispatch_get_config() {
    ...
	if (test_task_syscall_work(task, SYSCALL_USER_DISPATCH))
		cfg.mode = PR_SYS_DISPATCH_ON;
	else
		cfg.mode = PR_SYS_DISPATCH_OFF;

	cfg.offset = sd->offset;
	cfg.len = sd->len;
    ...
}

During restoration, task_set_syscall_user_dispatch() evaluates this state
under the EXCLUSIVE_ON branch, where the overflow check rejects the inverted
wrap-around parameters:

kernel/entry/syscall_user_dispatch.c:task_set_syscall_user_dispatch() {
    ...
	case PR_SYS_DISPATCH_EXCLUSIVE_ON:
		/* ... */
		if (offset && offset + len <= offset)
			return -EINVAL;
    ...
}

Could this cause ptrace(PTRACE_SET_SYSCALL_USER_DISPATCH_CONFIG) to
unconditionally fail with -EINVAL for inclusive mode configurations,
breaking Checkpoint/Restore?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709072803.3843948-1-ruanjinjie@huawei.com?part=1