From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <viro@ftp.linux.org.uk>
X-Google-Smtp-Source: ACJfBoun5gjLwi6mdfvmQQ9tZUDxb1o7bHdIlw+XfW8JTaEAaDFgLZugBwrr7T/BawFT2oHp5jmL
ARC-Seal: i=1; a=rsa-sha256; t=1516250592; cv=none;
        d=google.com; s=arc-20160816;
        b=y9Yv+EzdKAMQ1FOx6YBeZismscf4f+9bbD5sBh4GhEEIHBqxM+sjswRRN2icbhhZz3
         8QLaJfDfvYJceFlf16QtyOSJ3PlIf+L+GEuSdb2jVq0eVW4oWbCwzDfs3g2YqPtmvv1V
         pBAa1q6KwZluTB/wqw9dd+DPTK4wg5/rCs1hUlQxuC/XCgcAC31ebuKTjmW5Bj16MIRv
         +uzKSk8MOBfLGn3PUw6/JBbNnrXACuXvk7NqHHKzactYVWmkGSfsyZ3LbtrKdl89W98Z
         rZR4NPsUKFQoeE0LEpmbKcKIeAd9boVMz7wdvkxToCoRSMNjEH1MTfqucUFxxt2rgiyU
         83wQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=sender:user-agent:in-reply-to:content-disposition:mime-version
         :references:message-id:subject:cc:to:from:date
         :arc-authentication-results;
        bh=hyCz45jHDTa5hZAd2+ula5eJ+QSe5Sq0/ZwzlzeHBjU=;
        b=iUullyqBeNe4zxYam7X7tGqlf2Xl58h184mIYR+E/1XCSRz/Wvr+n1I3Go4palqYKB
         qVfMQZevzTZOYpXXAo0miCjUVp85u5umpy0oyU2QCRLfJV0IUbclfGSyJ5pTxUHPW2HU
         1qmGRIi9goRbgaewTsjZYjOOk4nbMPmFFzBh3gOQCfKxXwXAeum+LJQgoCccGrtHp4s7
         Jdf1lz89zidg0QYsmlj13qPDQ4mNEKNetCdUPSEUtyIXgHRsq2/kjSR/uejz0LZ9xq9a
         d5Wf+tgYnIZH0HdzWgYHf2dU3kifI1T2PkuY5w4kTwG5nsCzEhlzchcLT50Ac0Ep3vJO
         7uww==
ARC-Authentication-Results: i=1; mx.google.com;
       spf=pass (google.com: best guess record for domain of viro@ftp.linux.org.uk designates 195.92.253.2 as permitted sender) smtp.mailfrom=viro@ftp.linux.org.uk
Authentication-Results: mx.google.com;
       spf=pass (google.com: best guess record for domain of viro@ftp.linux.org.uk designates 195.92.253.2 as permitted sender) smtp.mailfrom=viro@ftp.linux.org.uk
Date: Thu, 18 Jan 2018 04:43:02 +0000
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Network Development <netdev@vger.kernel.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arch@vger.kernel.org, Andi Kleen <ak@linux.intel.com>,
	Kees Cook <keescook@chromium.org>,
	kernel-hardening@lists.openwall.com,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Alan Cox <alan@linux.intel.com>, David Miller <davem@davemloft.net>
Subject: Re: [RFC][PATCH] get rid of the use of set_fs() (by way of
 kernel_recvmsg()) in sunrpc
Message-ID: <20180118044302.GZ13338@ZenIV.linux.org.uk>
References: <151586748981.5820.14559543798744763404.stgit@dwillia2-desk3.amr.corp.intel.com>
 <CA+55aFzoAR+MYX+ub0xZ32OsT7WtD5Kru2t6LhwB1buLWPResQ@mail.gmail.com>
 <CA+55aFxsg5+u7bCHj1N8xyyVf7-RMm-5ACNp=ENNrKL78omaow@mail.gmail.com>
 <CAPcyv4hfUx8gLScuNewY3+BWi4YBS_Z9dhvYf1D+WEWDDCShXA@mail.gmail.com>
 <CA+55aFxAFG5czVmCyhYMyHmXLNJ7pcXxWzusjZvLRh_qTGHj6Q@mail.gmail.com>
 <CA+55aFxB01XEEpdPynwYmzQMfTJdJnUrN+ZLqSV_UdnKLBgAZw@mail.gmail.com>
 <1516198646.4184.13.camel@linux.intel.com>
 <20180117185232.GW13338@ZenIV.linux.org.uk>
 <20180118030634.GY13338@ZenIV.linux.org.uk>
 <CA+55aFzKPed+89wz=ajWNpsQ8Kh+AQWx61hwVqqDh7_=h4tecg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+55aFzKPed+89wz=ajWNpsQ8Kh+AQWx61hwVqqDh7_=h4tecg@mail.gmail.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: Al Viro <viro@ftp.linux.org.uk>
X-getmail-retrieved-from-mailbox: INBOX
X-GMAIL-THRID: =?utf-8?q?1589897919168956864?=
X-GMAIL-MSGID: =?utf-8?q?1589903981407888978?=
X-Mailing-List: linux-kernel@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>

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@zeniv.linux.org.uk> 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...