linux-kernel - Re: [PATCH 01/14] [media] v4l2 core: return -ENOIOCTLCMD if an ioctl doesn't exist

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 26 Jun 2011 19:49:42 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
Cc:	Linux Media Mailing List <linux-media@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 01/14] [media] v4l2 core: return -ENOIOCTLCMD if an ioctl
 doesn't exist

On Sun, Jun 26, 2011 at 9:06 AM, Mauro Carvalho Chehab
<mchehab@...hat.com> wrote:
> +       <term><errorcode>ENOIOCTLCMD</errorcode></term>
> +       <listitem>
> +         <para>The application attempted to use a non-existent ioctl. This is returned by the V4L2 core only.
> +               Applications should be able to handle this error code, in order to detect if a new ioctl is
> +               not implemented at the current Kernel version. Kernel versions lower than 3.0 returns EINVAL to
> +               non-existing ioctl's.</para>

This seems entirely bogus.

ENOICTLCMD is meant to be an entirely kernel-internal one, which is
meant to never be shown to user space. IOW, vfs_ioctl() turns it into
EINVAL (which I personally think is bogus - traditionally ENOTTY is
the right one for "not a valid ioctl", but there are people who
disagree - whatever)

The rationale for it is mainly as a way for layers inside the kernel
to determine the difference between "ioctl existed but failed with
EINVAL" vs "ioctl doesn't actually exist". Some layers try first one
thing and then another, and want to know the difference. An example of
that might be some code that first tries to call device-specific
version, and if that doesn't exist, do a generic emulation version.

Of course, as far as I can tell, almost nothing does that anyway.
Regardless, it's definitely wrong to document it as being returned to
user land. It should never be user-visible.

                  Linus
--
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/