linux-kernel - Re: [PATCH] [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 for Android: free password hash cracker in your pocket

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

Message-Id: <201106270738.27417.hverkuil@xs4all.nl>
Date:	Mon, 27 Jun 2011 07:38:27 +0200
From:	Hans Verkuil <hverkuil@...all.nl>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
Cc:	Arnd Bergmann <arnd@...db.de>, 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, June 26, 2011 20:51:37 Mauro Carvalho Chehab wrote:
> Em 26-06-2011 15:20, Arnd Bergmann escreveu:
> > On Sunday 26 June 2011 19:30:46 Mauro Carvalho Chehab wrote:
> >>> 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?
> >>
> >> Well, currently, it is returning -EINVAL maybe due to the mass-conversions
> >> you've mentioned.
> > 
> > I mean what do you return *to* vfs_ioctl from v4l? The conversions must
> > have been long before we introduced compat_ioctl and ENOIOCTLCMD.
> > 
> > As far as I can tell, video_ioctl2 has always converted ENOIOCTLCMD into
> > EINVAL, so changing the vfs functions would not have any effect.
> 
> Yes.  This discussion was originated by a RFC patch proposing to change 
> video_ioctl2 to return -ENOIOCTLCMD instead of -EINVAL.
> 
> >> The point is that -EINVAL has too many meanings at V4L. It currently can be
> >> either that an ioctl is not supported, or that one of the parameters had
> >> an invalid parameter. If the userspace can't distinguish between an unimplemented
> >> ioctl and an invalid parameter, it can't decide if it needs to fall back to
> >> some different methods of handling a V4L device.
> >>
> >> Maybe the answer would be to return -ENOTTY when an ioctl is not implemented.
> > 
> > That is what a lot of subsystems do these days. But wouldn't that change
> > your ABI?
> 
> Yes. The patch in question is also changing the DocBook spec for the ABI. We'll
> likely need to drop some notes about that at the features-to-be-removed.txt.
> 
> I don't think that applications are relying at -EINVAL in order to detect if
> an ioctl is not supported, but before merging such patch, we need to double-check.

I really don't think we can change this behavior. It's been part of the spec since
forever and it is not just open source apps that can rely on this, but also closed
source. Making an ABI change like this can really mess up applications.

We should instead review the spec and ensure that applications can discover what
is and what isn't supported through e.g. capabilities.

Regards,

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