[LTP] [PATCH] lack of ENAMETOOLONG testcases for pathnames longer than PATH_MAX

[Andrea Cervesato]

Hi!

On Tue Jan 13, 2026 at 8:49 PM CET, Al Viro wrote:
> 	There are different causes of ENAMETOOLONG.  It might come from
> filesystem rejecting an excessively long pathname component, but there's
> also "pathname is longer than PATH_MAX bytes, including terminating NUL"
> and that doesn't get checked anywhere.
>
> 	Ran into that when a braino in kernel patch broke that logics
> (ending up with cutoff too low) and that didn't get caught by LTP run.
>
> 	Patch below adds the checks to one of the tests that do deal
> with the other source of ENAMETOOLONG; it almost certainly not the
> right use of infrastructure, though.

The description is not well formatted, spaces at the beginning of the
phrases should be removed.

Also, we can make it slightly more clear, by saying that error can be
caused by a path name that is bigger than NAME_MAX, if relative, or
bigger than PATH_MAX, if absolute (when we use '/').

In this test we only verifies if relative paths are longer than
NAME_MAX (we give 273 bytes instead of 255 max), but we don't test if
path name is bigger than PATH_MAX.

We should correctly distinguish these two cases inside the test with
proper names as well. Check below..

>
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> ---
> diff --git a/testcases/kernel/syscalls/chdir/chdir04.c b/testcases/kernel/syscalls/chdir/chdir04.c
> index 6e53b7fef..e8dd5121d 100644
> --- a/testcases/kernel/syscalls/chdir/chdir04.c
> +++ b/testcases/kernel/syscalls/chdir/chdir04.c
> @@ -11,6 +11,8 @@
>  #include "tst_test.h"
>  
>  static char long_dir[] = "abcdefghijklmnopqrstmnopqrstuvwxyzabcdefghijklmnopqrstmnopqrstuvwxyzabcdefghijklmnopqrstmnopqrstuvwxyzabcdefghijklmnopqrstmnopqrstuvwxyzabcdefghijklmnopqrstmnopqrstuvwxyzabcdefghijklmnopqrstmnopqrstuvwxyzabcdefghijklmnopqrstmnopqrstuvwxyzabcdefghijklmnopqrstmnopqrstuvwxyz";
> +static char long_path[PATH_MAX+1];
> +static char shorter_path[PATH_MAX];
>  static char noexist_dir[] = "noexistdir";

When it comes to syscall testing, it's better to use guarded buffers.
This is easy to do: please check tst_test.bufs usage in here:

https://linux-test-project.readthedocs.io/en/latest/developers/api_c_tests.html#guarded-buffers-introduction

Many old tests are not using these buffers, but it's better to
introduce them when a test is refactored or fixed, like in this case.

You need to define:

static char *long_rel_path;
static char *long_abs_path;

...

static void setup(void) {
	..
	// initialize long_rel_path content
	// initialize long_abs_path content
}

static struct tst_test test = {
	..
	.bufs = (struct tst_buffer []) {
		{&long_rel_path, .size = NAME_MAX + 10},
		{&long_abs_path, .size = PATH_MAX + 10},
		{}
	}
};

>  
>  static struct tcase {
> @@ -20,16 +22,23 @@ static struct tcase {
>  	{long_dir, ENAMETOOLONG},
>  	{noexist_dir, ENOENT},
>  	{0, EFAULT}, // bad_addr
> +	{long_path, ENAMETOOLONG},
> +	{shorter_path, 0},
>  };
>  
>  static void verify_chdir(unsigned int i)
>  {
> -	TST_EXP_FAIL(chdir(tcases[i].dir), tcases[i].exp_errno, "chdir()");
> +	if (tcases[i].exp_errno)
> +		TST_EXP_FAIL(chdir(tcases[i].dir), tcases[i].exp_errno, "chdir()");
> +	else
> +		TST_EXP_PASS(chdir(tcases[i].dir), "chdir()");

In this test we only verify errors, so TST_EXP_PASS is not needed.

-- 
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com