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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 31AF2CCA479 for ; Tue, 28 Jun 2022 11:51:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344600AbiF1LvJ (ORCPT ); Tue, 28 Jun 2022 07:51:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51268 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344287AbiF1LvI (ORCPT ); Tue, 28 Jun 2022 07:51:08 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B823BF18; Tue, 28 Jun 2022 04:51:04 -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-out1.suse.de (Postfix) with ESMTPS id 6A95C21E50; Tue, 28 Jun 2022 11:51:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1656417063; 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=u6QyzjA0WXJZm5y/Yp1Q51V61GQNDJoRSnCEcOY53uI=; b=uSA6oXLmU0vSd+JP+EeaPg+uSLJkXqM6iHhljNQDVGWJHNTxyRPF/TT5ev7vyKToAtM4wW HMumprw0FlBLhUV9NblLW8NxladvUcfYmqyYutDmzUMnBlWTLNezac1ic8GIth02CNb/Mc HH90sAKnLrZDIit4hVMnjGstYchs6KM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1656417063; 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=u6QyzjA0WXJZm5y/Yp1Q51V61GQNDJoRSnCEcOY53uI=; b=cyJkAgYhq2ZEegkyJBNwzKYl8/YzKmz2preVaquVDpxqJXCCe0QTVEZLYdAmrWCkVvA6Jt 0wJZoMxdFvknRkDQ== 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 27367139E9; Tue, 28 Jun 2022 11:51:03 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id ez52CCfrumKEDgAAMHmgww (envelope-from ); Tue, 28 Jun 2022 11:51:03 +0000 Date: Tue, 28 Jun 2022 13:46:21 +0200 From: David Sterba To: Christoph Hellwig Cc: Jan Kara , Qu Wenruo , clm@fb.com, josef@toxicpanda.com, dsterba@suse.com, linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] btrfs: remove btrfs_writepage_cow_fixup Message-ID: <20220628114621.GA20633@suse.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Christoph Hellwig , Jan Kara , Qu Wenruo , clm@fb.com, josef@toxicpanda.com, dsterba@suse.com, linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220625091143.GA23118@lst.de> User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Sat, Jun 25, 2022 at 11:11:43AM +0200, Christoph Hellwig wrote: > On Fri, Jun 24, 2022 at 03:07:50PM +0200, Jan Kara wrote: > > I'm not sure I get the context 100% right but pages getting randomly dirty > > behind filesystem's back can still happen - most commonly with RDMA and > > similar stuff which calls set_page_dirty() on pages it has got from > > pin_user_pages() once the transfer is done. page_maybe_dma_pinned() should > > be usable within filesystems to detect such cases and protect the > > filesystem but so far neither me nor John Hubbart has got to implement this > > in the generic writeback infrastructure + some filesystem as a sample case > > others could copy... > > Well, so far the strategy elsewhere seems to be to just ignore pages > only dirtied through get_user_pages. E.g. iomap skips over pages > reported as holes, and ext4_writepage complains about pages without > buffers and then clears the dirty bit and continues. > > I'm kinda surprised that btrfs wants to treat this so special > especially as more of the btrfs page and sub-page status will be out > of date as well. I'm not sure it's safe to ignore that in btrfs, that's sounds quite risky and potentially breaking something. It's not only that page does not have buffers but that there's page with dirty bit set but without the associated extents updated. So this needs a COW to get it back to sync. It's special because it's for COW, can't compare that to ext4.