[LTP] [PATCH] pathconf01: Allow EINVAL where POSIX leaves support unspecified

[LTP] [PATCH] pathconf01: Allow EINVAL where POSIX leaves support unspecified

[Wake Liu via ltp]

POSIX lists two EINVAL cases for pathconf(). It shall fail with EINVAL
when the value of name is not valid. It may also fail with EINVAL when
"the implementation does not support an association of the variable
name with the specified file".

The test always calls pathconf() on a directory. For a directory, POSIX
leaves it unspecified whether _PC_MAX_CANON, _PC_MAX_INPUT and
_PC_VDISABLE (note 2), _PC_ASYNC_IO, _PC_PRIO_IO and _PC_SYNC_IO
(note 8) and the _PC_REC_* names (note 10) are supported, so EINVAL is
allowed for them.

Bionic before Android 15 returns -1 and sets errno to EINVAL for
_PC_REC_INCR_XFER_SIZE and _PC_REC_MAX_XFER_SIZE, which makes the test
fail.

Report EINVAL as TCONF for these names. EINVAL for the other names is
still a failure.

Also print the name and errno on failure, so it is clear which name
failed.

Signed-off-by: Wake Liu <wakel@google.com>
---
 .../kernel/syscalls/pathconf/pathconf01.c     | 36 ++++++++++++-------
 1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/testcases/kernel/syscalls/pathconf/pathconf01.c b/testcases/kernel/syscalls/pathconf/pathconf01.c
index 5af45e417..635c356bc 100644
--- a/testcases/kernel/syscalls/pathconf/pathconf01.c
+++ b/testcases/kernel/syscalls/pathconf/pathconf01.c
@@ -19,24 +19,26 @@ static char *path;
 static struct tcase {
 	int value;
 	char *name;
+	/* POSIX leaves support for a directory unspecified */
+	int einval_ok;
 } tcases[] = {
 	{NAME_DESC(_PC_LINK_MAX)},
-	{NAME_DESC(_PC_MAX_CANON)},
-	{NAME_DESC(_PC_MAX_INPUT)},
+	{NAME_DESC(_PC_MAX_CANON), .einval_ok = 1},
+	{NAME_DESC(_PC_MAX_INPUT), .einval_ok = 1},
 	{NAME_DESC(_PC_NAME_MAX)},
 	{NAME_DESC(_PC_PATH_MAX)},
 	{NAME_DESC(_PC_PIPE_BUF)},
 	{NAME_DESC(_PC_CHOWN_RESTRICTED)},
 	{NAME_DESC(_PC_NO_TRUNC)},
-	{NAME_DESC(_PC_VDISABLE)},
-	{NAME_DESC(_PC_SYNC_IO)},
-	{NAME_DESC(_PC_ASYNC_IO)},
-	{NAME_DESC(_PC_PRIO_IO)},
+	{NAME_DESC(_PC_VDISABLE), .einval_ok = 1},
+	{NAME_DESC(_PC_SYNC_IO), .einval_ok = 1},
+	{NAME_DESC(_PC_ASYNC_IO), .einval_ok = 1},
+	{NAME_DESC(_PC_PRIO_IO), .einval_ok = 1},
 	{NAME_DESC(_PC_FILESIZEBITS)},
-	{NAME_DESC(_PC_REC_INCR_XFER_SIZE)},
-	{NAME_DESC(_PC_REC_MAX_XFER_SIZE)},
-	{NAME_DESC(_PC_REC_MIN_XFER_SIZE)},
-	{NAME_DESC(_PC_REC_XFER_ALIGN)},
+	{NAME_DESC(_PC_REC_INCR_XFER_SIZE), .einval_ok = 1},
+	{NAME_DESC(_PC_REC_MAX_XFER_SIZE), .einval_ok = 1},
+	{NAME_DESC(_PC_REC_MIN_XFER_SIZE), .einval_ok = 1},
+	{NAME_DESC(_PC_REC_XFER_ALIGN), .einval_ok = 1},
 };
 
 static void verify_pathconf(unsigned int i)
@@ -47,10 +49,18 @@ static void verify_pathconf(unsigned int i)
 
 	TEST(pathconf(path, tc->value));
 
-	if (TST_RET == -1 && errno != 0)
-		tst_res(TFAIL, "pathconf Failed, errno = %d", TST_ERR);
-	else
+	if (TST_RET != -1 || !TST_ERR) {
 		tst_res(TPASS, "pathconf(%s, %s)", path, tc->name);
+		return;
+	}
+
+	if (tc->einval_ok && TST_ERR == EINVAL) {
+		tst_res(TCONF, "pathconf(%s, %s) not supported for a directory",
+			path, tc->name);
+		return;
+	}
+
+	tst_res(TFAIL | TTERRNO, "pathconf(%s, %s)", path, tc->name);
 }
 
 static struct tst_test test = {
-- 
2.56.0.rc1.315.gc6ed9934b7-goog


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] pathconf01: Allow EINVAL where POSIX leaves support unspecified

[linuxtestproject.agent]

Hi Wake,

On Mon, 5 Oct 2026 06:19:33 +0000, Wake Liu via ltp wrote:
> [PATCH] pathconf01: Allow EINVAL where POSIX leaves support unspecified

Verdict - Reviewed

---
Note:

The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.

Regards,
LTP AI Reviewer

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] pathconf01: Allow EINVAL where POSIX leaves support unspecified

[Andrea Cervesato via ltp]

Hi Wake,

> POSIX lists two EINVAL cases for pathconf(). It shall fail with EINVAL
> when the value of name is not valid. It may also fail with EINVAL when
> "the implementation does not support an association of the variable
> name with the specified file".
> 
> The test always calls pathconf() on a directory. For a directory, POSIX
> leaves it unspecified whether _PC_MAX_CANON, _PC_MAX_INPUT and
> _PC_VDISABLE (note 2), _PC_ASYNC_IO, _PC_PRIO_IO and _PC_SYNC_IO
> (note 8) and the _PC_REC_* names (note 10) are supported, so EINVAL is
> allowed for them.
> 
> Bionic before Android 15 returns -1 and sets errno to EINVAL for
> _PC_REC_INCR_XFER_SIZE and _PC_REC_MAX_XFER_SIZE, which makes the test
> fail.
> 
> Report EINVAL as TCONF for these names. EINVAL for the other names is
> still a failure.
> 
> Also print the name and errno on failure, so it is clear which name
> failed.
> 
> Signed-off-by: Wake Liu <wakel@google.com>
> ---
>  .../kernel/syscalls/pathconf/pathconf01.c     | 36 ++++++++++++-------
>  1 file changed, 23 insertions(+), 13 deletions(-)
> 
> diff --git a/testcases/kernel/syscalls/pathconf/pathconf01.c b/testcases/kernel/syscalls/pathconf/pathconf01.c
> index 5af45e417..635c356bc 100644
> --- a/testcases/kernel/syscalls/pathconf/pathconf01.c
> +++ b/testcases/kernel/syscalls/pathconf/pathconf01.c
> @@ -19,24 +19,26 @@ static char *path;
>  static struct tcase {
>  	int value;
>  	char *name;
> +	/* POSIX leaves support for a directory unspecified */
> +	int einval_ok;

Usually, in these cases, it's better to define an array of errno we might
have when we trigger the syscall in a certain way. And then we use
TST_EXP_ARR_FAIL() on it.

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

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] pathconf01: Allow EINVAL where POSIX leaves support unspecified

[Wake Liu via ltp]

Hi Andrea,

> > + /* POSIX leaves support for a directory unspecified */
> > + int einval_ok;
>
> Usually, in these cases, it's better to define an array of errno we might
> have when we trigger the syscall in a certain way. And then we use
> TST_EXP_ARR_FAIL() on it.

Thanks for the review!

pathconf01 is a positive test, and the einval_ok names actually succeed
on glibc, musl and Bionic since Android 15: they return >= 0, or -1
without changing errno.

TST_EXP_FAIL_ARR() and TST_EXP_FAIL2_ARR() expect the call to fail, so
they report TFAIL wherever these names are supported for directories.
I tried TST_EXP_FAIL2_ARR() and all 10 einval_ok names fail on glibc
("succeeded" or "expected EINVAL: SUCCESS (0)").

Here we still expect pathconf() to succeed, and only want to treat
EINVAL as TCONF for the names where POSIX leaves directory support
unspecified (POSIX only defines EINVAL for this case).

Does keeping the einval_ok check make sense to you, or would you still
prefer storing an exp_errs array in struct tcase and checking it with
tst_errno_in_set(), the helper behind TST_EXP_FAIL_ARR()?

Best regards,
Wake


On Tue, Oct 13, 2026 at 12:20 AM Andrea Cervesato
<andrea.cervesato@suse.com> wrote:
>
> Hi Wake,
>
> > POSIX lists two EINVAL cases for pathconf(). It shall fail with EINVAL
> > when the value of name is not valid. It may also fail with EINVAL when
> > "the implementation does not support an association of the variable
> > name with the specified file".
> >
> > The test always calls pathconf() on a directory. For a directory, POSIX
> > leaves it unspecified whether _PC_MAX_CANON, _PC_MAX_INPUT and
> > _PC_VDISABLE (note 2), _PC_ASYNC_IO, _PC_PRIO_IO and _PC_SYNC_IO
> > (note 8) and the _PC_REC_* names (note 10) are supported, so EINVAL is
> > allowed for them.
> >
> > Bionic before Android 15 returns -1 and sets errno to EINVAL for
> > _PC_REC_INCR_XFER_SIZE and _PC_REC_MAX_XFER_SIZE, which makes the test
> > fail.
> >
> > Report EINVAL as TCONF for these names. EINVAL for the other names is
> > still a failure.
> >
> > Also print the name and errno on failure, so it is clear which name
> > failed.
> >
> > Signed-off-by: Wake Liu <wakel@google.com>
> > ---
> >  .../kernel/syscalls/pathconf/pathconf01.c     | 36 ++++++++++++-------
> >  1 file changed, 23 insertions(+), 13 deletions(-)
> >
> > diff --git a/testcases/kernel/syscalls/pathconf/pathconf01.c b/testcases/kernel/syscalls/pathconf/pathconf01.c
> > index 5af45e417..635c356bc 100644
> > --- a/testcases/kernel/syscalls/pathconf/pathconf01.c
> > +++ b/testcases/kernel/syscalls/pathconf/pathconf01.c
> > @@ -19,24 +19,26 @@ static char *path;
> >  static struct tcase {
> >       int value;
> >       char *name;
> > +     /* POSIX leaves support for a directory unspecified */
> > +     int einval_ok;
>
> Usually, in these cases, it's better to define an array of errno we might
> have when we trigger the syscall in a certain way. And then we use
> TST_EXP_ARR_FAIL() on it.
>
> --
> Andrea Cervesato
> SUSE QE Automation Engineer Linux
> andrea.cervesato@suse.com



-- 
Best Regards,
Wake Liu

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] pathconf01: Allow EINVAL where POSIX leaves support unspecified

[Andrea Cervesato via ltp]

Hi Wake,

> pathconf01 is a positive test, and the einval_ok names actually succeed
> on glibc, musl and Bionic since Android 15: they return >= 0, or -1
> without changing errno.
> 
> TST_EXP_FAIL_ARR() and TST_EXP_FAIL2_ARR() expect the call to fail, so
> they report TFAIL wherever these names are supported for directories.
> I tried TST_EXP_FAIL2_ARR() and all 10 einval_ok names fail on glibc
> ("succeeded" or "expected EINVAL: SUCCESS (0)").
> 
> Here we still expect pathconf() to succeed, and only want to treat
> EINVAL as TCONF for the names where POSIX leaves directory support
> unspecified (POSIX only defines EINVAL for this case).
> 
> Does keeping the einval_ok check make sense to you, or would you still
> prefer storing an exp_errs array in struct tcase and checking it with
> tst_errno_in_set(), the helper behind TST_EXP_FAIL_ARR()?

Indeed, my review was biased by unrelated usage of TST_EXP_FAIL_ARR().
The patch is correct as is and we don't have any macro hich could substitute
the manual check we are applying in this patch.

Thanks for pointing it out.

Reviewed-by: Andrea Cervesato <andrea.cervesato@suse.com>

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

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] pathconf01: Allow EINVAL where POSIX leaves support unspecified

[Andrea Cervesato via ltp]

Merged, Thanks!

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

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp