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 DDD2CC43463 for ; Sun, 20 Sep 2020 16:59:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9EE5A2158C for ; Sun, 20 Sep 2020 16:59:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600621191; bh=x0CbGoy7QDKeuRiDyZ0r+bpumnscmCVOPI/85NlktW8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=twLw2ww9Tbi1GiXH1QA+u6ALyXkEmpb2JoztSoot4g31r0iLhcHxCl+IJ7LlYpryO P1CoA4BTAzXVM2TESrgaoORpeSMoQfXOV6tkp+jWNPI9dQ2pTzZrp6Rz4FHudI5nGm vZO47edyYrFQ7FSlbfCSoM5ZLNknZqFUZ3+ohL84= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726456AbgITQ7v (ORCPT ); Sun, 20 Sep 2020 12:59:51 -0400 Received: from mail.kernel.org ([198.145.29.99]:48304 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726437AbgITQ7u (ORCPT ); Sun, 20 Sep 2020 12:59:50 -0400 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (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 084B921D7A 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-f46.google.com with SMTP id w2so9874467wmi.1 for ; Sun, 20 Sep 2020 09:59:49 -0700 (PDT) X-Gm-Message-State: AOAM530IFH+Grucr7nylH0DojZrwSOcffcAPJI8Wqp32q2tRZhp0KaBA iZR4ezk7XeSt8I7Xtem3bibixfML3IjnpRN2m/YIUA== 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: io-uring@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.