Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp551731pxk; Wed, 23 Sep 2020 09:42:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyKGNfn40qnc1Gw1Un+id6yVBjO6nkYf8pxjMjdLaqf8iJ5VPzkrt8CwcXxgQ6KYwvUUr6B X-Received: by 2002:a17:906:2619:: with SMTP id h25mr546596ejc.142.1600879333358; Wed, 23 Sep 2020 09:42:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600879333; cv=none; d=google.com; s=arc-20160816; b=otjTAkzZuEy9H8iYK74Ha4SRN38y4u79MRNuh1yVbKpdZhCzZYpJrJmXV+xlrb2712 xfzmahE2TEdUe2IlnaYBVJjgW76VkFxjgbxmYoPsy+//LPqlvq61Tb3ZCxdG4OCnHk7i 7lxmMRVI4YFqdhqk8VQhgskZ2Xpl9sYS30i1RdpqSW01H2Mle3sPXmL/uQdn9YMtdN96 jsivDFzzMF1Aw41x1YelNTsbOi7BPK87gOWXG/n02lqyMFq2+gPAqCTYpZjzYN+hP6Vh BF4pcmByvmex3NlqdSm6RzoZPHU2RoiaXwOKyb7nvu5zyz37lxGNhIK3f8Bp0Hx0Kv6p uoQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=/Prtvy1YJanjMZDygdmUYCqmxpOxXyZhF2vwDs5Hf8Y=; b=wqSTe7U0Htc52JN9WetmM0zNYnRROPwFbWUp0vSH4amembxfUe1IcrMCrwDvhUwFIC 04/QBKoxD++QpTA0c2pcEKhK/ebc7eVrJwhrFkSQKqJ8cZGYfgypoVyiJI1ZndeDPvLq 0UCu/nubL3As1hD0mnd9YUUEHt3VwKSlTzANu0nhvHtAdKqUs4DbPkX9DSfkTaVqCRL7 T1+M2WdYlwF8iOZFKaLiSLE+OWGSY2+BB1YhVd7m6neeHdnUgwhVhNC0VsAeiCS416iD QfodTAPGBBCAiGQl266UG0vv5SPqW+wcUnGz8BTIed/ekzKN1e/Bu8hnTbxlRiajpmNt RoEQ== 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 c12si237210edy.146.2020.09.23.09.41.48; Wed, 23 Sep 2020 09:42:13 -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 S1726748AbgIWQio (ORCPT + 99 others); Wed, 23 Sep 2020 12:38:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53324 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726419AbgIWQin (ORCPT ); Wed, 23 Sep 2020 12:38:43 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C33F6C0613CE; Wed, 23 Sep 2020 09:38:42 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kL7mp-004f4D-Mx; Wed, 23 Sep 2020 16:38:31 +0000 Date: Wed, 23 Sep 2020 17:38:31 +0100 From: Al Viro To: Christoph Hellwig Cc: Andrew Morton , Jens Axboe , Arnd Bergmann , David Howells , David Laight , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, sparclinux@vger.kernel.org, linux-block@vger.kernel.org, linux-scsi@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, io-uring@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org, keyrings@vger.kernel.org, linux-security-module@vger.kernel.org Subject: Re: [PATCH 5/9] fs: remove various compat readv/writev helpers Message-ID: <20200923163831.GO3421308@ZenIV.linux.org.uk> References: <20200923060547.16903-1-hch@lst.de> <20200923060547.16903-6-hch@lst.de> <20200923142549.GK3421308@ZenIV.linux.org.uk> <20200923143251.GA14062@lst.de> <20200923145901.GN3421308@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200923145901.GN3421308@ZenIV.linux.org.uk> Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 23, 2020 at 03:59:01PM +0100, Al Viro wrote: > > That's a very good question. But it does not just compile but actually > > works. Probably because all the syscall wrappers mean that we don't > > actually generate the normal names. I just tried this: > > > > --- a/include/linux/syscalls.h > > +++ b/include/linux/syscalls.h > > @@ -468,7 +468,7 @@ asmlinkage long sys_lseek(unsigned int fd, off_t offset, > > asmlinkage long sys_read(unsigned int fd, char __user *buf, size_t count); > > asmlinkage long sys_write(unsigned int fd, const char __user *buf, > > size_t count); > > -asmlinkage long sys_readv(unsigned long fd, > > +asmlinkage long sys_readv(void *fd, > > > > for fun, and the compiler doesn't care either.. > > Try to build it for sparc or ppc... FWIW, declarations in syscalls.h used to serve 4 purposes: 1) syscall table initializers needed symbols declared 2) direct calls needed the same 3) catching mismatches between the declarations and definitions 4) centralized list of all syscalls (2) has been (thankfully) reduced for some time; in any case, ksys_... is used for the remaining ones. (1) and (3) are served by syscalls.h in architectures other than x86, arm64 and s390. On those 3 (1) is done otherwise (near the syscall table initializer) and (3) is not done at all. I wonder if we should do something like SYSCALL_DECLARE3(readv, unsigned long, fd, const struct iovec __user *, vec, unsigned long, vlen); in syscalls.h instead, and not under that ifdef. Let it expand to declaration of sys_...() in generic case and, on x86, into __do_sys_...() and __ia32_sys_...()/__x64_sys_...(), with types matching what SYSCALL_DEFINE ends up using. Similar macro would cover compat_sys_...() declarations. That would restore mismatch checking for x86 and friends. AFAICS, the cost wouldn't be terribly high - cpp would have more to chew through in syscalls.h, but it shouldn't be all that costly. Famous last words, of course... Does anybody see fundamental problems with that?