Received: by 10.223.148.5 with SMTP id 5csp6863311wrq; Wed, 17 Jan 2018 20:43:45 -0800 (PST) X-Google-Smtp-Source: ACJfBou0DzD+ydhAFV7Vbmi30TJKrMSB6uRZIDrEV6PXX0oGiY/EE33YXwgS+fFtu6Qrtp0OBpel X-Received: by 10.107.136.78 with SMTP id k75mr17044201iod.273.1516250625530; Wed, 17 Jan 2018 20:43:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516250625; cv=none; d=google.com; s=arc-20160816; b=fi7zDX0USiWDp1DKc0uZRNoxNFnCP/vKSgxMRGCBg2ooC0gaqZ2NYv9wmquv7ngWqt yyxkVwwW3iJczkU8A7/PApfkoqW3VlxJUpk9F56wtkXOOi2QgmnwFqHVN57OTL2y4rdD u3BtDRPjRGsy+O8UCpWz1LbHwXufuIHouI8e9MpItGFXouMD3tnT/rRXeuEayCtWL00E 9JkTTWFx2k+wueSrJAH7knrCsJglRFwumERh43OD6rQOdZUja7LjEbxBIchqCsPQ/ioK eOxNsMyuKJI+uh+3ZpZNlwptrBS9ecXNC/ps3vHwVbbMSj02h4MfE7+ts5WiJBxQKw98 C6bA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence: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=WJvzGmeCNzmKCP7N24fEhCN+Nz1RqtnCE3RUA4tOdTzMWRsuOo2ToYEyOKPLuRtfwC jcEK01q2QmQH+fYgpmdDNKURufMYff+4rBXGnxbP88xnWEo+Ty5FtFJYiVCSSHAoDojd 77FHqWAb+NjTGeiGmkff9+UQFuMYrp2D7yBySbx80czBm8kDezkoEmijmyRBznoDApb0 hJWZgNCWo32kqsmBX+RH3ChoZrO+nMyptKU2ABntHBwTDESx6intoIG6fzuINeVyel2H uxqkviwk6x9nAxOiRcBi7+R3ArBBaXeFXpIRypqhwalgGXMjQofR2XMXcyRy0d8ZhgJs bnfg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g1si6051461itd.56.2018.01.17.20.43.32; Wed, 17 Jan 2018 20:43:45 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754104AbeAREnJ (ORCPT + 99 others); Wed, 17 Jan 2018 23:43:09 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:33186 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752184AbeAREnH (ORCPT ); Wed, 17 Jan 2018 23:43:07 -0500 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.87 #1 (Red Hat Linux)) id 1ec22Y-0006xl-PX; Thu, 18 Jan 2018 04:43:02 +0000 Date: Thu, 18 Jan 2018 04:43:02 +0000 From: Al Viro To: Linus Torvalds Cc: Network Development , Dan Williams , Linux Kernel Mailing List , linux-arch@vger.kernel.org, Andi Kleen , Kees Cook , kernel-hardening@lists.openwall.com, Greg Kroah-Hartman , the arch/x86 maintainers , Ingo Molnar , "H. Peter Anvin" , Thomas Gleixner , Andrew Morton , Alan Cox , David Miller 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> <1516198646.4184.13.camel@linux.intel.com> <20180117185232.GW13338@ZenIV.linux.org.uk> <20180118030634.GY13338@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: 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 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...