6.18.0-rc1: LTP syscalls ioctl_pidfd05: TFAIL: ioctl(pidfd, PIDFD_GET_INFO_SHORT, info_invalid) expected EINVAL: ENOTTY (25)

6.18.0-rc1: LTP syscalls ioctl_pidfd05: TFAIL: ioctl(pidfd, PIDFD_GET_INFO_SHORT, info_invalid) expected EINVAL: ENOTTY (25)

[Naresh Kamboju]

The LTP syscalls ioctl_pidfd05 test failed due to following error on
the Linux mainline
kernel v6.18-rc1-104-g7ea30958b305 on the arm64, arm and x86_64.

The Test case is expecting to fail with EINVAL but found ENOTTY.

Please investigate this reported regression.

First seen on v6.18-rc1-104-g7ea30958b305
Good: 6.18.0-rc1
Bad: 7ea30958b3054f5e488fa0b33c352723f7ab3a2a

Regression Analysis:
- New regression? yes
- Reproducibility? yes

Test regressions: 6.18.0-rc1: LTP syscalls ioctl_pidfd05: TFAIL:
ioctl(pidfd, PIDFD_GET_INFO_SHORT, info_invalid) expected EINVAL:
ENOTTY (25)

Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>

## Test error log
tst_buffers.c:57: TINFO: Test is using guarded buffers
tst_test.c:2021: TINFO: LTP version: 20250930
tst_test.c:2024: TINFO: Tested kernel: 6.18.0-rc1 #1 SMP PREEMPT
@1760657272 aarch64
tst_kconfig.c:88: TINFO: Parsing kernel config '/proc/config.gz'
tst_kconfig.c:676: TINFO: CONFIG_TRACE_IRQFLAGS kernel option detected
which might slow the execution
tst_test.c:1842: TINFO: Overall timeout per run is 0h 21m 36s
ioctl_pidfd05.c:45: TPASS: ioctl(pidfd, PIDFD_GET_INFO, NULL) : EINVAL (22)
ioctl_pidfd05.c:46: TFAIL: ioctl(pidfd, PIDFD_GET_INFO_SHORT,
info_invalid) expected EINVAL: ENOTTY (25)
Summary:
passed   1
failed   1

## Source
* Kernel version: 6.18.0-rc1
* Git tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
* Git describe: v6.18-rc1-104-g98ac9cc4b445
* Git commit: 98ac9cc4b4452ed7e714eddc8c90ac4ae5da1a09
* Architectures: arm64, x86_64
* Toolchains: gcc-13 clang
* Kconfigs: defconfig+lkftconfig

## Build
* Test log: https://lkft.validation.linaro.org/scheduler/job/8495154#L15590
* Test details:
https://regressions.linaro.org/lkft/linux-mainline-master/v6.18-rc1-104-g98ac9cc4b445/ltp-syscalls/ioctl_pidfd05/
* Build plan: https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/tests/34AVGrBMrEy9qh7gqsguINdUFFt
* Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/34AVFcbKDpJQfCdAQupg3lZzwFY/
* Kernel config:
https://storage.tuxsuite.com/public/linaro/lkft/builds/34AVFcbKDpJQfCdAQupg3lZzwFY/config

--
Linaro LKFT

Re: 6.18.0-rc1: LTP syscalls ioctl_pidfd05: TFAIL: ioctl(pidfd, PIDFD_GET_INFO_SHORT, info_invalid) expected EINVAL: ENOTTY (25)

[Naresh Kamboju]

+ LTP mailing list,

On Fri, 17 Oct 2025 at 14:21, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
>
> The LTP syscalls ioctl_pidfd05 test failed due to following error on
> the Linux mainline
> kernel v6.18-rc1-104-g7ea30958b305 on the arm64, arm and x86_64.
>
> The Test case is expecting to fail with EINVAL but found ENOTTY.

[Not a kernel regression]

From the recent LTP upgrade we have newly added test cases,
ioctl_pidfd()

The test case is meant to test,

Add ioctl_pidfd05 test
Verify that ioctl() raises an EINVAL error when PIDFD_GET_INFO
 is used.
 This happens when:
   - info parameter is NULL
   - info parameter is providing the wrong size

However, we need to investigate the reason for failure.

Test case: https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/ioctl/ioctl_pidfd05.c

>
> Please investigate this reported regression.
>
> First seen on v6.18-rc1-104-g7ea30958b305
> Good: 6.18.0-rc1
> Bad: 7ea30958b3054f5e488fa0b33c352723f7ab3a2a
>
> Regression Analysis:
> - New regression? yes
> - Reproducibility? yes
>
> Test regressions: 6.18.0-rc1: LTP syscalls ioctl_pidfd05: TFAIL:
> ioctl(pidfd, PIDFD_GET_INFO_SHORT, info_invalid) expected EINVAL:
> ENOTTY (25)
>
> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
>
> ## Test error log
> tst_buffers.c:57: TINFO: Test is using guarded buffers
> tst_test.c:2021: TINFO: LTP version: 20250930
> tst_test.c:2024: TINFO: Tested kernel: 6.18.0-rc1 #1 SMP PREEMPT
> @1760657272 aarch64
> tst_kconfig.c:88: TINFO: Parsing kernel config '/proc/config.gz'
> tst_kconfig.c:676: TINFO: CONFIG_TRACE_IRQFLAGS kernel option detected
> which might slow the execution
> tst_test.c:1842: TINFO: Overall timeout per run is 0h 21m 36s
> ioctl_pidfd05.c:45: TPASS: ioctl(pidfd, PIDFD_GET_INFO, NULL) : EINVAL (22)
> ioctl_pidfd05.c:46: TFAIL: ioctl(pidfd, PIDFD_GET_INFO_SHORT,
> info_invalid) expected EINVAL: ENOTTY (25)
> Summary:
> passed   1
> failed   1
>
> ## Source
> * Kernel version: 6.18.0-rc1
> * Git tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> * Git describe: v6.18-rc1-104-g98ac9cc4b445
> * Git commit: 98ac9cc4b4452ed7e714eddc8c90ac4ae5da1a09
> * Architectures: arm64, x86_64
> * Toolchains: gcc-13 clang
> * Kconfigs: defconfig+lkftconfig
>
> ## Build
> * Test log: https://lkft.validation.linaro.org/scheduler/job/8495154#L15590
> * Test details:
> https://regressions.linaro.org/lkft/linux-mainline-master/v6.18-rc1-104-g98ac9cc4b445/ltp-syscalls/ioctl_pidfd05/
> * Build plan: https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/tests/34AVGrBMrEy9qh7gqsguINdUFFt
> * Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/34AVFcbKDpJQfCdAQupg3lZzwFY/
> * Kernel config:
> https://storage.tuxsuite.com/public/linaro/lkft/builds/34AVFcbKDpJQfCdAQupg3lZzwFY/config
>
> --
> Linaro LKFT

- Naresh

Re: 6.18.0-rc1: LTP syscalls ioctl_pidfd05: TFAIL: ioctl(pidfd, PIDFD_GET_INFO_SHORT, info_invalid) expected EINVAL: ENOTTY (25)

[Cyril Hrubis]

Hi!
> > The LTP syscalls ioctl_pidfd05 test failed due to following error on
> > the Linux mainline
> > kernel v6.18-rc1-104-g7ea30958b305 on the arm64, arm and x86_64.
> >
> > The Test case is expecting to fail with EINVAL but found ENOTTY.
> 
> [Not a kernel regression]
> 
> From the recent LTP upgrade we have newly added test cases,
> ioctl_pidfd()
> 
> The test case is meant to test,
> 
> Add ioctl_pidfd05 test
> Verify that ioctl() raises an EINVAL error when PIDFD_GET_INFO
>  is used.
>  This happens when:
>    - info parameter is NULL
>    - info parameter is providing the wrong size
> 
> However, we need to investigate the reason for failure.
> 
> Test case: https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/ioctl/ioctl_pidfd05.c

Already fixed in:

commit 00c3e947cece63ce81cdaf12b5a2071984aa7815
Author: Avinesh Kumar <akumar@suse.de>
Date:   Thu Sep 25 10:19:11 2025 +0200

    Introduce ioctl_pidfd_get_info_supported() function

    Check if ioctl(PIDFD_GET_INFO) is implemented or not
    before proceeding in ioctl_pidfd05 test.


-- 
Cyril Hrubis
chrubis@suse.cz

Re: 6.18.0-rc1: LTP syscalls ioctl_pidfd05: TFAIL: ioctl(pidfd, PIDFD_GET_INFO_SHORT, info_invalid) expected EINVAL: ENOTTY (25)

[Cyril Hrubis]

Hi!
> > ## Test error log
> > tst_buffers.c:57: TINFO: Test is using guarded buffers
> > tst_test.c:2021: TINFO: LTP version: 20250930
> > tst_test.c:2024: TINFO: Tested kernel: 6.18.0-rc1 #1 SMP PREEMPT
> > @1760657272 aarch64
> > tst_kconfig.c:88: TINFO: Parsing kernel config '/proc/config.gz'
> > tst_kconfig.c:676: TINFO: CONFIG_TRACE_IRQFLAGS kernel option detected
> > which might slow the execution
> > tst_test.c:1842: TINFO: Overall timeout per run is 0h 21m 36s
> > ioctl_pidfd05.c:45: TPASS: ioctl(pidfd, PIDFD_GET_INFO, NULL) : EINVAL (22)
> > ioctl_pidfd05.c:46: TFAIL: ioctl(pidfd, PIDFD_GET_INFO_SHORT,
> > info_invalid) expected EINVAL: ENOTTY (25)

Looking closely this is a different problem.

What we do in the test is that we pass PIDFD_IOCTL_INFO whith invalid
size with:

struct pidfd_info_invalid {
        uint32_t dummy;
};

#define PIDFD_GET_INFO_SHORT _IOWR(PIDFS_IOCTL_MAGIC, 11, struct pidfd_info_invalid)


And we expect to hit:

        if (usize < PIDFD_INFO_SIZE_VER0)
                return -EINVAL; /* First version, no smaller struct possible */

in fs/pidfs.c


And apparently the return value was changed in:

commit 3c17001b21b9f168c957ced9384abe969019b609
Author: Christian Brauner <brauner@kernel.org>
Date:   Fri Sep 12 13:52:24 2025 +0200

    pidfs: validate extensible ioctls
    
    Validate extensible ioctls stricter than we do now.
    
    Reviewed-by: Aleksa Sarai <cyphar@cyphar.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Christian Brauner <brauner@kernel.org>

diff --git a/fs/pidfs.c b/fs/pidfs.c
index edc35522d75c..0a5083b9cce5 100644
--- a/fs/pidfs.c
+++ b/fs/pidfs.c
@@ -440,7 +440,7 @@ static bool pidfs_ioctl_valid(unsigned int cmd)
                 * erronously mistook the file descriptor for a pidfd.
                 * This is not perfect but will catch most cases.
                 */
-               return (_IOC_TYPE(cmd) == _IOC_TYPE(PIDFD_GET_INFO));
+               return extensible_ioctl_valid(cmd, PIDFD_GET_INFO, PIDFD_INFO_SIZE_VER0);
        }
 
        return false;


So kernel has changed error it returns, if this is a regression or not
is for kernel developers to decide.

-- 
Cyril Hrubis
chrubis@suse.cz

Re: 6.18.0-rc1: LTP syscalls ioctl_pidfd05: TFAIL: ioctl(pidfd, PIDFD_GET_INFO_SHORT, info_invalid) expected EINVAL: ENOTTY (25)

[Jan Kara]

On Fri 17-10-25 11:40:41, Cyril Hrubis wrote:
> Hi!
> > > ## Test error log
> > > tst_buffers.c:57: TINFO: Test is using guarded buffers
> > > tst_test.c:2021: TINFO: LTP version: 20250930
> > > tst_test.c:2024: TINFO: Tested kernel: 6.18.0-rc1 #1 SMP PREEMPT
> > > @1760657272 aarch64
> > > tst_kconfig.c:88: TINFO: Parsing kernel config '/proc/config.gz'
> > > tst_kconfig.c:676: TINFO: CONFIG_TRACE_IRQFLAGS kernel option detected
> > > which might slow the execution
> > > tst_test.c:1842: TINFO: Overall timeout per run is 0h 21m 36s
> > > ioctl_pidfd05.c:45: TPASS: ioctl(pidfd, PIDFD_GET_INFO, NULL) : EINVAL (22)
> > > ioctl_pidfd05.c:46: TFAIL: ioctl(pidfd, PIDFD_GET_INFO_SHORT,
> > > info_invalid) expected EINVAL: ENOTTY (25)
> 
> Looking closely this is a different problem.
> 
> What we do in the test is that we pass PIDFD_IOCTL_INFO whith invalid
> size with:
> 
> struct pidfd_info_invalid {
>         uint32_t dummy;
> };
> 
> #define PIDFD_GET_INFO_SHORT _IOWR(PIDFS_IOCTL_MAGIC, 11, struct pidfd_info_invalid)
> 
> 
> And we expect to hit:
> 
>         if (usize < PIDFD_INFO_SIZE_VER0)
>                 return -EINVAL; /* First version, no smaller struct possible */
> 
> in fs/pidfs.c
> 
> 
> And apparently the return value was changed in:
> 
> commit 3c17001b21b9f168c957ced9384abe969019b609
> Author: Christian Brauner <brauner@kernel.org>
> Date:   Fri Sep 12 13:52:24 2025 +0200
> 
>     pidfs: validate extensible ioctls
>     
>     Validate extensible ioctls stricter than we do now.
>     
>     Reviewed-by: Aleksa Sarai <cyphar@cyphar.com>
>     Reviewed-by: Jan Kara <jack@suse.cz>
>     Signed-off-by: Christian Brauner <brauner@kernel.org>
> 
> diff --git a/fs/pidfs.c b/fs/pidfs.c
> index edc35522d75c..0a5083b9cce5 100644
> --- a/fs/pidfs.c
> +++ b/fs/pidfs.c
> @@ -440,7 +440,7 @@ static bool pidfs_ioctl_valid(unsigned int cmd)
>                  * erronously mistook the file descriptor for a pidfd.
>                  * This is not perfect but will catch most cases.
>                  */
> -               return (_IOC_TYPE(cmd) == _IOC_TYPE(PIDFD_GET_INFO));
> +               return extensible_ioctl_valid(cmd, PIDFD_GET_INFO, PIDFD_INFO_SIZE_VER0);
>         }
>  
>         return false;
> 
> 
> So kernel has changed error it returns, if this is a regression or not
> is for kernel developers to decide.

Yes, it's mostly a question to Christian whether if passed size for
extensible ioctl is smaller than minimal, we should be returning
ENOIOCTLCMD or EINVAL. I think EINVAL would make more sense but Christian
is our "extensible ioctl expert" :).

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: 6.18.0-rc1: LTP syscalls ioctl_pidfd05: TFAIL: ioctl(pidfd, PIDFD_GET_INFO_SHORT, info_invalid) expected EINVAL: ENOTTY (25)

[Christian Brauner]

On Fri, Oct 17, 2025 at 02:43:14PM +0200, Jan Kara wrote:
> On Fri 17-10-25 11:40:41, Cyril Hrubis wrote:
> > Hi!
> > > > ## Test error log
> > > > tst_buffers.c:57: TINFO: Test is using guarded buffers
> > > > tst_test.c:2021: TINFO: LTP version: 20250930
> > > > tst_test.c:2024: TINFO: Tested kernel: 6.18.0-rc1 #1 SMP PREEMPT
> > > > @1760657272 aarch64
> > > > tst_kconfig.c:88: TINFO: Parsing kernel config '/proc/config.gz'
> > > > tst_kconfig.c:676: TINFO: CONFIG_TRACE_IRQFLAGS kernel option detected
> > > > which might slow the execution
> > > > tst_test.c:1842: TINFO: Overall timeout per run is 0h 21m 36s
> > > > ioctl_pidfd05.c:45: TPASS: ioctl(pidfd, PIDFD_GET_INFO, NULL) : EINVAL (22)
> > > > ioctl_pidfd05.c:46: TFAIL: ioctl(pidfd, PIDFD_GET_INFO_SHORT,
> > > > info_invalid) expected EINVAL: ENOTTY (25)
> > 
> > Looking closely this is a different problem.
> > 
> > What we do in the test is that we pass PIDFD_IOCTL_INFO whith invalid
> > size with:
> > 
> > struct pidfd_info_invalid {
> >         uint32_t dummy;
> > };
> > 
> > #define PIDFD_GET_INFO_SHORT _IOWR(PIDFS_IOCTL_MAGIC, 11, struct pidfd_info_invalid)
> > 
> > 
> > And we expect to hit:
> > 
> >         if (usize < PIDFD_INFO_SIZE_VER0)
> >                 return -EINVAL; /* First version, no smaller struct possible */
> > 
> > in fs/pidfs.c
> > 
> > 
> > And apparently the return value was changed in:
> > 
> > commit 3c17001b21b9f168c957ced9384abe969019b609
> > Author: Christian Brauner <brauner@kernel.org>
> > Date:   Fri Sep 12 13:52:24 2025 +0200
> > 
> >     pidfs: validate extensible ioctls
> >     
> >     Validate extensible ioctls stricter than we do now.
> >     
> >     Reviewed-by: Aleksa Sarai <cyphar@cyphar.com>
> >     Reviewed-by: Jan Kara <jack@suse.cz>
> >     Signed-off-by: Christian Brauner <brauner@kernel.org>
> > 
> > diff --git a/fs/pidfs.c b/fs/pidfs.c
> > index edc35522d75c..0a5083b9cce5 100644
> > --- a/fs/pidfs.c
> > +++ b/fs/pidfs.c
> > @@ -440,7 +440,7 @@ static bool pidfs_ioctl_valid(unsigned int cmd)
> >                  * erronously mistook the file descriptor for a pidfd.
> >                  * This is not perfect but will catch most cases.
> >                  */
> > -               return (_IOC_TYPE(cmd) == _IOC_TYPE(PIDFD_GET_INFO));
> > +               return extensible_ioctl_valid(cmd, PIDFD_GET_INFO, PIDFD_INFO_SIZE_VER0);
> >         }
> >  
> >         return false;
> > 
> > 
> > So kernel has changed error it returns, if this is a regression or not
> > is for kernel developers to decide.
> 
> Yes, it's mostly a question to Christian whether if passed size for
> extensible ioctl is smaller than minimal, we should be returning
> ENOIOCTLCMD or EINVAL. I think EINVAL would make more sense but Christian
> is our "extensible ioctl expert" :).

You're asking difficult questions actually. :D
I think it would be completely fine to return EINVAL in this case.
But traditionally ENOTTY has been taken to mean that this is not a
supported ioctl. This translation is done by the VFS layer itself iirc.

Re: 6.18.0-rc1: LTP syscalls ioctl_pidfd05: TFAIL: ioctl(pidfd, PIDFD_GET_INFO_SHORT, info_invalid) expected EINVAL: ENOTTY (25)

[Jan Kara]

On Tue 21-10-25 15:21:08, Christian Brauner wrote:
> On Fri, Oct 17, 2025 at 02:43:14PM +0200, Jan Kara wrote:
> > On Fri 17-10-25 11:40:41, Cyril Hrubis wrote:
> > > Hi!
> > > > > ## Test error log
> > > > > tst_buffers.c:57: TINFO: Test is using guarded buffers
> > > > > tst_test.c:2021: TINFO: LTP version: 20250930
> > > > > tst_test.c:2024: TINFO: Tested kernel: 6.18.0-rc1 #1 SMP PREEMPT
> > > > > @1760657272 aarch64
> > > > > tst_kconfig.c:88: TINFO: Parsing kernel config '/proc/config.gz'
> > > > > tst_kconfig.c:676: TINFO: CONFIG_TRACE_IRQFLAGS kernel option detected
> > > > > which might slow the execution
> > > > > tst_test.c:1842: TINFO: Overall timeout per run is 0h 21m 36s
> > > > > ioctl_pidfd05.c:45: TPASS: ioctl(pidfd, PIDFD_GET_INFO, NULL) : EINVAL (22)
> > > > > ioctl_pidfd05.c:46: TFAIL: ioctl(pidfd, PIDFD_GET_INFO_SHORT,
> > > > > info_invalid) expected EINVAL: ENOTTY (25)
> > > 
> > > Looking closely this is a different problem.
> > > 
> > > What we do in the test is that we pass PIDFD_IOCTL_INFO whith invalid
> > > size with:
> > > 
> > > struct pidfd_info_invalid {
> > >         uint32_t dummy;
> > > };
> > > 
> > > #define PIDFD_GET_INFO_SHORT _IOWR(PIDFS_IOCTL_MAGIC, 11, struct pidfd_info_invalid)
> > > 
> > > 
> > > And we expect to hit:
> > > 
> > >         if (usize < PIDFD_INFO_SIZE_VER0)
> > >                 return -EINVAL; /* First version, no smaller struct possible */
> > > 
> > > in fs/pidfs.c
> > > 
> > > 
> > > And apparently the return value was changed in:
> > > 
> > > commit 3c17001b21b9f168c957ced9384abe969019b609
> > > Author: Christian Brauner <brauner@kernel.org>
> > > Date:   Fri Sep 12 13:52:24 2025 +0200
> > > 
> > >     pidfs: validate extensible ioctls
> > >     
> > >     Validate extensible ioctls stricter than we do now.
> > >     
> > >     Reviewed-by: Aleksa Sarai <cyphar@cyphar.com>
> > >     Reviewed-by: Jan Kara <jack@suse.cz>
> > >     Signed-off-by: Christian Brauner <brauner@kernel.org>
> > > 
> > > diff --git a/fs/pidfs.c b/fs/pidfs.c
> > > index edc35522d75c..0a5083b9cce5 100644
> > > --- a/fs/pidfs.c
> > > +++ b/fs/pidfs.c
> > > @@ -440,7 +440,7 @@ static bool pidfs_ioctl_valid(unsigned int cmd)
> > >                  * erronously mistook the file descriptor for a pidfd.
> > >                  * This is not perfect but will catch most cases.
> > >                  */
> > > -               return (_IOC_TYPE(cmd) == _IOC_TYPE(PIDFD_GET_INFO));
> > > +               return extensible_ioctl_valid(cmd, PIDFD_GET_INFO, PIDFD_INFO_SIZE_VER0);
> > >         }
> > >  
> > >         return false;
> > > 
> > > 
> > > So kernel has changed error it returns, if this is a regression or not
> > > is for kernel developers to decide.
> > 
> > Yes, it's mostly a question to Christian whether if passed size for
> > extensible ioctl is smaller than minimal, we should be returning
> > ENOIOCTLCMD or EINVAL. I think EINVAL would make more sense but Christian
> > is our "extensible ioctl expert" :).
> 
> You're asking difficult questions actually. :D
> I think it would be completely fine to return EINVAL in this case.
> But traditionally ENOTTY has been taken to mean that this is not a
> supported ioctl. This translation is done by the VFS layer itself iirc.

Now the translation is done by VFS, I agree. But in the past (when the LTP
test was written) extensible ioctl with too small structure passed the
initial checks, only later we found out the data is too short and returned
EINVAL for that case. I *think* we are fine with just adjusting the test to
accept the new world order but wanted your opinion what are the chances of
some real userspace finding the old behavior useful or otherwise depending
on it.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: 6.18.0-rc1: LTP syscalls ioctl_pidfd05: TFAIL: ioctl(pidfd, PIDFD_GET_INFO_SHORT, info_invalid) expected EINVAL: ENOTTY (25)

[Petr Vorel]

> On Tue 21-10-25 15:21:08, Christian Brauner wrote:
> > On Fri, Oct 17, 2025 at 02:43:14PM +0200, Jan Kara wrote:
> > > On Fri 17-10-25 11:40:41, Cyril Hrubis wrote:
> > > > Hi!
> > > > > > ## Test error log
> > > > > > tst_buffers.c:57: TINFO: Test is using guarded buffers
> > > > > > tst_test.c:2021: TINFO: LTP version: 20250930
> > > > > > tst_test.c:2024: TINFO: Tested kernel: 6.18.0-rc1 #1 SMP PREEMPT
> > > > > > @1760657272 aarch64
> > > > > > tst_kconfig.c:88: TINFO: Parsing kernel config '/proc/config.gz'
> > > > > > tst_kconfig.c:676: TINFO: CONFIG_TRACE_IRQFLAGS kernel option detected
> > > > > > which might slow the execution
> > > > > > tst_test.c:1842: TINFO: Overall timeout per run is 0h 21m 36s
> > > > > > ioctl_pidfd05.c:45: TPASS: ioctl(pidfd, PIDFD_GET_INFO, NULL) : EINVAL (22)
> > > > > > ioctl_pidfd05.c:46: TFAIL: ioctl(pidfd, PIDFD_GET_INFO_SHORT,
> > > > > > info_invalid) expected EINVAL: ENOTTY (25)

> > > > Looking closely this is a different problem.

> > > > What we do in the test is that we pass PIDFD_IOCTL_INFO whith invalid
> > > > size with:

> > > > struct pidfd_info_invalid {
> > > >         uint32_t dummy;
> > > > };

> > > > #define PIDFD_GET_INFO_SHORT _IOWR(PIDFS_IOCTL_MAGIC, 11, struct pidfd_info_invalid)


> > > > And we expect to hit:

> > > >         if (usize < PIDFD_INFO_SIZE_VER0)
> > > >                 return -EINVAL; /* First version, no smaller struct possible */

> > > > in fs/pidfs.c


> > > > And apparently the return value was changed in:

> > > > commit 3c17001b21b9f168c957ced9384abe969019b609
> > > > Author: Christian Brauner <brauner@kernel.org>
> > > > Date:   Fri Sep 12 13:52:24 2025 +0200

> > > >     pidfs: validate extensible ioctls

> > > >     Validate extensible ioctls stricter than we do now.

> > > >     Reviewed-by: Aleksa Sarai <cyphar@cyphar.com>
> > > >     Reviewed-by: Jan Kara <jack@suse.cz>
> > > >     Signed-off-by: Christian Brauner <brauner@kernel.org>

> > > > diff --git a/fs/pidfs.c b/fs/pidfs.c
> > > > index edc35522d75c..0a5083b9cce5 100644
> > > > --- a/fs/pidfs.c
> > > > +++ b/fs/pidfs.c
> > > > @@ -440,7 +440,7 @@ static bool pidfs_ioctl_valid(unsigned int cmd)
> > > >                  * erronously mistook the file descriptor for a pidfd.
> > > >                  * This is not perfect but will catch most cases.
> > > >                  */
> > > > -               return (_IOC_TYPE(cmd) == _IOC_TYPE(PIDFD_GET_INFO));
> > > > +               return extensible_ioctl_valid(cmd, PIDFD_GET_INFO, PIDFD_INFO_SIZE_VER0);
> > > >         }

> > > >         return false;


> > > > So kernel has changed error it returns, if this is a regression or not
> > > > is for kernel developers to decide.

> > > Yes, it's mostly a question to Christian whether if passed size for
> > > extensible ioctl is smaller than minimal, we should be returning
> > > ENOIOCTLCMD or EINVAL. I think EINVAL would make more sense but Christian
> > > is our "extensible ioctl expert" :).

> > You're asking difficult questions actually. :D
> > I think it would be completely fine to return EINVAL in this case.
> > But traditionally ENOTTY has been taken to mean that this is not a
> > supported ioctl. This translation is done by the VFS layer itself iirc.

> Now the translation is done by VFS, I agree. But in the past (when the LTP
> test was written) extensible ioctl with too small structure passed the
> initial checks, only later we found out the data is too short and returned
> EINVAL for that case. I *think* we are fine with just adjusting the test to
> accept the new world order but wanted your opinion what are the chances of
> some real userspace finding the old behavior useful or otherwise depending
> on it.

+1, thanks! Is it ok just expect any of these two regardless kernel version?

@Naresh Kamboju will you send a patch to LTP ML?

Kind regards,
Petr

> 								Honza

Re: 6.18.0-rc1: LTP syscalls ioctl_pidfd05: TFAIL: ioctl(pidfd, PIDFD_GET_INFO_SHORT, info_invalid) expected EINVAL: ENOTTY (25)

[Naresh Kamboju]

On Wed, 22 Oct 2025 at 13:21, Petr Vorel <pvorel@suse.cz> wrote:
>
> > On Tue 21-10-25 15:21:08, Christian Brauner wrote:
> > > On Fri, Oct 17, 2025 at 02:43:14PM +0200, Jan Kara wrote:
> > > > On Fri 17-10-25 11:40:41, Cyril Hrubis wrote:
> > > > > Hi!
> > > > > > > ## Test error log
> > > > > > > tst_buffers.c:57: TINFO: Test is using guarded buffers
> > > > > > > tst_test.c:2021: TINFO: LTP version: 20250930
> > > > > > > tst_test.c:2024: TINFO: Tested kernel: 6.18.0-rc1 #1 SMP PREEMPT
> > > > > > > @1760657272 aarch64
> > > > > > > tst_kconfig.c:88: TINFO: Parsing kernel config '/proc/config.gz'
> > > > > > > tst_kconfig.c:676: TINFO: CONFIG_TRACE_IRQFLAGS kernel option detected
> > > > > > > which might slow the execution
> > > > > > > tst_test.c:1842: TINFO: Overall timeout per run is 0h 21m 36s
> > > > > > > ioctl_pidfd05.c:45: TPASS: ioctl(pidfd, PIDFD_GET_INFO, NULL) : EINVAL (22)
> > > > > > > ioctl_pidfd05.c:46: TFAIL: ioctl(pidfd, PIDFD_GET_INFO_SHORT,
> > > > > > > info_invalid) expected EINVAL: ENOTTY (25)
>
> > > > > Looking closely this is a different problem.
>
> > > > > What we do in the test is that we pass PIDFD_IOCTL_INFO whith invalid
> > > > > size with:
>
> > > > > struct pidfd_info_invalid {
> > > > >         uint32_t dummy;
> > > > > };
>
> > > > > #define PIDFD_GET_INFO_SHORT _IOWR(PIDFS_IOCTL_MAGIC, 11, struct pidfd_info_invalid)
>
>
> > > > > And we expect to hit:
>
> > > > >         if (usize < PIDFD_INFO_SIZE_VER0)
> > > > >                 return -EINVAL; /* First version, no smaller struct possible */
>
> > > > > in fs/pidfs.c
>
>
> > > > > And apparently the return value was changed in:
>
> > > > > commit 3c17001b21b9f168c957ced9384abe969019b609
> > > > > Author: Christian Brauner <brauner@kernel.org>
> > > > > Date:   Fri Sep 12 13:52:24 2025 +0200
>
> > > > >     pidfs: validate extensible ioctls
>
> > > > >     Validate extensible ioctls stricter than we do now.
>
> > > > >     Reviewed-by: Aleksa Sarai <cyphar@cyphar.com>
> > > > >     Reviewed-by: Jan Kara <jack@suse.cz>
> > > > >     Signed-off-by: Christian Brauner <brauner@kernel.org>
>
> > > > > diff --git a/fs/pidfs.c b/fs/pidfs.c
> > > > > index edc35522d75c..0a5083b9cce5 100644
> > > > > --- a/fs/pidfs.c
> > > > > +++ b/fs/pidfs.c
> > > > > @@ -440,7 +440,7 @@ static bool pidfs_ioctl_valid(unsigned int cmd)
> > > > >                  * erronously mistook the file descriptor for a pidfd.
> > > > >                  * This is not perfect but will catch most cases.
> > > > >                  */
> > > > > -               return (_IOC_TYPE(cmd) == _IOC_TYPE(PIDFD_GET_INFO));
> > > > > +               return extensible_ioctl_valid(cmd, PIDFD_GET_INFO, PIDFD_INFO_SIZE_VER0);
> > > > >         }
>
> > > > >         return false;
>
>
> > > > > So kernel has changed error it returns, if this is a regression or not
> > > > > is for kernel developers to decide.
>
> > > > Yes, it's mostly a question to Christian whether if passed size for
> > > > extensible ioctl is smaller than minimal, we should be returning
> > > > ENOIOCTLCMD or EINVAL. I think EINVAL would make more sense but Christian
> > > > is our "extensible ioctl expert" :).
>
> > > You're asking difficult questions actually. :D
> > > I think it would be completely fine to return EINVAL in this case.
> > > But traditionally ENOTTY has been taken to mean that this is not a
> > > supported ioctl. This translation is done by the VFS layer itself iirc.
>
> > Now the translation is done by VFS, I agree. But in the past (when the LTP
> > test was written) extensible ioctl with too small structure passed the
> > initial checks, only later we found out the data is too short and returned
> > EINVAL for that case. I *think* we are fine with just adjusting the test to
> > accept the new world order but wanted your opinion what are the chances of
> > some real userspace finding the old behavior useful or otherwise depending
> > on it.
>
> +1, thanks! Is it ok just expect any of these two regardless kernel version?
>
> @Naresh Kamboju will you send a patch to LTP ML?

Sure.
I love to send patches to LTP mailing list.

>
> Kind regards,
> Petr
>
> >                                                               Honza