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 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 CF366C43463 for ; Sun, 20 Sep 2020 21:42:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 227EA20829 for ; Sun, 20 Sep 2020 21:42:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 227EA20829 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3E6B16B0082; Sun, 20 Sep 2020 17:42:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 339866B007D; Sun, 20 Sep 2020 17:42:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 140676B0087; Sun, 20 Sep 2020 17:42:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0197.hostedemail.com [216.40.44.197]) by kanga.kvack.org (Postfix) with ESMTP id EBE0E6B0082 for ; Sun, 20 Sep 2020 17:42:43 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id A8F518249980 for ; Sun, 20 Sep 2020 21:42:43 +0000 (UTC) X-FDA: 77284764606.01.hill56_11133622713f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id 8BD19100471E6; Sun, 20 Sep 2020 21:42:43 +0000 (UTC) X-HE-Tag: hill56_11133622713f X-Filterd-Recvd-Size: 2589 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [195.92.253.2]) by imf11.hostedemail.com (Postfix) with ESMTP; Sun, 20 Sep 2020 21:42:42 +0000 (UTC) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kK76L-002haB-NO; Sun, 20 Sep 2020 21:42:29 +0000 Date: Sun, 20 Sep 2020 22:42:29 +0100 From: Al Viro To: Matthew Wilcox Cc: Christoph Hellwig , Andrew Morton , Jens Axboe , Arnd Bergmann , David Howells , linux-arm-kernel@lists.infradead.org, x86@kernel.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 1/9] kernel: add a PF_FORCE_COMPAT flag Message-ID: <20200920214229.GR3421308@ZenIV.linux.org.uk> References: <20200918124533.3487701-1-hch@lst.de> <20200918124533.3487701-2-hch@lst.de> <20200920151510.GS32101@casper.infradead.org> <20200920180742.GN3421308@ZenIV.linux.org.uk> <20200920190159.GT32101@casper.infradead.org> <20200920191031.GQ3421308@ZenIV.linux.org.uk> <20200920192259.GU32101@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200920192259.GU32101@casper.infradead.org> 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 Sun, Sep 20, 2020 at 08:22:59PM +0100, Matthew Wilcox wrote: > On Sun, Sep 20, 2020 at 08:10:31PM +0100, Al Viro wrote: > > IMO it's much saner to mark those and refuse to touch them from io_uring... > > Simpler solution is to remove io_uring from the 32-bit syscall list. > If you're a 32-bit process, you don't get to use io_uring. Would > any real users actually care about that? What for? I mean, is there any reason to try and keep those bugs as first-class citizens? IDGI... Yes, we have several special files (out of thousands) that have read()/write() user-visible semantics broken wrt 32bit/64bit. And we have to keep them working that way for existing syscalls. Why would we want to pretend that their behaviour is normal and isn't an ABI bug, not to be repeated for anything new?