use subsys_virtual_register()
pool: use shmem file as backing store
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>
external API: use explicit padding

Data structures with 64 bit members in them differ in alignment
by architecture: x86-32 keeps the alignment at 32 bit at most,
while all sane architectures including x86-64 use 64 bit
alignment and add extra implicit padding if necessary.

This means the kdbus_cmd_monitor structure is incompatible between
x86-64 and x86-32, unless we make the padding explcicit.

struct kdbus_memfd has a similar definition, so we change that
as well, although the change currently makes no difference because
it is always embedded in a larger structure.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
return proper -EINVAL instead of EINVAL for an error