Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp431680iog; Fri, 24 Jun 2022 06:55:29 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tOGTZ5cgQhea6DuiM88wUcdKwkHl87kNkQVhu1Pwymcn117YjwctreqL/kD+U0AlRzE8cs X-Received: by 2002:a63:8f56:0:b0:40c:9877:9f51 with SMTP id r22-20020a638f56000000b0040c98779f51mr12132953pgn.206.1656078928985; Fri, 24 Jun 2022 06:55:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656078928; cv=none; d=google.com; s=arc-20160816; b=JvrV+3lb+sJm/smDSPVSGX3I1O3L8ukShXaAfjrFN4oClzddWs+rezgmCCmzuVVzFU zD3nk0TH1wFA04hUde/KOUtqPR7xq4pdgpB4AWqPs+9oq2iNp+R09wtG1LXuy0wxz8WM 6K+6QrHx3MuXL+EnmXWOKcF4yiwbnmUsTEd3aykKGJ/9No0coHuOXYY5s4sP5lcMNLjs 7kKmgLkADdp305qXcPnAawQtGVhT3d9mNOOFMNjRWJdz4ws00nq068Q4vmlmxsVBfNH6 CisU5pCrC7vc5p+CfKrYNC8B0Ud/pEkoC5UaPldjoKrVD8/TKgsEde6BmdMa+SHeEI2i JdAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:mail-followup-to:reply-to:message-id :subject:cc:to:from:date:dkim-signature:dkim-signature; bh=RgjcjsWwgFCT51qzN2+gjNYaVNpGbaTRZxVXLNJmXbg=; b=HpXXhYn1Kp9j/lHPPcQwVjoumof/4uUQvT8jRZ/MVEfqjgeWw52mja8JpwJ4Oz2LOf ev+HfZApfH6lanF8D0a01wycLQqQbFnppNkYhncA2kQBRzf0gTsLKDJ6DDoFz12jtV7U lK2HVt7GCwhXYB6EFA5rkXNKg+yr9129vN2N0MmU/m4qLEec5SmpqnDlAjWdt7YFl8h8 EnFtDg22dfNf9R322jnLf+zk2cB5ey0ibL7yA5TICS82kFVaKwgAmIvalaV9vEzcuwVP 8CiTN0MNMxFlymdS+CzyQ6N1N1JouEX3dPvMy5Nr1X/1kwGFtFVC75dDKDpsV48qnl5w kphQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=VvgWBKdl; dkim=neutral (no key) header.i=@suse.cz header.b=rbv9OWQH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q25-20020a656259000000b003fd8db5b36fsi2643573pgv.217.2022.06.24.06.55.15; Fri, 24 Jun 2022 06:55:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=VvgWBKdl; dkim=neutral (no key) header.i=@suse.cz header.b=rbv9OWQH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231891AbiFXNbv (ORCPT + 99 others); Fri, 24 Jun 2022 09:31:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35812 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230223AbiFXNbu (ORCPT ); Fri, 24 Jun 2022 09:31:50 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C4B0838BFA; Fri, 24 Jun 2022 06:31:41 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 843F71F8EF; Fri, 24 Jun 2022 13:31:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1656077500; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RgjcjsWwgFCT51qzN2+gjNYaVNpGbaTRZxVXLNJmXbg=; b=VvgWBKdl1CvOhvyADG1uOBOtFL4EJM2iTP2RJqENtsxjEYxFI99ueud6cmoj+xODh0wwcW kMqP/2+9iWPT6AEnQqfytCLGO+D2y6T+8o8FSO3uf4PV21cMv2Cyo8bgWLj0jJBKaV558o OODUa0Kvif5Pec8YeSKL8+/Flq4R9Tc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1656077500; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RgjcjsWwgFCT51qzN2+gjNYaVNpGbaTRZxVXLNJmXbg=; b=rbv9OWQH8nhn7uiUClbt61DsOVh1zVoZ2ZxvEt5asVQO0+SUARI8H8X4igIt64k89EDwJw uzXtiGYjZlESk3DQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 3F69B13480; Fri, 24 Jun 2022 13:31:40 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id WYCFDry8tWJVBQAAMHmgww (envelope-from ); Fri, 24 Jun 2022 13:31:40 +0000 Date: Fri, 24 Jun 2022 15:27:01 +0200 From: David Sterba To: Qu Wenruo Cc: dsterba@suse.cz, Christoph Hellwig , clm@fb.com, josef@toxicpanda.com, dsterba@suse.com, linux-btrfs@vger.kernel.org, Linux Kernel Mailing List , Linux Memory Management List Subject: Re: [PATCH] btrfs: remove btrfs_writepage_cow_fixup Message-ID: <20220624132701.GT20633@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Qu Wenruo , Christoph Hellwig , clm@fb.com, josef@toxicpanda.com, dsterba@suse.com, linux-btrfs@vger.kernel.org, Linux Kernel Mailing List , Linux Memory Management List References: <20220624122334.80603-1-hch@lst.de> <20220624124913.GS20633@twin.jikos.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 24, 2022 at 09:12:44PM +0800, Qu Wenruo wrote: > 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. Probably yes. > Furthermore, this means we can get a page dirtied without us knowing. This should not happen because we do have the detection of the page and extent state mismatch and the fixup worker makes things right again. > 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. You seem to be a non-believer that the bug is real and calling the code dead. Each filesystem should validate the implementation agains the platform where it is and btrfs once found the hard way that there are some corner cases where structures get out of sync. > 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? The regression test is generic/208 and it was not reliable at all, it fired randomly once a week or month, there used to be a BUG() in the fixup worker callback. > Instead of just keeping what we know works, I really want to handle this > old case/bug in a more modern way. As long as the guarantees stay the same, then fine. We need to be able to detect the unexpected dirty bit and have a way to react to it. f4b1363cae43 ("btrfs: do not do delalloc reservation under page lock") 25f3c5021985 ("Btrfs: keep pages dirty when using btrfs_writepage_fixup_worker") 1d53c9e67230 ("Btrfs: only associate the locked page with one async_chunk struct") And the commit that fixed it: 87826df0ec36 ("btrfs: delalloc for page dirtied out-of-band in fixup worker") You can find several reports in the mailing list archives (search term btrfs_writepage_fixup_worker): https://lore.kernel.org/linux-btrfs/1295053074.15265.6.camel@mercury.localdomain https://lore.kernel.org/linux-btrfs/20110701174436.GA8352@yahoo.fr https://lore.kernel.org/linux-btrfs/j0k65i$29a$1@dough.gmane.org https://lore.kernel.org/linux-btrfs/CAO47_--H0+6bu4qQ2QA9gZcHvGVWO4QUGCAb3+9a5Kg3+23UiQ@mail.gmail.com https://lore.kernel.org/linux-btrfs/vqfmv8-9ch.ln1@hurikhan.ath.cx