[RFC 0/n] Pass kernel buffers to sock->ops->[sg]et_sockopt() functions

[RFC 0/n] Pass kernel buffers to sock->ops->[sg]et_sockopt() functions

[David Laight]

There are a few code paths (including BPF intercept) that
currently use set_fs(KERNEL_DS) prior to actioning
[sg]et_sockopt() in order toget kernel buffers accessed by
copy_to/from_user().

The 32bit compat code also has to allocate buffer space
on the user stack to copy out translated requests so that
the 64bit code can read them back from userspace.

All the code that processes the requests also has to
call copy_to/from_user() all over the place and check for
failures.

This can all be simplified if the system call entry code
handles the copy_to/from_user() and all the rest of the
code just processes the kernel buffer.

Now, when getsockopt() was first implemented the kernel
code just assumed that the user buffer was long enough.
But some time later the length parameter was made read/update.
So the __sys_getsockopt() knows how big a kernel buffer
is required (in spite of the comment above the entry point).

This patch sequence (to be written) does the following:

Patch 1: Change __sys_setsockopt() to allocate a kernel buffer,
         copy the data into it then call set_fs(KERNEL_DS).
         An on-stack buffer (say 64 bytes) will be used for
         small transfers.

Patch 2: The same for __sys_getsockopt().

Patch 3: Compat setsockopt.

Patch 4: Compat getsockopt.

Patch 5: Remove the user copies from the global socket options code.

Patches 6 to n-1; Remove the user copies from the per-protocol code.

Patch n: Remove the set_fs(KERNEL_DS) from the entry points.

This should be bisectable.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)