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.