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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A7C96C433EF for ; Wed, 29 Jun 2022 07:58:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 185948E0002; Wed, 29 Jun 2022 03:58:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1421F8E0001; Wed, 29 Jun 2022 03:58:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 023598E0002; Wed, 29 Jun 2022 03:58:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id E4B448E0001 for ; Wed, 29 Jun 2022 03:58:42 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B87671425 for ; Wed, 29 Jun 2022 07:58:42 +0000 (UTC) X-FDA: 79630521684.29.E43336A Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf26.hostedemail.com (Postfix) with ESMTP id 038E9140008 for ; Wed, 29 Jun 2022 07:58:41 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id 0D32867373; Wed, 29 Jun 2022 09:58:38 +0200 (CEST) Date: Wed, 29 Jun 2022 09:58:37 +0200 From: Christoph Hellwig To: dsterba@suse.cz, Qu Wenruo , Jan Kara , Christoph Hellwig , clm@fb.com, josef@toxicpanda.com, dsterba@suse.com, linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Heiko Carstens , Vasily Gorbik , Alexander Gordeev , linux-s390@vger.kernel.org Subject: Re: [PATCH] btrfs: remove btrfs_writepage_cow_fixup Message-ID: <20220629075837.GA22346@lst.de> References: <20220624122334.80603-1-hch@lst.de> <7c30b6a4-e628-baea-be83-6557750f995a@gmx.com> <20220624125118.GA789@lst.de> <20220624130750.cu26nnm6hjrru4zd@quack3.lan> <20220625091143.GA23118@lst.de> <20220627101914.gpoz7f6riezkolad@quack3.lan> <20220628115356.GB20633@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220628115356.GB20633@suse.cz> User-Agent: Mutt/1.5.17 (2007-11-01) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656489522; a=rsa-sha256; cv=none; b=1HSCL7xQWFsV42kuMvWe6UmLp8zGPYviRZBgXU4+ks4RxxETJgTKn4uP+xZfFnqdGV8PST +zkpUaSOPFk2KGHTxBqp+YJ3k66XUMPA/NvXs+4irSh1VLmdnTnxdp2Yd2QkNHYGYaPpFQ Hq8Iz7OOqGorI0KcpV7zWSdO2GjPgyA= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=none; dmarc=none; spf=none (imf26.hostedemail.com: domain of hch@lst.de has no SPF policy when checking 213.95.11.211) smtp.mailfrom=hch@lst.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656489522; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KohrukuwjKZSnArxCynFicibGsA3CtIKr3KMHZ93cQg=; b=WQF2fJ0TXdtCEchND4IMErHgnQjh2mSyfGOKPxx0mjeNViPbRpGwMRaisCbPWTJuRY17do ipj4lBjP7DodufkxJvbPIXSujl3o2ThlYDjNSB+w0+dLDtxwGeJq5/9Vy3E/B6b5hqqK5C Gw+Eep158R0uh6wmgDDtM7WIKgaLc+g= X-Stat-Signature: 1nz1kesinbr5yu8ejxhfwy7bw55a5yc3 X-Rspamd-Queue-Id: 038E9140008 Authentication-Results: imf26.hostedemail.com; dkim=none; dmarc=none; spf=none (imf26.hostedemail.com: domain of hch@lst.de has no SPF policy when checking 213.95.11.211) smtp.mailfrom=hch@lst.de X-Rspamd-Server: rspam10 X-Rspam-User: X-HE-Tag: 1656489521-374089 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 Tue, Jun 28, 2022 at 01:53:56PM +0200, David Sterba wrote: > This would work only for the higher level API where eg. RDMA notifies > the filesystem, but there's still the s390 case that is part of the > hardware architecture. The fixup worker is there as a safety for all > other cases, I'm not fine removing or ignoring it. I'd really like to have a confirmation of this whole s390 theory. s390 does treat some dirtying different than the other architectures, but none of that should leak into the file system API if any way that bypasses ->page_mkwrite. Because if it did most file systems would be completely broken on s390.