[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251022075134.GA463176@pevik>
Date: Wed, 22 Oct 2025 09:51:34 +0200
From: Petr Vorel <pvorel@...e.cz>
To: Jan Kara <jack@...e.cz>
Cc: Christian Brauner <brauner@...nel.org>, Cyril Hrubis <chrubis@...e.cz>,
Naresh Kamboju <naresh.kamboju@...aro.org>,
open list <linux-kernel@...r.kernel.org>,
linux-fsdevel@...r.kernel.org, lkft-triage@...ts.linaro.org,
Linux Regressions <regressions@...ts.linux.dev>,
LTP List <ltp@...ts.linux.it>,
Andrey Albershteyn <aalbersh@...nel.org>,
Arnd Bergmann <arnd@...db.de>,
Alexander Viro <viro@...iv.linux.org.uk>,
Dan Carpenter <dan.carpenter@...aro.org>,
Anders Roxell <anders.roxell@...aro.org>,
Ben Copeland <benjamin.copeland@...aro.org>,
Andrea Cervesato <andrea.cervesato@...e.com>
Subject: Re: 6.18.0-rc1: LTP syscalls ioctl_pidfd05: TFAIL: ioctl(pidfd,
PIDFD_GET_INFO_SHORT, info_invalid) expected EINVAL: ENOTTY (25)
> 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@...nel.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@...har.com>
> > > > Reviewed-by: Jan Kara <jack@...e.cz>
> > > > Signed-off-by: Christian Brauner <brauner@...nel.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
Powered by blists - more mailing lists