external API: fix ioctl command definitions

This changes the ioctl commands to follow the common
conventions, resolving one item from the TODO file:

* We use _IO for commands that use the argument as a literal
  and not dereference it as a pointer. KDBUS_CMD_MEMFD_SEAL_SET
  just passes an bool here, and KDBUS_CMD_MSG_RELEASE passes
  a pointer that is compared to other pointers but not accessed.

* _IOR is used for commands that only copy data from the kernel
  to user space, IOW is used for commands that only copy into
  the kernel, which is the majority here. _IOWR is used only
  for commands that both read and write on the pointer passed
  as the ioctl arg. Whether we read or write from indirect
  pointers passed in the structure is not relevant here.

* The size argument must be the data structure that the ioctl
  argument points to. Importantly, this is not a pointer type
  as e.g. in the old KDBUS_CMD_MSG_RECV definition. Using
  a pointer here breaks 32 bit compat mode because taking
  sizeof(__u64*) results in a different command number on 32 and
  64 bit user space.

An open question is what to do for commands with variable-length
arguments. Some subsystems in the kernel actually define variable-length
commands as

 #define KDBUS_CMD_MSG_SEND(len) _IOC(_IOC_WRITE,KDBUS_IOC_MAGIC,\
				 0x40,sizeof(struct kdbus_msg)+(len))

This has the advantage of saving one 'copy_from_user' for each
call, and actually reflecting the correct size in the command
number, but it can also confuse readers. The maximum size that
can be passed like this is 8192 (alpha, mips, sparc, powerpc)
or 16384 (all other architectures) bytes, which may also be a
limitation.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

1 files changed, 0 insertions, 1 deletions

diff --git a/TODO b/TODO
index b0b26e58fe8..05034560522 100644
--- a/TODO
+++ b/TODO
@@ -1,5 +1,4 @@
 External API:
-  - _IOWR() vs. _IOR()/_IOW()?
   - rules for: which unknown items to ignore in userspace?
 
 Internal: