[LTP] [PATCH v2] syscall02: test invalid syscall number -1

Cyril Hrubis chrubis@suse.cz
Tue Jul 14 14:48:52 CEST 2026


Hi!
> diff --git a/runtest/syscalls b/runtest/syscalls
> index a021c79da49d4157c33187caed2dd3f0483759e0..8a777e61da1af59ba694e0bc5b5d92bb1d63754a 100644
> --- a/runtest/syscalls
> +++ b/runtest/syscalls
> @@ -1678,6 +1678,7 @@ sync_file_range01 sync_file_range01
>  sync_file_range02 sync_file_range02
>  
>  syscall01 syscall01
> +syscall02 syscall02
>  
>  sysconf01 sysconf01
>  
> diff --git a/testcases/kernel/syscalls/syscall/.gitignore b/testcases/kernel/syscalls/syscall/.gitignore
> index 74a081e40cb564e874e0f81478d3d1a0e95b6df4..fed1d81079450a7442023447285cd112924f7a10 100644
> --- a/testcases/kernel/syscalls/syscall/.gitignore
> +++ b/testcases/kernel/syscalls/syscall/.gitignore
> @@ -1 +1,2 @@
>  /syscall01
> +/syscall02
> diff --git a/testcases/kernel/syscalls/syscall/syscall02.c b/testcases/kernel/syscalls/syscall/syscall02.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..2fefcb17c763813653a6644759c2a035bee2c604
> --- /dev/null
> +++ b/testcases/kernel/syscalls/syscall/syscall02.c
> @@ -0,0 +1,31 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2026 SUSE LLC Andrea Cervesato <andrea.cervesato@suse.com>
> + */
> +
> +/*\
> + * Verify that a raw :manpage:`syscall(2)` with the invalid system call
> + * number -1 fails with ENOSYS.
> + *
> + * The behavior of number -1 is architecture specific, so the test only runs on
> + * the architectures where it has been verified against the kernel entry code.
> + */
> +
> +#define _GNU_SOURCE
> +#include <unistd.h>
> +
> +#include "tst_test.h"
> +
> +static void run(void)
> +{
> +	TST_EXP_FAIL2(syscall(-1), ENOSYS, "invalid syscall number -1");
> +}
> +
> +static struct tst_test test = {
> +	.test_all = run,
> +	.supported_archs = (const char *const []) {
> +		"x86_64",
> +		"aarch64",
> +		NULL
> +	},
> +};

I do not think that there is an architecture that has a valid syscall
mapped to -1. I do not think that we need to restrict the architecture
here.

-- 
Cyril Hrubis
chrubis@suse.cz


More information about the ltp mailing list