Remove the special case for FITRIM, and make file systems
handle that like all other ioctl commands with their own
handlers.

Cc: linux-ext4@vger.kernel.org
Cc: linux-f2fs-devel@lists.sourceforge.net
Cc: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Cc: linux-nilfs@vger.kernel.org
Cc: ocfs2-devel@oss.oracle.com
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The last users are all gone, so let's remove the macro as well.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Commit aa98aa31 ("md: move compat_ioctl handling into md.c")
already removed the COMPATIBLE_IOCTL() table entries and added
a complete implementation, but a few lines got left behind and
should also be removed here.

Cc: linux-raid@vger.kernel.org
Cc: Song Liu <song@kernel.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The /dev/rawX implementation already handles these just fine, so
the entries in the table are not needed any more.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The /proc/pci/ implementation already handles these just fine, so
the entries in the table are not needed any more.

Cc: linux-pci@vger.kernel.org
Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The joystick driver already handles these just fine, so
the entries in the table are not needed any more.

Cc: linux-input@vger.kernel.org
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

These are all handled by the random driver, so instead of listing
each ioctl, we can use the generic compat_ptr_ioctl() helper.
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Since commit 07d106d0 ("vfs: fix up ENOIOCTLCMD error handling"),
we don't warn about unhandled compat-ioctl command code any more, but
just return the same error that a native file descriptor returns when
there is no handler.

This means the IGNORE_IOCTL() annotations are completely useless and
can all be removed. TIOCSTART/TIOCSTOP and KDGHWCLK/KDSHWCLK fall into
the same category, but for some reason were listed as COMPATIBLE_IOCTL().
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The SNDCTL_* and SOUND_* commands are the old OSS user interface.

I checked all the sound ioctl commands listed in fs/compat_ioctl.c
to see if we still need the translation handlers. Here is what I
found:

- sound/oss/ is (almost) gone from the kernel, this is what actually
  needed all the translations
- The ALSA emulation for OSS correctly handles all compat_ioctl
  commands already.
- sound/oss/dmasound/ is the last holdout of the original OSS code,
  this is only used on arch/m68k, which has no 64-bit mode and
  hence needs no compat handlers
- arch/um/drivers/hostaudio_kern.c may run in 64-bit mode with
  32-bit x86 user space underneath it. This rare corner case is
  the only one that still needs the compat handlers.

By adding a simple redirect of .compat_ioctl to .unlocked_ioctl in the
UML driver, we can remove all the COMPATIBLE_IOCTL() annotations without
a change in functionality. For completeness, I'm adding the same thing
to the dmasound file, knowing that it makes no difference.

The compat_ioctl list contains one comment about SNDCTL_DSP_MAPINBUF and
SNDCTL_DSP_MAPOUTBUF, which actually would need a translation handler
if implemented. However, the native implementation just returns -EINVAL,
so we don't care.
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The two drivers implementing these both gained proper compat_ioctl()
handlers a long time ago with commits bb6c8d8f ("HID: hiddev:
Add 32bit ioctl compatibilty") and ae5e49c7 ("HID: hidraw: add
compatibility ioctl() for 32-bit applications."), so the lists in
fs/compat_ioctl.c are no longer used.

It appears that the lists were also incomplete, so the translation
didn't actually work correctly when it was still in use.

Remove them as cleanup.

Cc: linux-bluetooth@vger.kernel.org
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

As of commit f0193d3e ("change semantics of ldisc ->compat_ioctl()"),
all hciuart ioctl commands are handled correctly in the driver, and we
never need to go through the table here.

Cc: linux-bluetooth@vger.kernel.org
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

All these ioctl commands are compatible, so we can handle
them with a trivial wrapper in hci_sock.c and remove
the listing in fs/compat_ioctl.c.

A few of the commands pass integer arguments instead of
pointers, so for correctness skip the compat_ptr() conversion
here.
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

All these ioctl commands are compatible, so we can handle
them with a trivial wrapper in rfcomm/sock.c and remove
the listing in fs/compat_ioctl.c.
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Neither the old isdn4linux interface nor the newer mISDN stack
ever had working 32-bit compat mode as far as I can tell.

However, the CAPI stack has some ioctl commands that are
correctly listed in fs/compat_ioctl.c.

We can trivially move all of those into the corresponding
file that implement the native handlers by adding a compat_ioctl
redirect to that.

I did notice that treating CAPI_MANUFACTURER_CMD() as compatible
is broken, so I'm also adding a handler for that, realizing that
in all likelyhood, nobody is ever going to call it.

Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: netdev@vger.kernel.org
Cc: isdn4linux@listserv.isdn4linux.de
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

These are two obscure ioctl commands, in a driver that only
has compatible commands, so just let the driver handle this
itself.
Acked-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

MTIOCPOS and MTIOCGET are incompatible between 32-bit and 64-bit user
space, and traditionally have been translated in fs/compat_ioctl.c.

To get rid of that translation handler, move a corresponding
implementation into each of the four drivers implementing those commands.

The interesting part of that is now in a new linux/mtio.h header that
wraps the existing uapi/linux/mtio.h header and provides an abstraction
to let drivers handle both cases easily. Using an in_compat_syscall()
check, the caller does not have to keep track of whether this was
called through .unlocked_ioctl() or .compat_ioctl().
Acked-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Cc: "Kai Mäkisara" <Kai.Makisara@kolumbus.fi>
Cc: linux-scsi@vger.kernel.org
Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

We no longer need the rtc compat handling to be in common code, now that
all drivers are either moved to the rtc-class framework, or (rarely)
exist in drivers/char for architectures without compat mode (m68k,
alpha and ia64, respectively).

I checked the list of ioctl commands in drivers, and the ones that are
not already handled are all compatible, again with the one exception of
m68k driver, which implements RTC_PLL_GET and RTC_PLL_SET, but has no
compat mode.

Unlike earlier versions of this patch, I'm now adding a separate
compat_ioctl handler that takes care of RTC_IRQP_READ32/RTC_IRQP_SET32
and treats all other commands as compatible, leaving the native
behavior unchanged.

The old conversion handler also deals with RTC_EPOCH_READ and
RTC_EPOCH_SET, which are not handled in rtc-dev.c but only in a single
device driver (rtc-vr41xx), so I'm adding the compat version in the same
place. I don't expect other drivers to need those commands in the future.
Acked-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Reviewed-by: NBen Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
---
v4: handle RTC_EPOCH_SET32 in rtc_dev_compat_ioctl
v3: handle RTC_IRQP_READ32/RTC_IRQP_SET32 in rtc_dev_compat_ioctl
v2: merge compat handler into ioctl function to avoid the
    compat_alloc_user_space() roundtrip, based on feedback
    from Al Viro.

Handle ioctls that might be handled without reaching ->ioctl() in
native case on the top level there.  The counterpart of vfs_ioctl()
(i.e. calling ->unlock_ioctl(), etc.) left as-is; eventually
that would turn simply into the call of ->compat_ioctl(), but
that'll take more work.  Once that is done, we can move the
remains of compat_sys_ioctl() into fs/ioctl.c and finally bury
fs/compat_ioctl.c.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

... and lose the ridiculous games with compat_alloc_user_space()
there.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

... and hadn't for a long time.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

it takes a pointer argument, regular file or no regular file
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Unlike FICLONE, all of those take a pointer argument; they do need
compat_ptr() applied to arg.

Fixes: d79bdd52 ("vfs: wire up compat ioctl for CLONE/CLONE_RANGE")
Fixes: 54dbc151 ("vfs: hoist the btrfs deduplication ioctl to the vfs")
Fixes: ceac204e ("fs: make fiemap work from compat_ioctl")
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Support for handling the PPPOEIOCSFWD ioctl in compat mode was added in
linux-2.5.69 along with hundreds of other commands, but was always broken
sincen only the structure is compatible, but the command number is not,
due to the size being sizeof(size_t), or at first sizeof(sizeof((struct
sockaddr_pppox)), which is different on 64-bit architectures.

Guillaume Nault adds:

  And the implementation was broken until 2016 (see 29e73269 ("pppoe:
  fix reference counting in PPPoE proxy")), and nobody ever noticed. I
  should probably have removed this ioctl entirely instead of fixing it.
  Clearly, it has never been used.

Fix it by adding a compat_ioctl handler for all pppoe variants that
translates the command number and then calls the regular ioctl function.

All other ioctl commands handled by pppoe are compatible between 32-bit
and 64-bit, and require compat_ptr() conversion.

This should apply to all stable kernels.
Acked-by: NGuillaume Nault <g.nault@alphalink.fr>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

all of those are provided only by vt and s390 tty3270; both have
proper ->compat_ioctl()
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

... and get rid of COMPAT_IOCTL() for its private ioctls
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

TIOCLINUX is handled by ->compat_ioctl() in the only place that has
native ->ioctl() recognizing it, TIOC{START,STOP} are simply useless
these days - unrecognized compat ioctl won't spew into syslog
anymore.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

ioctls that are
	* callable only via tty_ioctl()
	* not driver-specific
	* not demand data structure conversions
	* either always need passing arg as is or always demand compat_ptr()
get intercepted in tty_compat_ioctl() from the very beginning and
redirecter to tty_ioctl().  As the result, their entries in fs/compat_ioctl.c
(some of those had been missing, BTW) got removed, as well as
n_tty_compat_ioctl_helper() (now it's never called with any cmd it would accept).
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

The VIDEO_STILLPICTURE is only implemented by one driver, while
VIDEO_GET_EVENT has two users in tree. In both cases, it is fairly
easy to handle the compat ioctls in the native handler rather
than relying on translation in fs/compat_ioctls.

In effect, this means that now the drivers implement both structure
layouts in both native and compat mode, but I don't see anything
wrong with that.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Most DVB audio and video ioctl commands are completely compatible,
and are implemented by just two drivers: ttpci and ivtv. In both
cases, we can use the same ioctl handler for both native and
compat ioctl handling, and remove the entries from the global
lookup table.

In case of ttpci, this directly hooks into the file_operations
structure, and for ivtv, we have to set the compat_ioctl32
method in v4l2_file_operations. For all I can tell, setting it
to video_ioctl2 will still do the right thing for all commands.

Note that for the VIDEO_STILLPICTURE and VIDEO_GET_EVENT commands,
a translation handler in fs/compat_ioctl.c is still used. This
works because the command numbers are different on 32-bit
systems.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

All the CEC ioctls are compatible, and they are only implemented
in one driver, so we can simply let this driver handle them
natively.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

All dmx ioctls are compatible, and they are only implemented
in one file, so we can replace the list of commands in
fs/compat_ioctl.c with a single line in dmxdev.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

The VIDEO_GET_EVENT and VIDEO_STILLPICTURE was added back in 2005 but
it never worked because the command number is wrong.

Using the right command number means we have a better chance of them
actually doing the right thing, though clearly nobody has ever tried
it successfully.

I noticed these while auditing the remaining users of compat_time_t
for y2038 bugs. This one is fine in that regard, it just never did
anything.

Fixes: 6e87abd0 ("[DVB]: Add compat ioctl handling.")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

1) no point putting it into fs/compat_ioctl.c when you handle it in
your ->compat_ioctl() anyway.
2) HIDPCONNADD is *not* COMPATIBLE_IOCTL() stuff at all - it does
layout massage (pointer-chasing there)
3) use compat_ptr()
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Use compat_ptr().  And don't mess with fs/compat_ioctl.c
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

use compat_ptr() properly and don't bother with fs/compat_ioctl.c -
it's all handled in ->compat_ioctl() anyway.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

There are a number of other ioctls that aren't used anywhere
inside the Kernel tree.

Get rid of them.
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

There are a number of other ioctls that aren't used anywhere
inside the Kernel tree.

Get rid of them.
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>