On Wed, Jan 17, 2018 at 07:16:02PM -0800, Linus Torvalds wrote: > On Wed, Jan 17, 2018 at 7:06 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > > Similar to the way put_cmsg() handles 32bit case on biarch > > targets, introduce a flag telling put_cmsg() to treat > > ->msg_control as kernel pointer, using memcpy instead of > > copy_to_user(). That allows to avoid the use of kernel_recvmsg() > > with its set_fs(). > > If this is the only case that kernel_recvmsg() exists for, then by all > means, that patch certainly looks like a good thing. In -next that's the only remaining caller. kernel_recvmsg() is { mm_segment_t oldfs = get_fs(); int result; iov_iter_kvec(&msg->msg_iter, READ | ITER_KVEC, vec, num, size); set_fs(KERNEL_DS); result = sock_recvmsg(sock, msg, flags); set_fs(oldfs); return result; } and iov_iter_kvec(&msg->msg_iter, READ | ITER_KVEC, vec, num, size); result = sock_recvmsg(sock, msg, flags); works just fine for copying the data - that gets handled by copy_to_iter() and copy_page_to_iter(). Those don't care about set_fs(); the trouble with sunrpc call site is that we want to fill msg_control-pointed kernel object. That gets copied by put_cmsg(). We could turn ->msg_control/->msg_controllen into another iov_iter, but seeing that we never do scatter-gather for those IMO that would be a massive overkill. A flag controlling whether ->msg_control is kernel or userland pointer would do, especially since we already have a flag for "do we want a native or compat layout for cmsg" in there. That's the only caller we need it for, but that thing looks cheap enough. Obviously needs to pass testing, including "is it too ugly to live as far as Davem is concerned" test, though...