On Wed, Jan 21, 2015 at 7:41 AM, Michael Ellerman <m...@ellerman.id.au> wrote:
> On systems which don't implement sys_execveat(), this test produces a
> lot of output.
>
> Add a check at the beginning to see if the syscall is present, and if
> not just note one error and return.
Good point, thanks.
> Signed-off-by: Michael Ellerman <m...@ellerman.id.au>
> ---
> tools/testing/selftests/exec/execveat.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/tools/testing/selftests/exec/execveat.c
> b/tools/testing/selftests/exec/execveat.c
> index e238c9559caf..b87e4a843bea 100644
> --- a/tools/testing/selftests/exec/execveat.c
> +++ b/tools/testing/selftests/exec/execveat.c
> @@ -234,6 +234,14 @@ static int run_tests(void)
> int fd_cloexec = open_or_die("execveat", O_RDONLY|O_CLOEXEC);
> int fd_script_cloexec = open_or_die("script", O_RDONLY|O_CLOEXEC);
>
> + /* Check if we have execveat at all, and bail early if not */
> + errno = 0;
> + execveat_(-1, NULL, NULL, NULL, 0);
> + if (errno == -ENOSYS) {
Could we change this to ENOSYS (no minus) and also change
the execveat_() function similarly, so that a binary built where
__NR_execveat is available but running where it isn't also exits
early? (My bad for having the minus sign in execveat_() in the
first place -- fingers too used to kernel mode.)
Thanks!
> + printf("[FAIL] ENOSYS calling execveat - no kernel
> support?\n");
> + return 1;
> + }
> +
> /* Change file position to confirm it doesn't affect anything */
> lseek(fd, 10, SEEK_SET);
>
> --
> 2.1.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
