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 C4B4DC43466 for ; Sun, 20 Sep 2020 19:10:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 54C7E20789 for ; Sun, 20 Sep 2020 19:10:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 54C7E20789 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 8E5F490000E; Sun, 20 Sep 2020 15:10:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 86EF6900009; Sun, 20 Sep 2020 15:10:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 719D490000D; Sun, 20 Sep 2020 15:10:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0066.hostedemail.com [216.40.44.66]) by kanga.kvack.org (Postfix) with ESMTP id 546A9900009 for ; Sun, 20 Sep 2020 15:10:45 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 1E6501EE6 for ; Sun, 20 Sep 2020 19:10:45 +0000 (UTC) X-FDA: 77284381650.27.pan14_190ac532713e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id EDECD3D663; Sun, 20 Sep 2020 19:10:44 +0000 (UTC) X-HE-Tag: pan14_190ac532713e X-Filterd-Recvd-Size: 3266 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [195.92.253.2]) by imf47.hostedemail.com (Postfix) with ESMTP; Sun, 20 Sep 2020 19:10:44 +0000 (UTC) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kK4jH-002dC7-8S; Sun, 20 Sep 2020 19:10:31 +0000 Date: Sun, 20 Sep 2020 20:10:31 +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: <20200920191031.GQ3421308@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200920190159.GT32101@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:01:59PM +0100, Matthew Wilcox wrote: > On Sun, Sep 20, 2020 at 07:07:42PM +0100, Al Viro wrote: > > 2) a few drivers are really fucked in head. They use different > > *DATA* layouts for reads/writes, depending upon the calling process. > > IOW, if you fork/exec a 32bit binary and your stdin is one of those, > > reads from stdin in parent and child will yield different data layouts. > > On the same struct file. > > That's what Christoph worries about (/dev/sg he'd mentioned is > > one of those). > > > > IMO we should simply have that dozen or so of pathological files > > marked with FMODE_SHITTY_ABI; it's not about how they'd been opened - > > it describes the userland ABI provided by those. And it's cast in stone. > > > > Any in_compat_syscall() in ->read()/->write() instances is an ABI > > bug, plain and simple. Some are unfixable for compatibility reasons, but > > any new caller like that should be a big red flag. > > So an IOCB_COMPAT flag would let us know whether the caller is expecting > a 32-bit or 64-bit layout? And io_uring could set it based on the > ctx->compat flag. So you want to convert all that crap to a form that would see iocb (IOW, ->read_iter()/->write_iter())? And, since quite a few are sysfs attributes, propagate that through sysfs, changing the method signatures to match that and either modifying fuckloads of instances or introducing new special methods for the ones that are sensitive to that crap? IMO it's much saner to mark those and refuse to touch them from io_uring...