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]
Message-ID: <BANLkTimBxTpzK3Ooc-gz=nJbhZ1Mu5d1cQ@mail.gmail.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ