From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3DE31C4727F for ; Wed, 23 Sep 2020 18:46:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id ECA42235FD for ; Wed, 23 Sep 2020 18:46:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726988AbgIWSqO (ORCPT ); Wed, 23 Sep 2020 14:46:14 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:35555 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726665AbgIWSqO (ORCPT ); Wed, 23 Sep 2020 14:46:14 -0400 Received: from mail-qt1-f182.google.com ([209.85.160.182]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.129]) with ESMTPSA (Nemesis) id 1M89P1-1kOi931zbn-005Hlb; Wed, 23 Sep 2020 20:46:10 +0200 Received: by mail-qt1-f182.google.com with SMTP id a4so831862qth.0; Wed, 23 Sep 2020 11:46:09 -0700 (PDT) X-Gm-Message-State: AOAM531B6RKNkGQC/NDN1KVy6L7ZJDh/eTh8x/vyn/fCGays+viehdTH kYMDsdGq5j5wMlrpbikXGrM/muVRkR5VaFZOmUo= X-Google-Smtp-Source: ABdhPJwsvaOBWtaZA0D/OVEHB/gCWu247kr3QZZFrdP10NBc4wqx9Hcp+T5ZYDolhQMYUd20W7JjEkRUKsdbgp0ivyQ= X-Received: by 2002:ac8:64a:: with SMTP id e10mr1527617qth.142.1600886767946; Wed, 23 Sep 2020 11:46:07 -0700 (PDT) MIME-Version: 1.0 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> <20200923163831.GO3421308@ZenIV.linux.org.uk> In-Reply-To: <20200923163831.GO3421308@ZenIV.linux.org.uk> From: Arnd Bergmann Date: Wed, 23 Sep 2020 20:45:51 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 5/9] fs: remove various compat readv/writev helpers To: Al Viro Cc: Christoph Hellwig , Andrew Morton , Jens Axboe , David Howells , David Laight , Linux ARM , "linux-kernel@vger.kernel.org" , "open list:BROADCOM NVRAM DRIVER" , Parisc List , linuxppc-dev , linux-s390 , sparclinux , linux-block , linux-scsi , Linux FS-devel Mailing List , linux-aio , io-uring@vger.kernel.org, linux-arch , Linux-MM , Networking , keyrings@vger.kernel.org, LSM List Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:mMkQRAJUWfdk4a4PEkmTkMjSEPbcbr4OqrN3fUr4LQ2AQqlPl0n bOWryggRLru9T6JJoTMuOGI9kvl/I6BtMLB/VbJVDYLH2lraHpn3UOgXAQiZMVZJ9Wt6/3q dgtI834LPxJGojFQwlbq6VqcE61sUtAzG9Asu4SnN3A1f/GYReptJqFvli47ZUGxJu1McD6 wXqFv/2sZdtXtrzvqb6Gw== X-UI-Out-Filterresults: notjunk:1;V03:K0:ARXrn3BJvHg=:OaZDrHRji4s3F+Z4R525Bn agD8Hjw3INq7irUQDHIrs31n4HiItPG1qRH9sCOQsBDzKfQ2GBPxOe8cQiCUK6etjcRZgS5uz ltu+yxAg8SdJB7S6UrMx8x4gZIRJZNx/h1Pd359G8hRQEWUkB77c3Uu7iX6+oWPogrXiRLcyE Ay+LH2roCsVe74rsugu9p8r/jxgEYoo6ke7HkJiyLsrJx77n+/GWpX9PQTbGXJGYCmPKo03Dx 7rZxQHvz4lzlsQGvZ22Lw1H85lBROKXGp/T1YCWt7CkiGs0Y/R3V3UonSnBX41Bf98v3feicD RYBnkyjEcAUUQRR5u9cw067xVVV2JdvUKInxkNdutFVn0CM66u/fDJxueg1uLRW9RPYp7DjVs Mx/HRUmO0wQonj6taqWhVCgSUthPIg1jpw3qykbSoDJ96MDdaz8DcUt+7qpkA5t/+tGOD+rWW Bn0ajxwLkORS0R61/JXIJExhw4SvyLBTVKDr7LI7QuYFV9tfgKH3fZzLZmBkdPEqiGd2kyAMe 0agELAyDb5Rehyc/3jcYzTGZyQ9nlXuD/YYv4vEmC1CRzjxWF4KIZFY6D3HWoeuUMlzvMCijI ue6FAYnnAerqxzrTow74a1x9I80VfvnWRTz0xYpnoiGRegiq0P5uWv1YSyriRyFortckburp8 xW1/xnziTC/+/JUjrApbsItKfFZpj/Vffo23zPwOLXvOArj8zkutkvZ9h8hGYgo934l9OKJGu P5NJw1LlqSAdgmNcPhTbFVxjnCSs1G9+5tq34fiY8XA66+2tLlwvaAnYp+zv5HOWn5OOwlMar YndfSM38x1BkZ1kFiYikEr51lnNKUep3VIupblSMr1ljcWZWbNW0XzKu+xNzfuUJBnp9WMfFy 7T3ELZ0Iq8IWSMYb0u7TCVmN4B9t5+iKBzUQ+0CqaqKkDuOmWY7NnBHAU/IZ6fceZMEkzvN4O Id5+SP2sVY8Io6R5XqdC6M9inrRybKQ1OIWUL/7Bpv8x4eU8nqVGM Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Wed, Sep 23, 2020 at 6:38 PM Al Viro wrote: > > 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? I've had some ideas along those lines in the past and I think it should work. As a variation of this, the SYSCALL_DEFINEx() macros could go away entirely, leaving only the macro instantiations from the header to require that syntax. It would require first changing the remaining architectures to build the syscall table from C code instead of assembler though. Regardless of that, another advantage of having the SYSCALL_DECLAREx() would be the ability to include that header file from elsewhere with a different macro definition to create a machine-readable version of the interface when combined with the syscall.tbl files. This could be used to create a user space stub for calling into the low-level syscall regardless of the libc interfaces, or for synchronizing the interfaces with strace, qemu-user, or anything that needs to deal with the low-level interface. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Date: Wed, 23 Sep 2020 18:45:51 +0000 Subject: Re: [PATCH 5/9] fs: remove various compat readv/writev helpers Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit List-Id: 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> <20200923163831.GO3421308@ZenIV.linux.org.uk> In-Reply-To: <20200923163831.GO3421308@ZenIV.linux.org.uk> To: Al Viro Cc: Christoph Hellwig , Andrew Morton , Jens Axboe , David Howells , David Laight , Linux ARM , "linux-kernel@vger.kernel.org" , "open list:BROADCOM NVRAM DRIVER" , Parisc List , linuxppc-dev , linux-s390 , sparclinux , linux-block , linux-scsi , Linux FS-devel Mailing List , linux-aio , io-uring@vger.kernel.org, linux-arch , Linux-MM , Networking , keyrings@vger.kernel.org, LSM List On Wed, Sep 23, 2020 at 6:38 PM Al Viro wrote: > > 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? I've had some ideas along those lines in the past and I think it should work. As a variation of this, the SYSCALL_DEFINEx() macros could go away entirely, leaving only the macro instantiations from the header to require that syntax. It would require first changing the remaining architectures to build the syscall table from C code instead of assembler though. Regardless of that, another advantage of having the SYSCALL_DECLAREx() would be the ability to include that header file from elsewhere with a different macro definition to create a machine-readable version of the interface when combined with the syscall.tbl files. This could be used to create a user space stub for calling into the low-level syscall regardless of the libc interfaces, or for synchronizing the interfaces with strace, qemu-user, or anything that needs to deal with the low-level interface. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C7E83C2D0A8 for ; Wed, 23 Sep 2020 18:46:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 150D3235FD for ; Wed, 23 Sep 2020 18:46:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 150D3235FD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 25C156B0003; Wed, 23 Sep 2020 14:46:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 20C106B005A; Wed, 23 Sep 2020 14:46:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0AD126B0037; Wed, 23 Sep 2020 14:46:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0216.hostedemail.com [216.40.44.216]) by kanga.kvack.org (Postfix) with ESMTP id DC7CC6B005A for ; Wed, 23 Sep 2020 14:46:12 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 97C252490 for ; Wed, 23 Sep 2020 18:46:12 +0000 (UTC) X-FDA: 77295206184.18.prose41_42021bc27158 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin18.hostedemail.com (Postfix) with ESMTP id 3BB83100DD3CD; Wed, 23 Sep 2020 18:46:12 +0000 (UTC) X-HE-Tag: prose41_42021bc27158 X-Filterd-Recvd-Size: 5554 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) by imf47.hostedemail.com (Postfix) with ESMTP; Wed, 23 Sep 2020 18:46:11 +0000 (UTC) Received: from mail-qt1-f175.google.com ([209.85.160.175]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.129]) with ESMTPSA (Nemesis) id 1M3mHT-1kKKQs2NJT-000vkq; Wed, 23 Sep 2020 20:46:09 +0200 Received: by mail-qt1-f175.google.com with SMTP id c18so801005qtw.5; Wed, 23 Sep 2020 11:46:08 -0700 (PDT) X-Gm-Message-State: AOAM530flGmYepUFz7YKNZRKSYGPsMJMDAus6RDgd3luKjfxj3gWaMH1 MLmdOfVNbQtrwDVM+O05wg+YH0IizfRjz2hTrYc= X-Google-Smtp-Source: ABdhPJwsvaOBWtaZA0D/OVEHB/gCWu247kr3QZZFrdP10NBc4wqx9Hcp+T5ZYDolhQMYUd20W7JjEkRUKsdbgp0ivyQ= X-Received: by 2002:ac8:64a:: with SMTP id e10mr1527617qth.142.1600886767946; Wed, 23 Sep 2020 11:46:07 -0700 (PDT) MIME-Version: 1.0 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> <20200923163831.GO3421308@ZenIV.linux.org.uk> In-Reply-To: <20200923163831.GO3421308@ZenIV.linux.org.uk> From: Arnd Bergmann Date: Wed, 23 Sep 2020 20:45:51 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 5/9] fs: remove various compat readv/writev helpers To: Al Viro Cc: Christoph Hellwig , Andrew Morton , Jens Axboe , David Howells , David Laight , Linux ARM , "linux-kernel@vger.kernel.org" , "open list:BROADCOM NVRAM DRIVER" , Parisc List , linuxppc-dev , linux-s390 , sparclinux , linux-block , linux-scsi , Linux FS-devel Mailing List , linux-aio , io-uring@vger.kernel.org, linux-arch , Linux-MM , Networking , keyrings@vger.kernel.org, LSM List Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:EFNboF17l3L0uCn1GZT6ThmsGE9Gp0x1dAE7WSSodZjOhn6s+Ug LfKP5zMsh9hpy9BWtnxfq+w3QZgo+HJol+jI4yjLcncJTbu5wmJTcfgxepfyzPJzF0DTWgX 41JJOPAbZWGZV36OazevPvHBrfY8x5IUnIDWQbWL2hxhV+lOe14c8SS0wK0CS0jWz84EYPK qOG7tiEfdhwm2/Im1veow== X-UI-Out-Filterresults: notjunk:1;V03:K0:mkco/ONsERs=:CtgLnM90jRLIGQYC5IVGe1 1WgMgtNPcC1SSZDqHqWQh7SlPqQFCnVWtFAXYwRMfUgT9PoH0CdmoL16K+AKDorv9ubBrq29B cNV0vyaTWPWFtaGyybAD8D9NG7mDJNrt2gRWuxrM1u8WJNFUgIsWXFJHWHJBOWSSDl5uqitBo Z/kdk/HzbR/I0vOipbm8os41DjT2+zR8FIr1t+2we41U+M0thmDmLxX+iUdCHLnQ0I6sCQGPs qST5sKYvIGDC+sYfsB6pwXDKEK5pBfPE5tfMZj1on+ts6THQ+kbXpUfjsIIWLjCDqMzRe20yB k33vNyyBQz8vUxqfJkqRIQVbTQt1fLs96mj7P67FuAbYtZc3KOeBZLGJ+ayI8HnQpN3F0YJ2/ wNx7TicslmXT8OoRRXw97msfSVHZ4Ffp7BIV+VEhxCXqpgNbD5fAXaGZabsAy/W52bo2ZInkN +pOjlebzeYf14jFPN1O4CBzZ//yzFUgB1aSklQq1GHHlPADiBrnBiiOQPR11ZLlVukYTagssz 5RTZ6/ojT/2LqYsE7QPkBdTK2RoMJooaiHdfH8HqlnvxPWx71++X1WmE3hWMh+D6k6miyIVc4 GSq7FKVaP+f4CYJVJOHOJuV8rBgUJbJiNHnWoTuZCutnuu2tu3F1Y4IE0SvBhHg18CGsUkMx2 OB91ta8ZSMUjoot0e5W9L0FI8m2aJ7VOWfW5Wm+4WXGRr+gjy60+FRt4X/mhjXw0bheD/5Qse nyhXSWSWMVpMfUiSezij+huJSMhiat2fF8CoPrnz5dMDvI3pjP8pyOEzokm34xDbrXCaxjF90 txDHMDv7OSGEoM2TrEvLGYYV5PDNm9Wd80ZMky+wmPDI58IoHjgPNbyYuFwILRSxdZNaknv X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Sep 23, 2020 at 6:38 PM Al Viro wrote: > > 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? I've had some ideas along those lines in the past and I think it should work. As a variation of this, the SYSCALL_DEFINEx() macros could go away entirely, leaving only the macro instantiations from the header to require that syntax. It would require first changing the remaining architectures to build the syscall table from C code instead of assembler though. Regardless of that, another advantage of having the SYSCALL_DECLAREx() would be the ability to include that header file from elsewhere with a different macro definition to create a machine-readable version of the interface when combined with the syscall.tbl files. This could be used to create a user space stub for calling into the low-level syscall regardless of the libc interfaces, or for synchronizing the interfaces with strace, qemu-user, or anything that needs to deal with the low-level interface. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 62F02C2D0A8 for ; Wed, 23 Sep 2020 18:48:06 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6DCC8206DB for ; Wed, 23 Sep 2020 18:48:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6DCC8206DB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4BxRyB3p9xzDqMl for ; Thu, 24 Sep 2020 04:48:02 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=arndb.de (client-ip=212.227.17.10; helo=mout.kundenserver.de; envelope-from=arnd@arndb.de; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=arndb.de X-Greylist: delayed 121458 seconds by postgrey-1.36 at bilbo; Thu, 24 Sep 2020 04:46:17 AEST Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4BxRw93Rq8zDqGg for ; Thu, 24 Sep 2020 04:46:15 +1000 (AEST) Received: from mail-qt1-f178.google.com ([209.85.160.178]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.145]) with ESMTPSA (Nemesis) id 1N1xdf-1kRSBP0TtZ-012Cwc for ; Wed, 23 Sep 2020 20:46:10 +0200 Received: by mail-qt1-f178.google.com with SMTP id 19so826165qtp.1 for ; Wed, 23 Sep 2020 11:46:08 -0700 (PDT) X-Gm-Message-State: AOAM533/+dLYQRhPdzbpOA1gDkD76ogt3CZdVQoh8Vv5L9VqWD4bbvaI PpFJ6x4wV7wyiHEqHmZgDen/HNMCef3N619Xl5I= X-Google-Smtp-Source: ABdhPJwsvaOBWtaZA0D/OVEHB/gCWu247kr3QZZFrdP10NBc4wqx9Hcp+T5ZYDolhQMYUd20W7JjEkRUKsdbgp0ivyQ= X-Received: by 2002:ac8:64a:: with SMTP id e10mr1527617qth.142.1600886767946; Wed, 23 Sep 2020 11:46:07 -0700 (PDT) MIME-Version: 1.0 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> <20200923163831.GO3421308@ZenIV.linux.org.uk> In-Reply-To: <20200923163831.GO3421308@ZenIV.linux.org.uk> From: Arnd Bergmann Date: Wed, 23 Sep 2020 20:45:51 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 5/9] fs: remove various compat readv/writev helpers To: Al Viro Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:xh0linslMPKiIKRuIaKjDJUt6Gm3SobvWFfqLQfb5f6ex5/fnKw E1m+6Mvmlrr8BC3Sf+lmzTo61eSFvv0CK45LHYSB3fTzxm21+MGZZMcMljvmBwRegDVzlpB D4la0zaezTtHN44hgF1x5RUuD3IkFyFsnO1R+1HZxy+RpiU0q0fxNxIKlCMAe0oKukg9sMG qgWPDO9/6hKWIXCk7IxoA== X-UI-Out-Filterresults: notjunk:1;V03:K0:gCeoXWWCXmw=:2U3WQbHBie0/QbWFJBfzMd 5joEh4+syZZBAodwRN4qz+cH4zElo+kTahKHbSNxDxFs3HigVXaLvtiYDp77r8BchDW4AEvhg yqyuoNXSJheUbLO7anFnHATQjtRGUfv+PRSayfilxb3gcAD6kSVPE5VhVAoIrp/n6KYbIM4Qt QCIydNy0fjVDARlrDzfUF1PhNueK0eC7tVjRPTGfKl3uCu5lQBzV+6RtHHkJFSXp9t1OwMr9S sPKs9KWssBR0ySfnDBEtsSx22l68hXte58hy82dgRTJ+GnZm77vsvL1EDp5xdlyMol3XzOIMp 5m1N2QkVvJjIzGZxq2fLESt57zDkxUjv3xDqhXad1yxAC/QQlGURvKP6dBFZQRAXkMPtkPj0c qcgz7v1y2opqSpKxDfL6n5V1X+W9Le/v9qHuuoVOt7uJVgmpFE9Bw6qgZCz0Ou/Gj3Ct1SVVE J/ZxYIWrLxkh5daxB2l/4LtMtcXtIHEoeMKyFJ8rAr/yaGeL+BCW5mzyzOzSz3bEhdp0DYo++ wRbUCo7DX7EB0kRZbMB2wKz6AuqMQh4VyXC6lBrOTGVZewzmAaQjXfRAhjP4qMv12t2vvWJDi nBBkqEpXoQzXsKgiHcEfEv/VKBXcvjc/NyGJQhnxoqsyX2boaMtQALwfRTqOOeta5YmCZ1rCa Gd6khAHpK5cQ6P5e0k5ee8iEJpKP/p8U7iEgl08+IrdgJW81kWQ4elKfO9ydlB9g0l8I+/PyY WnP92fq6SSy592JpSJ7fJ2XqBMTn7D4XXwtZPttMnkfwoxbAdkUvYmUPNrmLK5XueKSRYFt6Z 9e7GapX2XWse6MCAhl9pz7SDjCmPmBZRwR6I9OUz92dxQ6LXqF0HEOhp+MS1ReTu1UNqvT4 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-aio , "open list:BROADCOM NVRAM DRIVER" , David Howells , Linux-MM , keyrings@vger.kernel.org, sparclinux , Christoph Hellwig , linux-arch , linux-s390 , linux-scsi , linux-block , io-uring@vger.kernel.org, Linux ARM , Jens Axboe , Parisc List , Networking , "linux-kernel@vger.kernel.org" , LSM List , David Laight , Linux FS-devel Mailing List , Andrew Morton , linuxppc-dev Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Wed, Sep 23, 2020 at 6:38 PM Al Viro wrote: > > 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? I've had some ideas along those lines in the past and I think it should work. As a variation of this, the SYSCALL_DEFINEx() macros could go away entirely, leaving only the macro instantiations from the header to require that syntax. It would require first changing the remaining architectures to build the syscall table from C code instead of assembler though. Regardless of that, another advantage of having the SYSCALL_DECLAREx() would be the ability to include that header file from elsewhere with a different macro definition to create a machine-readable version of the interface when combined with the syscall.tbl files. This could be used to create a user space stub for calling into the low-level syscall regardless of the libc interfaces, or for synchronizing the interfaces with strace, qemu-user, or anything that needs to deal with the low-level interface. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34210C4727F for ; Wed, 23 Sep 2020 18:47:59 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C309E20637 for ; Wed, 23 Sep 2020 18:47:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="XTotku3C" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C309E20637 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=SyhxSEWwBz/JJyRs/j5gPMbK56VxOBkL9K8pcFQuvFY=; b=XTotku3CXz4FUh227d6a9WN0j Db9vlrk3P16bFWDXZjT358W61xjx0XPCwuTQOUwrQyoJ9+vki2dcD0Ryn9/mEO0bUv+EZX9whjq7V MMAkmgbH+X5axQdfSwWhDX3JYnrFIRL6R5kJUtupri0iVJ9yDs1vyAvSPv/D8dKqlR+7dWKHtlaDl 7eR/nyDwLEbrDu0soTCoVpiFf883bPNajKq1Mx3q/4eVoGWYjJP5/ntsLZbRbcEb/oWkFGIv5WICA gDYZonsIk/kWV/iYEflSROUrspt5x+VBgT5xTzc2ToeVwC3o9cEAf3h8EJgxu2gnWZ69jbF68Xg6D vfA3b4VDw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kL9mb-0003FU-0D; Wed, 23 Sep 2020 18:46:25 +0000 Received: from mout.kundenserver.de ([212.227.126.134]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kL9mY-0003F6-EK for linux-arm-kernel@lists.infradead.org; Wed, 23 Sep 2020 18:46:23 +0000 Received: from mail-qt1-f177.google.com ([209.85.160.177]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.129]) with ESMTPSA (Nemesis) id 1Mvs2R-1kcxBP0t3n-00syhb for ; Wed, 23 Sep 2020 20:46:16 +0200 Received: by mail-qt1-f177.google.com with SMTP id g3so769470qtq.10 for ; Wed, 23 Sep 2020 11:46:09 -0700 (PDT) X-Gm-Message-State: AOAM5317jzlUAaqjAAR5fcJT64Pmul1ZcriiOqJt7EmRVwHGDFSx0UHI 4InzyiL8pw4yasCFu5ckm9TaO0I65nlifSYabVI= X-Google-Smtp-Source: ABdhPJwsvaOBWtaZA0D/OVEHB/gCWu247kr3QZZFrdP10NBc4wqx9Hcp+T5ZYDolhQMYUd20W7JjEkRUKsdbgp0ivyQ= X-Received: by 2002:ac8:64a:: with SMTP id e10mr1527617qth.142.1600886767946; Wed, 23 Sep 2020 11:46:07 -0700 (PDT) MIME-Version: 1.0 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> <20200923163831.GO3421308@ZenIV.linux.org.uk> In-Reply-To: <20200923163831.GO3421308@ZenIV.linux.org.uk> From: Arnd Bergmann Date: Wed, 23 Sep 2020 20:45:51 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 5/9] fs: remove various compat readv/writev helpers To: Al Viro X-Provags-ID: V03:K1:EDkMpf/9S5M4VEBOmyAipIClHjzi8UFL7qAvothjmYmtbzO+ABM oH3spNi5zm+aZmIGM0tyaoW0P5rv/BwFN9vASZBKHRjTM9bjusrTkQubvIEWgYm45vj2JPv aX7NHAlBCXH6hHVk4HxJcQqBI/MX35hsA+3gHn0tDa+5Eq46/hO2TPzHOHQ8x6HmbhItIPO lrL0kuFIVKT0hnvd6BLjQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:IhKKXbuijVE=:ItXhCy1eWibsota5v5rah1 RFbFS3Cotcj3nxC1ntLRlysnNAAkKNbj1mIUEAgOMQTjtEQ5p76IueCNOiLAnsjdd6zM6S+TM n20MTfKpQwREew1bkGGi1JnGHLOwHVN/6cBI9yHiIzpZA4Y+v+TA11JftqQ0Tg5rRCQGnUtDi bMwf3gTu1NBOwzSPyQf2fhwTj1D2FH4vJKizq3taQzaNYVbdqZ+cHeVn9C5DTd1C9H13XprSQ 3K+4sm9g6Mk3o6i4euYQPJnf6sQG/rRJp73ogknUGhSL6hScGTo+ozVHc1zVK4moXW3zHYCDC Fbr+USWC9g/WtTwvrd7cdIFgY/a7ZQmUI75MPdLPtgn9Vbc9ho3jymLYzqHDTbVHGzkRoUk0w O5CvHcEj7fyFvU3UoqXFH7E8B0j13rkZM+/LN2/Eb4Z5DI7YVpExWR1bFkSSG0tbZy+x1rU5/ vfgLh3uPYoj0u1kqAHIupzt99LX28+KBcbtcrgtVhMUcPm5cvjstPqgTIa0fp1EA+VL4qYiQ/ X4d2BTcZLMeHMXtmc7XvZr8kBnann8fFaCwf7UjREZoa9KcGr5Jx2N1mgjFXhGrkQbgtC89FD 54mnI844xfiA8LZa7EAwN4DIgPo8wLxgk/bRqGyby1nuGZl2LWEw8uQovLhiu8v0Ze0R+JVu3 QQGTBCs402Kjgvc46f54I5wdrw6ZYmuAidO4i6B2/k1x1Te+Vc6GYDrZG9ExPlmeeGWaChYPI Ea86AXjvFOCu5TqBrH82I74ktrZY9xFYV4HvEXUk/B5xVE7/g/iMZWOf64XRAMyKUC95l+8Ym lBHxjY+dptRgxtHDEobVqUSnpFSVtTlbvYfRaQoQW/Ow3m62VKq5xErMyGUh44Y9gtB3CIIJ1 aY06M3QQHa+gte3snYw7CyDNDAQjzkAJePse02b63+WXJyV2A3k50PulDyRKFs8S5gilPCu7/ 1AY/qCKUd3yQQbRlu5f+6jlqxXG3OE10ZR1Z3D9XNlZWNywDmYr1I X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200923_144622_705604_C0BAA00D X-CRM114-Status: GOOD ( 21.72 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-aio , "open list:BROADCOM NVRAM DRIVER" , David Howells , Linux-MM , keyrings@vger.kernel.org, sparclinux , Christoph Hellwig , linux-arch , linux-s390 , linux-scsi , linux-block , io-uring@vger.kernel.org, Linux ARM , Jens Axboe , Parisc List , Networking , "linux-kernel@vger.kernel.org" , LSM List , David Laight , Linux FS-devel Mailing List , Andrew Morton , linuxppc-dev Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Sep 23, 2020 at 6:38 PM Al Viro wrote: > > 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? I've had some ideas along those lines in the past and I think it should work. As a variation of this, the SYSCALL_DEFINEx() macros could go away entirely, leaving only the macro instantiations from the header to require that syntax. It would require first changing the remaining architectures to build the syscall table from C code instead of assembler though. Regardless of that, another advantage of having the SYSCALL_DECLAREx() would be the ability to include that header file from elsewhere with a different macro definition to create a machine-readable version of the interface when combined with the syscall.tbl files. This could be used to create a user space stub for calling into the low-level syscall regardless of the libc interfaces, or for synchronizing the interfaces with strace, qemu-user, or anything that needs to deal with the low-level interface. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel