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 15851C433EF for ; Fri, 24 Jun 2022 13:12:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9E2FC8E0222; Fri, 24 Jun 2022 09:12:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 991A78E020E; Fri, 24 Jun 2022 09:12:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 858E28E0222; Fri, 24 Jun 2022 09:12:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 770FF8E020E for ; Fri, 24 Jun 2022 09:12:54 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 4AAFD726 for ; Fri, 24 Jun 2022 13:12:54 +0000 (UTC) X-FDA: 79613169468.18.60F1C6D Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by imf28.hostedemail.com (Postfix) with ESMTP id 92C1AC00BC for ; Fri, 24 Jun 2022 13:12:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1656076371; bh=mpgGbs0Th9qSc5wRx9aDtFvrJXSc6il6Q39uU61O9/Q=; h=X-UI-Sender-Class:Date:To:References:Cc:From:Subject:In-Reply-To; b=W13GLORQo4mFRzfAOT0zfMID4vv7W/3G/dTn33glJaBUfaqUwrhmDUOQbi6+RIuNl tlko9DswKfBwn1DhdR911ql/t/KT9H2X+QeeWuHscPB/QcqIdicMf2knnUte82MKLi heAAWaJ9GCp9KUD7v0mzJtV21hlaoFT1Mh0V1ULg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [0.0.0.0] ([149.28.201.231]) by mail.gmx.net (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1MlNtF-1nNNct0vS1-00lo3h; Fri, 24 Jun 2022 15:12:51 +0200 Message-ID: Date: Fri, 24 Jun 2022 21:12:44 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Content-Language: en-US To: dsterba@suse.cz, Christoph Hellwig , clm@fb.com, josef@toxicpanda.com, dsterba@suse.com, linux-btrfs@vger.kernel.org References: <20220624122334.80603-1-hch@lst.de> <20220624124913.GS20633@twin.jikos.cz> Cc: Linux Kernel Mailing List , Linux Memory Management List From: Qu Wenruo Subject: Re: [PATCH] btrfs: remove btrfs_writepage_cow_fixup In-Reply-To: <20220624124913.GS20633@twin.jikos.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:jN5WovdcgKwQ7MC+rQehoNVujc6Vceol5Mpw4MjMm+kzk7LuLt8 iQY5JSukD8cwWns0ier8wfJRmvaiKWzljF6hJ+fcPjE71Uwd7M5xhnKVh+NvqFqfcOV3vaJ xQeaMGhv3YUGfh2Y5xMQogOZu4yU5Zp8ZPihEfiJVuf/6ZJEmgNkKoAnxtdjU4Y5Py4LlF9 50BqUOXMbij7jSSowBE1w== X-UI-Out-Filterresults: notjunk:1;V03:K0:ah5fHvL9uP8=:Mjl0wCGX/fo7MhMwzB+gHN pZe5V3uoDLqVzlj1v/z7VJ0slrMnXnXk/Pcc8MHxYcuni0m9vwNbGZVcD+SmWZyHAN9i+LBNw aTa0BlAHnE0ZZQQe5jmZDRslI8kifPlBESnXeOUtNb6gHxt3T6ZFlzzpFqFo4d4T5zSqNnrdB BlwgipCNE+LgwBGPyjB6xlRM4ClAfezTPlEt2sbIy3rsKs8lj0G/gvEwImETzD3Xu3lbHn1xf E5HvybpJil8aIB0VFwnCsQA9TEwAFeLRD6NciOc7mb8SdNLVUhq4zoQQ6hegY+yZ8mIV2C7NX f2SLujPLeIzciVCbr+ed/p6HjpKfKrNKm75eOpb7A5ovVf6+IMaV9SneHW4Vlfu7FPjd3z1/H DYXUxwQnoimhXQlAQD5CSv7tLN9JwJ3OBr3cyl80MGM0/n5d+qq03GQ6G1ZcXOlMyPkU+IArr +vWmFfMBIrURduly1LlOVkExg3A895QNFjtaD0sTdjd5oJKIP1v9tC1tfvAbOHRCZc+p69ZFH P7SMj7l9/8f0re1FKrjqQwYrB1prvzXz9tDof5Rn4l0tPoUCgR69gJaV77OG+trVusgO6MwWC hNnx3kWC/lHQym4CUPYk7D9OgvunEr9C6XgsgoD+BiWDA8ZIv7bpzjzI6X6gA3WCt02ensosx m3zUKVZw1XmPluXDFpT69x6b2dToXA9NJVzmOFBfdu4bixYV7ie5PKl2+G8E5USBgWLy4S/kC HVsLlQmFaZDM8PJTv1zwipENMBJWrS71jV8zCzOWzvtlpN+KTSw4Ph9D529RgPeQSRsgLnLNV eB8VrR+uLWprz5z0BRuRl1rRjZJizHbVuJ02In/ZJdil9+vZvdojP390uBLoahEtJ28njKn1Z BGtXqZaML0Gw2TcfP4u2EcswB+SKmtLEN9nj+NskGrkBylNCj/lFu9rmjX1c1dYwGX2di4JaL bxjy4ewYe7I3oqovQxYKIsVatHdI2xzVUQMc7Lp4hsk/drydTaytAmxwDr+4Beq5Q+sUX4W9a BCqtHd7w+PliTx0DVMKxoTi+OueJ6uL/tBE8ecsIgm8EItzmjzEKZN3kGJAGxdXWcHsVxK1dp 6mUjE3mOn8W6TYT3H8b+34eU4BbfJasVersxlxwpUqSDpfYkSj5ITjxRA== ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656076373; a=rsa-sha256; cv=none; b=KcD5R82ri+a5/+UGoA24nmjvWYQwucpLHK0fLmncAGQzQe/L7E3BHHfKyaT5rOrGrSkcb1 rrFDuaJfLypR9ylVW/WMdVdaLQErXXwSmkUWmFOuoX4cp1S2wXqC7e4zDmyGPpX+jDBiDs PBzsXIAk/CtuoG99V/05aeUKV05WujM= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=W13GLORQ; dmarc=pass (policy=none) header.from=gmx.com; spf=pass (imf28.hostedemail.com: domain of quwenruo.btrfs@gmx.com designates 212.227.17.21 as permitted sender) smtp.mailfrom=quwenruo.btrfs@gmx.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656076373; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=358z4V8htp+5AvY966cPiQbqvcnFP1xAgaQTe+Y2Byk=; b=6nxVmfClHnkaEmU5RifGnruCk0CXaLVR9Q8gEFYXpnZ5OUZCrwD7ts2u8CNNw8jY1RvzYx x6dn84l6vGlh5tNb8zZdCl6aNEQAvPF1vJVvEBdbIiKWMpbvQm0yL4hIH0D6P6New2R3re FTcS45BoZFonNgDvaswxotFcZVD2kwY= X-Rspam-User: X-Stat-Signature: u5ef53ycfsyofarkhskj6roh8ijaqo8e X-Rspamd-Queue-Id: 92C1AC00BC Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=W13GLORQ; dmarc=pass (policy=none) header.from=gmx.com; spf=pass (imf28.hostedemail.com: domain of quwenruo.btrfs@gmx.com designates 212.227.17.21 as permitted sender) smtp.mailfrom=quwenruo.btrfs@gmx.com X-Rspamd-Server: rspam03 X-HE-Tag: 1656076373-391751 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 2022/6/24 20:49, David Sterba wrote: > On Fri, Jun 24, 2022 at 02:23:34PM +0200, Christoph Hellwig wrote: >> Since the page_mkwrite address space operation was added, starting with >> commit 9637a5efd4fb ("[PATCH] add page_mkwrite() vm_operations method") >> in 2006, the kernel does not just dirty random pages without telling >> the file system. > > It does and there's a history behind the fixup worker. tl;dr it can't be > removed, though every now and then somebody comes and tries to. > > On s390 the page status is tracked in two places, hw and in memory and > this needs to be synchronized manually. > > On x86_64 it's not a simple reason but it happens as well in some edge > case where the mappings get removed and dirty page is set deep in the > arch mm code. We've been chasing it long time ago, I don't recall exact > details and it's been a painful experience. > > If there's been any change on the s390 side or in arch/x86/mm code I > don't know but to be on the safe side, I strongly assume the fixup code > is needed unless proven otherwise. I'd say, if this can be a problem to btrfs, then all fs supporting COW should also be affected, and should have similar workaround. Furthermore, this means we can get a page dirtied without us knowing. This is a super big surprise to any fs, and should be properly documented, not just leaving some seemly dead and special code in some random fs. Furthermore, I'm not sure even if handling this in a fs level is correct. This looks like more a MM problem to me then. I totally understand it's a pain to debug such lowlevel bug, but shouldn't we have a proper regression for it then? Instead of just keeping what we know works, I really want to handle this old case/bug in a more modern way. Thanks, Qu