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.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 9AD32C43465 for ; Sun, 20 Sep 2020 17:00:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 66C0A20EDD for ; Sun, 20 Sep 2020 17:00:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600621200; bh=x0CbGoy7QDKeuRiDyZ0r+bpumnscmCVOPI/85NlktW8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=BoQojCViKQOhq9dsz8Xi7yofkrroyfVtFcjbhYU06KGnKDDR80O95fN18KlNwDQzL aDQLaLbhQnqPUsNucgSVZodKwD9K63Mn4P+iCuQlEv87aBHZ54ojZL6ftFqV99QlXE bYhwEQYaUpnntOjJnwpam67l0xUOGAqhiZljVLgY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726460AbgITQ7v (ORCPT ); Sun, 20 Sep 2020 12:59:51 -0400 Received: from mail.kernel.org ([198.145.29.99]:48310 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726440AbgITQ7u (ORCPT ); Sun, 20 Sep 2020 12:59:50 -0400 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1725D23119 for ; Sun, 20 Sep 2020 16:59:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600621190; bh=x0CbGoy7QDKeuRiDyZ0r+bpumnscmCVOPI/85NlktW8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=gJKTktW4SZM9Nk5DOVt1OrRoD5xvcMTHGvsORGcnvvYrrRwkT7FctEN7F9OgfkMkf go8qh4j37RWcESJvMJRLehEaF3oKhwPYJJdJDts/+toGi7k1LIglAiuuVrdC6I4+Xp /LzZmxNyVgp/8l8nI8i/3m9FhkW6jCz/eC4EQY4Q= Received: by mail-wm1-f53.google.com with SMTP id b79so10223888wmb.4 for ; Sun, 20 Sep 2020 09:59:50 -0700 (PDT) X-Gm-Message-State: AOAM531ZBdw/HrktA/PF77fNs+kw/HWOVEXO/QxjTdwtes2B3c80pZyu ALHRRxC8oSrOZ4p2aTJgBkPzYRNIRxuloC+2e4P6Fg== X-Google-Smtp-Source: ABdhPJwqhOCovrDdCcRZECZNQYs8Sx/d9wwPnQKSY4d4VjHeXmP8XzKxWrTfmcwJ7rQVtp7oa0fbaMUpJAjukisl/1Y= X-Received: by 2002:a1c:7e15:: with SMTP id z21mr25730921wmc.21.1600621188572; Sun, 20 Sep 2020 09:59:48 -0700 (PDT) MIME-Version: 1.0 References: <20200919224122.GJ3421308@ZenIV.linux.org.uk> <36CF3DE7-7B4B-41FD-9818-FDF8A5B440FB@amacapital.net> <20200919232411.GK3421308@ZenIV.linux.org.uk> <20200920025745.GL3421308@ZenIV.linux.org.uk> In-Reply-To: <20200920025745.GL3421308@ZenIV.linux.org.uk> From: Andy Lutomirski Date: Sun, 20 Sep 2020 09:59:36 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag To: Al Viro Cc: Andy Lutomirski , Christoph Hellwig , Andrew Morton , Jens Axboe , Arnd Bergmann , David Howells , linux-arm-kernel , X86 ML , LKML , "open list:MIPS" , Parisc List , linuxppc-dev , linux-s390 , sparclinux , linux-block , Linux SCSI List , Linux FS Devel , linux-aio , io-uring@vger.kernel.org, linux-arch , Linux-MM , Network Development , keyrings@vger.kernel.org, LSM List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Sat, Sep 19, 2020 at 7:57 PM Al Viro wrote: > > On Sat, Sep 19, 2020 at 05:14:41PM -0700, Andy Lutomirski wrote: > > > > 2) have you counted the syscalls that do and do not need that? > > > > No. > > Might be illuminating... > > > > 3) how many of those realistically *can* be unified with their > > > compat counterparts? [hint: ioctl(2) cannot] > > > > There would be no requirement to unify anything. The idea is that > > we'd get rid of all the global state flags. > > _What_ global state flags? When you have separate SYSCALL_DEFINE3(ioctl...) > and COMPAT_SYSCALL_DEFINE3(ioctl...), there's no flags at all, global or > local. They only come into the play when you try to share the same function > for both, right on the top level. ... > > > For ioctl, we'd have a new file_operation: > > > > long ioctl(struct file *, unsigned int, unsigned long, enum syscall_arch); > > > > I'm not saying this is easy, but I think it's possible and the result > > would be more obviously correct than what we have now. > > No, it would not. Seriously, from time to time a bit of RTFS before grand > proposals turns out to be useful. As one example, look at __sys_setsockopt(). It's called for the native and compat versions, and it contains an in_compat_syscall() check. (This particularly check looks dubious to me, but that's another story.) If this were to be done with equivalent semantics without a separate COMPAT_DEFINE_SYSCALL and without in_compat_syscall(), there would need to be some indication as to whether this is compat or native setsockopt. There are other setsockopt implementations in the net stack with more legitimate-seeming uses of in_compat_syscall() that would need some other mechanism if in_compat_syscall() were to go away. setsockopt is (I hope!) out of scope for io_uring, but the situation isn't fundamentally different from read and write. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Date: Sun, 20 Sep 2020 16:59:36 +0000 Subject: Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit List-Id: References: <20200919224122.GJ3421308@ZenIV.linux.org.uk> <36CF3DE7-7B4B-41FD-9818-FDF8A5B440FB@amacapital.net> <20200919232411.GK3421308@ZenIV.linux.org.uk> <20200920025745.GL3421308@ZenIV.linux.org.uk> In-Reply-To: <20200920025745.GL3421308@ZenIV.linux.org.uk> To: Al Viro Cc: Andy Lutomirski , Christoph Hellwig , Andrew Morton , Jens Axboe , Arnd Bergmann , David Howells , linux-arm-kernel , X86 ML , LKML , "open list:MIPS" , Parisc List , linuxppc-dev , linux-s390 , sparclinux , linux-block , Linux SCSI List , Linux FS Devel , linux-aio , io-uring@vger.kernel.org, linux-arch , Linux-MM , Network Development , keyrings@vger.kernel.org, LSM List On Sat, Sep 19, 2020 at 7:57 PM Al Viro wrote: > > On Sat, Sep 19, 2020 at 05:14:41PM -0700, Andy Lutomirski wrote: > > > > 2) have you counted the syscalls that do and do not need that? > > > > No. > > Might be illuminating... > > > > 3) how many of those realistically *can* be unified with their > > > compat counterparts? [hint: ioctl(2) cannot] > > > > There would be no requirement to unify anything. The idea is that > > we'd get rid of all the global state flags. > > _What_ global state flags? When you have separate SYSCALL_DEFINE3(ioctl...) > and COMPAT_SYSCALL_DEFINE3(ioctl...), there's no flags at all, global or > local. They only come into the play when you try to share the same function > for both, right on the top level. ... > > > For ioctl, we'd have a new file_operation: > > > > long ioctl(struct file *, unsigned int, unsigned long, enum syscall_arch); > > > > I'm not saying this is easy, but I think it's possible and the result > > would be more obviously correct than what we have now. > > No, it would not. Seriously, from time to time a bit of RTFS before grand > proposals turns out to be useful. As one example, look at __sys_setsockopt(). It's called for the native and compat versions, and it contains an in_compat_syscall() check. (This particularly check looks dubious to me, but that's another story.) If this were to be done with equivalent semantics without a separate COMPAT_DEFINE_SYSCALL and without in_compat_syscall(), there would need to be some indication as to whether this is compat or native setsockopt. There are other setsockopt implementations in the net stack with more legitimate-seeming uses of in_compat_syscall() that would need some other mechanism if in_compat_syscall() were to go away. setsockopt is (I hope!) out of scope for io_uring, but the situation isn't fundamentally different from read and write. 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.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 2D559C43469 for ; Sun, 20 Sep 2020 16:59:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A1B16235FA for ; Sun, 20 Sep 2020 16:59:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="gJKTktW4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A1B16235FA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CAFA5900006; Sun, 20 Sep 2020 12:59:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C5F0D900003; Sun, 20 Sep 2020 12:59:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B7424900006; Sun, 20 Sep 2020 12:59:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0221.hostedemail.com [216.40.44.221]) by kanga.kvack.org (Postfix) with ESMTP id A457F900003 for ; Sun, 20 Sep 2020 12:59:52 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 631A88249980 for ; Sun, 20 Sep 2020 16:59:52 +0000 (UTC) X-FDA: 77284051824.29.sort05_330a1ec2713e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin29.hostedemail.com (Postfix) with ESMTP id 4012418086CD4 for ; Sun, 20 Sep 2020 16:59:52 +0000 (UTC) X-HE-Tag: sort05_330a1ec2713e X-Filterd-Recvd-Size: 5079 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Sun, 20 Sep 2020 16:59:51 +0000 (UTC) Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9C1BA23787 for ; Sun, 20 Sep 2020 16:59:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600621190; bh=x0CbGoy7QDKeuRiDyZ0r+bpumnscmCVOPI/85NlktW8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=gJKTktW4SZM9Nk5DOVt1OrRoD5xvcMTHGvsORGcnvvYrrRwkT7FctEN7F9OgfkMkf go8qh4j37RWcESJvMJRLehEaF3oKhwPYJJdJDts/+toGi7k1LIglAiuuVrdC6I4+Xp /LzZmxNyVgp/8l8nI8i/3m9FhkW6jCz/eC4EQY4Q= Received: by mail-wm1-f47.google.com with SMTP id a9so10248875wmm.2 for ; Sun, 20 Sep 2020 09:59:50 -0700 (PDT) X-Gm-Message-State: AOAM531PkERv2Td5LeZmPWDm20r2C6T6jv2Z5KCdTeE0Q5o2TE7Dce0D 3yARZZYkoOoV2fSqyxd82H96TPpzmRfKw78yQ+p4yQ== X-Google-Smtp-Source: ABdhPJwqhOCovrDdCcRZECZNQYs8Sx/d9wwPnQKSY4d4VjHeXmP8XzKxWrTfmcwJ7rQVtp7oa0fbaMUpJAjukisl/1Y= X-Received: by 2002:a1c:7e15:: with SMTP id z21mr25730921wmc.21.1600621188572; Sun, 20 Sep 2020 09:59:48 -0700 (PDT) MIME-Version: 1.0 References: <20200919224122.GJ3421308@ZenIV.linux.org.uk> <36CF3DE7-7B4B-41FD-9818-FDF8A5B440FB@amacapital.net> <20200919232411.GK3421308@ZenIV.linux.org.uk> <20200920025745.GL3421308@ZenIV.linux.org.uk> In-Reply-To: <20200920025745.GL3421308@ZenIV.linux.org.uk> From: Andy Lutomirski Date: Sun, 20 Sep 2020 09:59:36 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag To: Al Viro Cc: Andy Lutomirski , Christoph Hellwig , Andrew Morton , Jens Axboe , Arnd Bergmann , David Howells , linux-arm-kernel , X86 ML , LKML , "open list:MIPS" , Parisc List , linuxppc-dev , linux-s390 , sparclinux , linux-block , Linux SCSI List , Linux FS Devel , linux-aio , io-uring@vger.kernel.org, linux-arch , Linux-MM , Network Development , keyrings@vger.kernel.org, LSM List Content-Type: text/plain; charset="UTF-8" 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 Sat, Sep 19, 2020 at 7:57 PM Al Viro wrote: > > On Sat, Sep 19, 2020 at 05:14:41PM -0700, Andy Lutomirski wrote: > > > > 2) have you counted the syscalls that do and do not need that? > > > > No. > > Might be illuminating... > > > > 3) how many of those realistically *can* be unified with their > > > compat counterparts? [hint: ioctl(2) cannot] > > > > There would be no requirement to unify anything. The idea is that > > we'd get rid of all the global state flags. > > _What_ global state flags? When you have separate SYSCALL_DEFINE3(ioctl...) > and COMPAT_SYSCALL_DEFINE3(ioctl...), there's no flags at all, global or > local. They only come into the play when you try to share the same function > for both, right on the top level. ... > > > For ioctl, we'd have a new file_operation: > > > > long ioctl(struct file *, unsigned int, unsigned long, enum syscall_arch); > > > > I'm not saying this is easy, but I think it's possible and the result > > would be more obviously correct than what we have now. > > No, it would not. Seriously, from time to time a bit of RTFS before grand > proposals turns out to be useful. As one example, look at __sys_setsockopt(). It's called for the native and compat versions, and it contains an in_compat_syscall() check. (This particularly check looks dubious to me, but that's another story.) If this were to be done with equivalent semantics without a separate COMPAT_DEFINE_SYSCALL and without in_compat_syscall(), there would need to be some indication as to whether this is compat or native setsockopt. There are other setsockopt implementations in the net stack with more legitimate-seeming uses of in_compat_syscall() that would need some other mechanism if in_compat_syscall() were to go away. setsockopt is (I hope!) out of scope for io_uring, but the situation isn't fundamentally different from read and write. 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,DKIM_INVALID, DKIM_SIGNED,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 955A0C43465 for ; Sun, 20 Sep 2020 17:02:50 +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 8686720EDD for ; Sun, 20 Sep 2020 17:02:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="gJKTktW4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8686720EDD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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 4BvYm64kZczDqdP for ; Mon, 21 Sep 2020 03:02:46 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=198.145.29.99; helo=mail.kernel.org; envelope-from=luto@kernel.org; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=default header.b=gJKTktW4; dkim-atps=neutral Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4BvYhn3MB7zDqZ3 for ; Mon, 21 Sep 2020 02:59:53 +1000 (AEST) Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2B77E23600 for ; Sun, 20 Sep 2020 16:59:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600621190; bh=x0CbGoy7QDKeuRiDyZ0r+bpumnscmCVOPI/85NlktW8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=gJKTktW4SZM9Nk5DOVt1OrRoD5xvcMTHGvsORGcnvvYrrRwkT7FctEN7F9OgfkMkf go8qh4j37RWcESJvMJRLehEaF3oKhwPYJJdJDts/+toGi7k1LIglAiuuVrdC6I4+Xp /LzZmxNyVgp/8l8nI8i/3m9FhkW6jCz/eC4EQY4Q= Received: by mail-wm1-f44.google.com with SMTP id z9so10231124wmk.1 for ; Sun, 20 Sep 2020 09:59:50 -0700 (PDT) X-Gm-Message-State: AOAM53194jGSbFK7FSvWSG0jBw2cGlwXjv4B86YIzUY6y081OzE88nvl khBBSQx6cq9eQawDYGY0LliXHhbwR/JEgaMiVzpNqQ== X-Google-Smtp-Source: ABdhPJwqhOCovrDdCcRZECZNQYs8Sx/d9wwPnQKSY4d4VjHeXmP8XzKxWrTfmcwJ7rQVtp7oa0fbaMUpJAjukisl/1Y= X-Received: by 2002:a1c:7e15:: with SMTP id z21mr25730921wmc.21.1600621188572; Sun, 20 Sep 2020 09:59:48 -0700 (PDT) MIME-Version: 1.0 References: <20200919224122.GJ3421308@ZenIV.linux.org.uk> <36CF3DE7-7B4B-41FD-9818-FDF8A5B440FB@amacapital.net> <20200919232411.GK3421308@ZenIV.linux.org.uk> <20200920025745.GL3421308@ZenIV.linux.org.uk> In-Reply-To: <20200920025745.GL3421308@ZenIV.linux.org.uk> From: Andy Lutomirski Date: Sun, 20 Sep 2020 09:59:36 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag To: Al Viro Content-Type: text/plain; charset="UTF-8" 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:MIPS" , David Howells , Linux-MM , keyrings@vger.kernel.org, sparclinux , Christoph Hellwig , linux-arch , linux-s390 , Linux SCSI List , X86 ML , Arnd Bergmann , linux-block , Andy Lutomirski , io-uring@vger.kernel.org, linux-arm-kernel , Jens Axboe , Parisc List , Network Development , LKML , LSM List , Linux FS Devel , Andrew Morton , linuxppc-dev Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Sat, Sep 19, 2020 at 7:57 PM Al Viro wrote: > > On Sat, Sep 19, 2020 at 05:14:41PM -0700, Andy Lutomirski wrote: > > > > 2) have you counted the syscalls that do and do not need that? > > > > No. > > Might be illuminating... > > > > 3) how many of those realistically *can* be unified with their > > > compat counterparts? [hint: ioctl(2) cannot] > > > > There would be no requirement to unify anything. The idea is that > > we'd get rid of all the global state flags. > > _What_ global state flags? When you have separate SYSCALL_DEFINE3(ioctl...) > and COMPAT_SYSCALL_DEFINE3(ioctl...), there's no flags at all, global or > local. They only come into the play when you try to share the same function > for both, right on the top level. ... > > > For ioctl, we'd have a new file_operation: > > > > long ioctl(struct file *, unsigned int, unsigned long, enum syscall_arch); > > > > I'm not saying this is easy, but I think it's possible and the result > > would be more obviously correct than what we have now. > > No, it would not. Seriously, from time to time a bit of RTFS before grand > proposals turns out to be useful. As one example, look at __sys_setsockopt(). It's called for the native and compat versions, and it contains an in_compat_syscall() check. (This particularly check looks dubious to me, but that's another story.) If this were to be done with equivalent semantics without a separate COMPAT_DEFINE_SYSCALL and without in_compat_syscall(), there would need to be some indication as to whether this is compat or native setsockopt. There are other setsockopt implementations in the net stack with more legitimate-seeming uses of in_compat_syscall() that would need some other mechanism if in_compat_syscall() were to go away. setsockopt is (I hope!) out of scope for io_uring, but the situation isn't fundamentally different from read and write. 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.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 7558EC43465 for ; Sun, 20 Sep 2020 17:01:27 +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 15FE020EDD for ; Sun, 20 Sep 2020 17:01:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="YLHJt4Bx"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="gJKTktW4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 15FE020EDD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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=Mp3AJ6ilV8kw4MOQHvSpIdzUQfG5J7JoX1Eouu//9ik=; b=YLHJt4BxCLJZmpjCTYPOnni2B GvLnz/RuYLUhgaoAv2zxQ7/b6AbzqqYqFdLjdOaC5Lx71ajQDHxGbXtaGbhTt0nIwE8Frz2o5ZQig kZbnxvJ21zVqHwdHIXuTX+tBFJaNCu7QBCNlO77SvIvPlzPARh17O1PYq0Yi3l0SIGU0gszrFGpUg u2RCmFRXiumiKzN2HLIOHTRyxe2EqPcG+RffmyvtSwX/ViU71HRRhGJSGxZDaHyR2LIUHKf9cvIC9 FnwaJHkfBV5kqyxvpvZWm9DUTuj8dkIWMJryHEziNBHCi+Ck84BpZYXLzPVYjZAhd32n/qb76mtce 3vrzedvvQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kK2gs-0005Ne-Ml; Sun, 20 Sep 2020 16:59:54 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kK2gp-0005M4-Ax for linux-arm-kernel@lists.infradead.org; Sun, 20 Sep 2020 16:59:52 +0000 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 23EF1235FA for ; Sun, 20 Sep 2020 16:59:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600621190; bh=x0CbGoy7QDKeuRiDyZ0r+bpumnscmCVOPI/85NlktW8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=gJKTktW4SZM9Nk5DOVt1OrRoD5xvcMTHGvsORGcnvvYrrRwkT7FctEN7F9OgfkMkf go8qh4j37RWcESJvMJRLehEaF3oKhwPYJJdJDts/+toGi7k1LIglAiuuVrdC6I4+Xp /LzZmxNyVgp/8l8nI8i/3m9FhkW6jCz/eC4EQY4Q= Received: by mail-wm1-f51.google.com with SMTP id e17so9878970wme.0 for ; Sun, 20 Sep 2020 09:59:50 -0700 (PDT) X-Gm-Message-State: AOAM5324PqgWP62KrT+VMYuCIMxWdjNkAVryWYe7zgn2r09ty3v2HHli KtpL78i6ZFEWhtDxIciL+Bf5kYmC5NZpXnFP/0CM9w== X-Google-Smtp-Source: ABdhPJwqhOCovrDdCcRZECZNQYs8Sx/d9wwPnQKSY4d4VjHeXmP8XzKxWrTfmcwJ7rQVtp7oa0fbaMUpJAjukisl/1Y= X-Received: by 2002:a1c:7e15:: with SMTP id z21mr25730921wmc.21.1600621188572; Sun, 20 Sep 2020 09:59:48 -0700 (PDT) MIME-Version: 1.0 References: <20200919224122.GJ3421308@ZenIV.linux.org.uk> <36CF3DE7-7B4B-41FD-9818-FDF8A5B440FB@amacapital.net> <20200919232411.GK3421308@ZenIV.linux.org.uk> <20200920025745.GL3421308@ZenIV.linux.org.uk> In-Reply-To: <20200920025745.GL3421308@ZenIV.linux.org.uk> From: Andy Lutomirski Date: Sun, 20 Sep 2020 09:59:36 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag To: Al Viro X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200920_125951_786038_6403A648 X-CRM114-Status: GOOD ( 26.00 ) 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:MIPS" , David Howells , Linux-MM , keyrings@vger.kernel.org, sparclinux , Christoph Hellwig , linux-arch , linux-s390 , Linux SCSI List , X86 ML , Arnd Bergmann , linux-block , Andy Lutomirski , io-uring@vger.kernel.org, linux-arm-kernel , Jens Axboe , Parisc List , Network Development , LKML , LSM List , Linux FS Devel , 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 Sat, Sep 19, 2020 at 7:57 PM Al Viro wrote: > > On Sat, Sep 19, 2020 at 05:14:41PM -0700, Andy Lutomirski wrote: > > > > 2) have you counted the syscalls that do and do not need that? > > > > No. > > Might be illuminating... > > > > 3) how many of those realistically *can* be unified with their > > > compat counterparts? [hint: ioctl(2) cannot] > > > > There would be no requirement to unify anything. The idea is that > > we'd get rid of all the global state flags. > > _What_ global state flags? When you have separate SYSCALL_DEFINE3(ioctl...) > and COMPAT_SYSCALL_DEFINE3(ioctl...), there's no flags at all, global or > local. They only come into the play when you try to share the same function > for both, right on the top level. ... > > > For ioctl, we'd have a new file_operation: > > > > long ioctl(struct file *, unsigned int, unsigned long, enum syscall_arch); > > > > I'm not saying this is easy, but I think it's possible and the result > > would be more obviously correct than what we have now. > > No, it would not. Seriously, from time to time a bit of RTFS before grand > proposals turns out to be useful. As one example, look at __sys_setsockopt(). It's called for the native and compat versions, and it contains an in_compat_syscall() check. (This particularly check looks dubious to me, but that's another story.) If this were to be done with equivalent semantics without a separate COMPAT_DEFINE_SYSCALL and without in_compat_syscall(), there would need to be some indication as to whether this is compat or native setsockopt. There are other setsockopt implementations in the net stack with more legitimate-seeming uses of in_compat_syscall() that would need some other mechanism if in_compat_syscall() were to go away. setsockopt is (I hope!) out of scope for io_uring, but the situation isn't fundamentally different from read and write. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel