[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201106261913.05752.arnd@arndb.de>
Date: Sun, 26 Jun 2011 19:13:05 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Mauro Carvalho Chehab <mchehab@...hat.com>
Cc: Sakari Ailus <sakari.ailus@....fi>,
Linux Media Mailing List <linux-media@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] [media] v4l2 core: return -ENOIOCTLCMD if an ioctl doesn't exist
On Sunday 26 June 2011 18:20:21 Mauro Carvalho Chehab wrote:
> > The V4L2 core probably should return -ENOIOCTLCMD when an IOCTL isn't implemented, but as long as vfs_ioctl() would stay as it is, the user space would still get -EINVAL. Or is vfs_ioctl() about to change?
> >
> > fs/ioctl.c:
> > ----8<-----------
> > static long vfs_ioctl(struct file *filp, unsigned int cmd,
> > unsigned long arg)
> > {
> > int error = -ENOTTY;
> >
> > if (!filp->f_op || !filp->f_op->unlocked_ioctl)
> > goto out;
> >
> > error = filp->f_op->unlocked_ioctl(filp, cmd, arg);
> > if (error == -ENOIOCTLCMD)
> > error = -EINVAL;
> > out:
> > return error;
> > }
> > ----8<-----------
One of the differences between the old ->ioctl() and the ->unlocked_ioctl()
function is that unlocked_ioctl could point to the same function as
->compat_ioctl(), so we have to catch functions returning -ENOIOCTLCMD.
> Good catch!
>
> At the recent git history, the return for -ENOIOCTLCMD were modified
> by this changeset:
>
> commit b19dd42faf413b4705d4adb38521e82d73fa4249
> Author: Arnd Bergmann <arnd@...db.de>
> Date: Sun Jul 4 00:15:10 2010 +0200
>
> bkl: Remove locked .ioctl file operation
> ...
> @@ -39,21 +38,12 @@ static long vfs_ioctl(struct file *filp, unsigned int cmd,
> {
> int error = -ENOTTY;
>
> - if (!filp->f_op)
> + if (!filp->f_op || !filp->f_op->unlocked_ioctl)
> goto out;
>
> - if (filp->f_op->unlocked_ioctl) {
> - error = filp->f_op->unlocked_ioctl(filp, cmd, arg);
> - if (error == -ENOIOCTLCMD)
> - error = -EINVAL;
> - goto out;
> - } else if (filp->f_op->ioctl) {
> - lock_kernel();
> - error = filp->f_op->ioctl(filp->f_path.dentry->d_inode,
> - filp, cmd, arg);
> - unlock_kernel();
> ...
>
> Before Arnd's patch, locked ioctl's were returning -ENOIOCTLCMD, and
> unlocked ones were returning -EINVAL. Now, the return of -ENOIOCTLCMD
> doesn't go to userspace anymore. IMO, that's wrong and can cause
> regressions, as some subsystems like DVB were returning -ENOIOCTLCMD
> to userspace.
ENOIOCTLCMD should never be returned to user space, see the comment
in include/linux/errno.h:
/*
* These should never be seen by user programs. To return one of ERESTART*
* codes, signal_pending() MUST be set. Note that ptrace can observe these
* at syscall exit tracing, but they will never be left for the debugged user
* process to see.
*/
There was a lot of debate whether undefined ioctls on non-ttys should
return -EINVAL or -ENOTTY, including mass-conversions from -ENOTTY to
-EINVAL at some point in the pre-git era, IIRC.
Inside of v4l2, I believe this is handled by video_usercopy(), which
turns the driver's -ENOIOCTLCMD into -ENOTTY. What cases do you observe
where this is not done correctly and we do return ENOIOCTLCMD to
vfs_ioctl?
> The right fix would be to remove this from fs:
>
> diff --git a/fs/ioctl.c b/fs/ioctl.c
> index 1d9b9fc..802fbbd 100644
> --- a/fs/ioctl.c
> +++ b/fs/ioctl.c
> @@ -41,8 +41,6 @@ static long vfs_ioctl(struct file *filp, unsigned int cmd,
> goto out;
>
> error = filp->f_op->unlocked_ioctl(filp, cmd, arg);
> - if (error == -ENOIOCTLCMD)
> - error = -EINVAL;
> out:
> return error;
> }
>
> However, the replacement from -EINVAL to -ENOIOCTLCMD is there since 2.6.12 for
> unlocked_ioctl:
>
> $ git blame b19dd42f^1 fs/ioctl.c
> ...
> ^1da177e (Linus Torvalds 2005-04-16 15:20:36 -0700 46) error = filp->f_op->unlocked_ioctl(filp, cmd, arg);
> ^1da177e (Linus Torvalds 2005-04-16 15:20:36 -0700 47) if (error == -ENOIOCTLCMD)
> ^1da177e (Linus Torvalds 2005-04-16 15:20:36 -0700 48) error = -EINVAL;
>
> Linus,
>
> what would be the expected behaviour?
Note that 1da177e is the initial commit to git, Linus did not write that
code, although he might have an opinion.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists