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 AE613C43334 for ; Sat, 25 Jun 2022 09:11:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232424AbiFYJLs (ORCPT ); Sat, 25 Jun 2022 05:11:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50486 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230395AbiFYJLr (ORCPT ); Sat, 25 Jun 2022 05:11:47 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4EB653BF83; Sat, 25 Jun 2022 02:11:47 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id 99A4768AA6; Sat, 25 Jun 2022 11:11:43 +0200 (CEST) Date: Sat, 25 Jun 2022 11:11:43 +0200 From: Christoph Hellwig To: Jan Kara Cc: Christoph Hellwig , 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: <20220625091143.GA23118@lst.de> References: <20220624122334.80603-1-hch@lst.de> <7c30b6a4-e628-baea-be83-6557750f995a@gmx.com> <20220624125118.GA789@lst.de> <20220624130750.cu26nnm6hjrru4zd@quack3.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220624130750.cu26nnm6hjrru4zd@quack3.lan> User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org 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.