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 A90EDC43469 for ; Sun, 20 Sep 2020 21:42:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7315D2085B for ; Sun, 20 Sep 2020 21:42:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726452AbgITVmm (ORCPT ); Sun, 20 Sep 2020 17:42:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56046 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726126AbgITVml (ORCPT ); Sun, 20 Sep 2020 17:42:41 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 992EFC061755; Sun, 20 Sep 2020 14:42:41 -0700 (PDT) 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> Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org 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? From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Date: Sun, 20 Sep 2020 21:42:29 +0000 Subject: Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag Message-Id: <20200920214229.GR3421308@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit List-Id: 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> In-Reply-To: <20200920192259.GU32101@casper.infradead.org> 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 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? 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 2E7A4C43463 for ; Sun, 20 Sep 2020 21:44:36 +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 6E4FA20829 for ; Sun, 20 Sep 2020 21:44:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6E4FA20829 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=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 4Bvh1D5P90zDqjQ for ; Mon, 21 Sep 2020 07:44:32 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=ftp.linux.org.uk (client-ip=2002:c35c:fd02::1; helo=zeniv.linux.org.uk; envelope-from=viro@ftp.linux.org.uk; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=zeniv.linux.org.uk Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4BvgzM4z2LzDqft for ; Mon, 21 Sep 2020 07:42:53 +1000 (AEST) 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 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-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@kvack.org, linux-mips@vger.kernel.org, David Howells , linux-mm@kvack.org, keyrings@vger.kernel.org, sparclinux@vger.kernel.org, Christoph Hellwig , linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, linux-scsi@vger.kernel.org, x86@kernel.org, Arnd Bergmann , linux-block@vger.kernel.org, io-uring@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Jens Axboe , linux-parisc@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org, Andrew Morton , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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? 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.3 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 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 17C4CC43465 for ; Sun, 20 Sep 2020 21:43:58 +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 B96C620829 for ; Sun, 20 Sep 2020 21:43:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="qw4G6y5e" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B96C620829 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=zeniv.linux.org.uk 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:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=jYkaoufpjEJfnnaq5pb+CQavqCBv6ddtHIK95o51Wuo=; b=qw4G6y5eEqFZ+AO+0P/9Zdp3u thFouCCPHKkokmlfrRoaz+zUE9UkA168PwDfWGc6UJ+65fq7duLC/nLZb3Yh4cYVvECQg+jn0V6sF ezxV5bQ9Yf59lmqFFk/fB+41chSkMBQtNi5WwHzvvyuPRibhc3G7qomQQF6+SSxX2ImbuM9yTS/zq sdM7vBIuZvG14jHmgjxVRl1rqev9avAt671pEAD6fJUfqi0xx9v4GZAV4A/W3WD1bgK8FnhefUNep Pue8oQ5pT6AQ1YNDXK9oFHC6Al32aWmz9dWiQeukVydH5pMP0WTWAAe2tCnVYJPKcMB1t3BZnW+NT S0IvmXgBg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kK76U-0004Bs-Qo; Sun, 20 Sep 2020 21:42:38 +0000 Received: from [2002:c35c:fd02::1] (helo=ZenIV.linux.org.uk) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kK76S-0004BY-KG for linux-arm-kernel@lists.infradead.org; Sun, 20 Sep 2020 21:42:37 +0000 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 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-Disposition: inline In-Reply-To: <20200920192259.GU32101@casper.infradead.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200920_174236_677292_40194F23 X-CRM114-Status: GOOD ( 13.71 ) 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@kvack.org, linux-mips@vger.kernel.org, David Howells , linux-mm@kvack.org, keyrings@vger.kernel.org, sparclinux@vger.kernel.org, Christoph Hellwig , linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, linux-scsi@vger.kernel.org, x86@kernel.org, Arnd Bergmann , linux-block@vger.kernel.org, io-uring@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Jens Axboe , linux-parisc@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org, Andrew Morton , linuxppc-dev@lists.ozlabs.org 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 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? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel