Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2431776ybz; Sun, 19 Apr 2020 01:10:34 -0700 (PDT) X-Google-Smtp-Source: APiQypJzdq2RtfxMdsX0W3EtbMZmBuwdJHfgcyikgFlBctJVoHokTa+b8LwR41Z898ZGYUo7rbHA X-Received: by 2002:a17:906:4a94:: with SMTP id x20mr10925106eju.306.1587283834095; Sun, 19 Apr 2020 01:10:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587283834; cv=none; d=google.com; s=arc-20160816; b=sjv62zn4DWd1HbBO32grCJ8OWNFBi2uHiTS509KcJo9QgqU8A7gaLWRJu9+WG7sy8k MzrG2rmgPHmQ97rPY2QjCJm9s1UgNMX2X/zhfw5PQEwKKTITuhJJ/PZXMHypAzL2N2zi 0BWeWXc1B/J/bNAaho/jjZoaZMxNDU7/QhXPeT6MpccGVqajp1/zONVJH31+zFiz108n SzWpNK/2Ceg+OZxKYMuaaNZaJix8DNo8OfTSIv5b1ZzezTfP31jqXrBPRv1imMHit7en zrs94Q59X7vw8CpfKQ6a85Wz+1s7XTmC3q8sZ88m3jZL9BeL8jhl0/cMjwk91pW2lpSp qJ2g== 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-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=YzQ1gTl9h1+KbhdDyCsbTlXYOukFyW5Tj25R37gZkwA=; b=qdUyCc+3jXmIX/PZeaNzpmqsAriIJHYk267+2iPqx2ZH6NOALg6A1I5GfJzpAx5bmp zuZuX+zv9QIE5pUQAYyFUovoQC2nxqsAWvS1D4w9XWvd9bHI/VxkE1DP2AtpEuzfQpve 7CnZJo24OKV5MWZjG7Ioou+tHeyayWU4rEhBdVMhGFwN5o8h4Jj+xn2mAWDYgCcxXU5l 7hnpUWti84sq5sAKELOC9NvNx34OFMGodfbagPvBLvvGPSMNh1uUaiBdrr+vILUsoDPb PYtFu17jqnpatWsL34C/32EFqZS+zc7WIvzWrjcMTP8fAbHn4Uncb/Xe4RWxJYl47VpO 47Jg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c3si17869418ejr.333.2020.04.19.01.10.09; Sun, 19 Apr 2020 01:10:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725950AbgDSIGs (ORCPT + 99 others); Sun, 19 Apr 2020 04:06:48 -0400 Received: from verein.lst.de ([213.95.11.211]:35721 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725903AbgDSIGs (ORCPT ); Sun, 19 Apr 2020 04:06:48 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 820AB68BEB; Sun, 19 Apr 2020 10:06:46 +0200 (CEST) Date: Sun, 19 Apr 2020 10:06:46 +0200 From: Christoph Hellwig To: Christophe Leroy Cc: Christoph Hellwig , Andrew Morton , Alexander Viro , Arnd Bergmann , linux-kernel@vger.kernel.org, Jeremy Kerr , linux-fsdevel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, "Eric W . Biederman" Subject: Re: [PATCH 8/8] exec: open code copy_string_kernel Message-ID: <20200419080646.GE12222@lst.de> References: <20200414070142.288696-1-hch@lst.de> <20200414070142.288696-9-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Apr 18, 2020 at 10:15:42AM +0200, Christophe Leroy wrote: > > > Le 14/04/2020 ? 09:01, Christoph Hellwig a ?crit?: >> Currently copy_string_kernel is just a wrapper around copy_strings that >> simplifies the calling conventions and uses set_fs to allow passing a >> kernel pointer. But due to the fact the we only need to handle a single >> kernel argument pointer, the logic can be sigificantly simplified while >> getting rid of the set_fs. > > > Instead of duplicating almost identical code, can you write a function that > takes whether the source is from user or from kernel, then you just do > things like: > > if (from_user) > len = strnlen_user(str, MAX_ARG_STRLEN); > else > len = strnlen(str, MAX_ARG_STRLEN); > > > if (from_user) > copy_from_user(kaddr+offset, str, bytes_to_copy); > else > memcpy(kaddr+offset, str, bytes_to_copy); We'll need two different str variables then with and without __user annotations to keep type safety. And introduce a branch-y and unreadable mess in the exec fast path instead of adding a simple and well understood function for the kernel case that just deals with the much simpler case of just copying a single arg vector from a kernel address.