Re: Broken ioctl error returns (was Re: [PATCH 2/3] block: fail SCSIpassthrough ioctls on partition devices)

[Linus Torvalds]

On Thu, Jan 5, 2012 at 9:02 AM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> Added, linux-media and Mauro to the Cc, because I'm about to commit
> something like the attached patch to see if anything breaks. We may
> have to revert it if things get too nasty, but we should have done
> this years and years ago, so let's hope not.

Ok, so "It works for me". I'll delay committing it in case somebody
has some quick obvious fixes or comments (like noticing other cases
like the blk_ioctl.c one), but on the whole I think I'll commit it
later today, just so that it will be as early as possible in the merge
window in case there is ENOTTY/EINVAL confusion.

The good news is that no user space can *ever* care about
ENOTTY/EINVAL in the "generic case", since different drivers have
returned different error returns for years. So user space that doesn't
know exactly what it is dealing with will pretty much by definition
not be affected. Except perhaps in a good way - if it uses "perror()"
or "strerror()" or similar, it will now give a much better error
string of "Inappropriate ioctl for device".

However, some applications don't work with "generic devices", but
instead work with a very specific device or perhaps a very specific
subset.

So the exception would be user space apps that know exactly which
driver they are talking about, and that particular driver used to
always return EINVAL before, and now the ENOIOCTLCMD -> ENOTTY fix
means that it returns the proper ENOTTY - and the application has
never seen it, and never tested against it, and breaks.

I don't *think* this happens outside of the media drivers, but we'll
see. It may be that we will have to make certain drivers return EINVAL
explicitly rather than ENOIOCTLCMD and add a comment about why. Sad,
if so, so we'll have little choice. Let's see what the breakage (if
any - cross your fingers) looks like.

                               Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/