[LTP] [PATCH v1] getcwd01: Only check buffer NULL on glibc

[Richard Palethorpe]

Hello,

Wei Gao via ltp <ltp@lists.linux.it> writes:

> Signed-off-by: Wei Gao <wegao@suse.com>
> ---

Need to mention the github issue in the commit
https://github.com/linux-test-project/ltp/issues/1084

>  testcases/kernel/syscalls/getcwd/getcwd01.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/testcases/kernel/syscalls/getcwd/getcwd01.c b/testcases/kernel/syscalls/getcwd/getcwd01.c
> index 65d827873..6769eb6f4 100644
> --- a/testcases/kernel/syscalls/getcwd/getcwd01.c
> +++ b/testcases/kernel/syscalls/getcwd/getcwd01.c
> @@ -34,10 +34,13 @@ static struct t_case {
>  	int exp_err;
>  } tcases[] = {
>  	{(void *)-1, PATH_MAX, EFAULT},
> -	{NULL, (size_t)-1, ENOMEM},
>  	{buffer, 0, EINVAL},
>  	{buffer, 1, ERANGE},
> +/* musl and uclibc-ng will allocate memory before syscall if buf == NULL */
> +#ifdef __GLIBC__
> +	{NULL, (size_t)-1, ENOMEM},

I'd prefer a more general solution. There are a lot of failures like
this. I've seen a lot in the past in glibc where it changed its
behaviour.

Most of these failures follow the same pattern:
pass an invalid argument -> expect a particular kernel error code.

Two things go wrong:
1. libc does something with the invalid value
   a. performs some extended behaviour (like above)
   b. segfaults
2. kernel returns an unexpected error code because the value or context
   are invalid in multiple ways.

For 1. we can usually call the system call directly. This solution has
       been used before. It works for most syscalls except ones like clone.

For 2. Beyond reporting these errors I'm just going to ignore tests like this.

>  	{NULL, 1, ERANGE}
> +#endif
>  };
>  
>  static void verify_getcwd(unsigned int n)
> -- 
> 2.35.3


-- 
Thank you,
Richard.