From patchwork Thu Jul 18 13:02:08 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brian Foster X-Patchwork-Id: 13736477 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 6C29FC3DA60 for ; Thu, 18 Jul 2024 13:01:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D11176B0089; Thu, 18 Jul 2024 09:01:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C990A6B0092; Thu, 18 Jul 2024 09:01:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AEAD36B0093; Thu, 18 Jul 2024 09:01:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 888736B0089 for ; Thu, 18 Jul 2024 09:01:43 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 3931E41ADF for ; Thu, 18 Jul 2024 13:01:43 +0000 (UTC) X-FDA: 82352885286.15.7F394DF Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf08.hostedemail.com (Postfix) with ESMTP id 814DA16003D for ; Thu, 18 Jul 2024 13:01:36 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="Uq+L6v/H"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf08.hostedemail.com: domain of bfoster@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bfoster@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721307666; a=rsa-sha256; cv=none; b=h9ZOF9dZ3eivKc9uZn/fuvZuBHxJHzCMctcjPiHHvj3D5Pe9hX7eM/s5WEODPvgLE+KscQ 94a50UBdy6J0w6USet4GYzb87tWBiHzuW2au2eoVEvinP6WfmEjbx0oPT8tXF3bJznGHwm 6yS9oT3WXk7QwaiJqquIjG/TYz5+k3s= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="Uq+L6v/H"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf08.hostedemail.com: domain of bfoster@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bfoster@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721307666; 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: references:dkim-signature; bh=3V+PXHSFTyeo6sWREIhFwcbZRHc4HxgVv7/AuNwulEI=; b=UuAKb3e69yDIzXVGm9LAX/ASAXnoCXlWonhS2qoOfOZohxIfA+Ybmn2vgXUghW8RxFr3iW JDtFN4KQGLkff/ptxrNSUUIIywLwbwQZZpM417SbR6Sz9b3yMmKkPxNfQHUa3us44bfxU1 kyEQgaOrDIiHjpqg3VQgbqsDvmwWR4U= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1721307695; h=from:from: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; bh=3V+PXHSFTyeo6sWREIhFwcbZRHc4HxgVv7/AuNwulEI=; b=Uq+L6v/HM23OOejRBzVuwmDKTrZ+PP9nyUqENHpFddlGLhzVYO0qlfjs87rHzdhmJOq1CH oZkBPYB/+hRF+H14xsOx/k5dsLtngKT3wf4twibmuzcgkKpfWohp4pBcarVoZOZ+ZLtvt7 y9haqsvwejxeCkiQuaDowuVJiVIRitw= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-64-xFF67-MjO-aQYm0ORU9Ngw-1; Thu, 18 Jul 2024 09:01:31 -0400 X-MC-Unique: xFF67-MjO-aQYm0ORU9Ngw-1 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 5C9761955F66; Thu, 18 Jul 2024 13:01:27 +0000 (UTC) Received: from bfoster.redhat.com (unknown [10.22.16.39]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 577671955F68; Thu, 18 Jul 2024 13:01:26 +0000 (UTC) From: Brian Foster To: linux-fsdevel@vger.kernel.org Cc: linux-xfs@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH RFC 0/4] iomap: zero dirty folios over unwritten mappings on zero range Date: Thu, 18 Jul 2024 09:02:08 -0400 Message-ID: <20240718130212.23905-1-bfoster@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Rspamd-Queue-Id: 814DA16003D X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: wdxc1tdbki3izf9twtxma4r3d3od1876 X-HE-Tag: 1721307696-47277 X-HE-Meta: U2FsdGVkX185sSAunLlfeHHq5RKxCvtCYU3MQSVR8j1f1ntjtHG4IUXLrcq5ExuLfa7xdBHNP4J4oJWtOlp/JHN7XP4I1kwyxTGoTHnWKJoTeSrRA+RTsD8RYM2Qk8VX+/2OLZSXGUmo3TJ3F+tJES885bkaKpekoboay2qhbwcJ+m9xnRSVXmUnNUSdRI9IO+ft3lIDk1R1EAAg3j+euSZWeqPxKY1Ato5Zd+zAO8iANRJU/5x6DQMNsNi66GRtPp0t2Ug4S9HEmtzJmvCQnSMLiY9nUzP7r5ZEc3x5+OKDJOAMUi5KsvzKl6XbZsjWmj6L4MDUzj7AfOP3wsFzRTlt8IJ08QRWrgFlMR+rjySrLvOkOnymcs5qqu58WLXh5Qgt2ecDiR9uzBnGC0PoUZBiATOquZtm1rjCZ6u7U967BOXM1CkrV/hOh/1pdmUBOYeHO59hp7YLRqKk+6PWj+IkKOYXh3GKrleka/nsdpoh2UqqAg1zTiKVXC+0Z5axg1AN5xcJS8hTqg3Xw1NX57kInttnCPQN8CRRF76TXmA00NYZs14/rqVk2OJmuZRCZEX/K1ilSb94yJfWFTivba29R+gyG7kf4yoroBL+LyVklI2ziFhT81wDmgiVITB3QpY7D723SzJbaev/J65oVKh7/cJlW4XVdiAcQFR8+PClO9TR/nWxcoEbgUPRn9tqzc2BLMvNrwXkvJ2qy6ZoRhkn27ZOL8IIufNdTM5CuvAnR4i8jrlZKNMcWlCowxia1FQjeizyw+nmkNBte1F0VrHrz0hw63cYegtvZkrNZh2ivbOraSJcu+/nHCj3KjUeoTPcpsFmO+cdbNit3zXKMC7qAnhZJvni+pQUtqpZV0wH1lvxbo6zkKxgfTLsy4OITtA6c676rezPV907LfSzN9p3Iu79dIfBvyI7avTn8jf4QedJ/Xx7g3CNp0DwIQHo5i8pSFx65HdlUBPnj0s 0c90DRiP obXpFaNVLmZY1c+H5FOpT1lcCS6FrNc0z6QNIWbkGBv8/jk3+Hbyt1tTXA5t6KkEiHnHGJXA3pxyoQauHHVBQReEYf1htYAc0k98VSOHT1gTSFr+H+FdmkXlf/YFjQDIZPFtBPPftfKmgGkAXjI7xtJDL+M1l1v1zuUoRsKFHAfHN09c01xzJAB8fDQL5MiVKKoUW+ViW4jq+0vWmMzytQQxDI0HnKjyLJZcGzNqu/BkO1MrKPPjwGh7nFYR3qiGPh01PG7NqJx4r1FS3huDJc8zzKw== 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: List-Subscribe: List-Unsubscribe: Hi all, This is a stab at fixing the iomap zero range problem where it doesn't correctly handle the case of an unwritten mapping with dirty pagecache. The gist is that we scan the mapping for dirty cache, zero any already-dirty folios via buffered writes as normal, but then otherwise skip clean ranges once we have a chance to validate those ranges against races with writeback or reclaim. This is somewhat simplistic in terms of how it scans, but that is intentional based on the existing use cases for zero range. From poking around a bit, my current sense is that there isn't any user of zero range that would ever expect to see more than a single dirty folio. Most callers either straddle the EOF folio or flush in higher level code for presumably (fs) context specific reasons. If somebody has an example to the contrary, please let me know because I'd love to be able to use it for testing. The caveat to this approach is that it only works for filesystems that implement folio_ops->iomap_valid(), which is currently just XFS. GFS2 doesn't use ->iomap_valid() and does call zero range, but AFAICT it doesn't actually export unwritten mappings so I suspect this is not a problem. My understanding is that ext4 iomap support is in progress, but I've not yet dug into what that looks like (though I suspect similar to XFS). The concern is mainly that this leaves a landmine for fs that might grow support for unwritten mappings && zero range but not ->iomap_valid(). We'd likely never know zero range was broken for such fs until stale data exposure problems start to materialize. I considered adding a fallback to just add a flush at the top of iomap_zero_range() so at least all future users would be correct, but I wanted to gate that on the absence of ->iomap_valid() and folio_ops isn't provided until iomap_begin() time. I suppose another way around that could be to add a flags param to iomap_zero_range() where the caller could explicitly opt out of a flush, but that's still kind of ugly. I dunno, maybe better than nothing..? So IMO, this raises the question of whether this is just unnecessarily overcomplicated. The KISS principle implies that it would also be perfectly fine to do a conditional "flush and stale" in zero range whenever we see the combination of an unwritten mapping and dirty pagecache (the latter checked before or during ->iomap_begin()). That's simple to implement and AFAICT would work/perform adequately and generically for all filesystems. I have one or two prototypes of this sort of thing if folks want to see it as an alternative. Otherwise, this series has so far seen some light regression and targeted testing. Patches 1-2 are factoring dependencies, patch 3 implements the main fix, and patch 4 drops the flush from XFS truncate. Thoughts, reviews, flames appreciated. Brian Brian Foster (4): filemap: return pos of first dirty folio from range_has_writeback iomap: refactor an iomap_revalidate() helper iomap: fix handling of dirty folios over unwritten extents xfs: remove unnecessary flush of eof page from truncate fs/iomap/buffered-io.c | 81 ++++++++++++++++++++++++++++++++++------- fs/xfs/xfs_iops.c | 10 ----- include/linux/pagemap.h | 4 +- mm/filemap.c | 8 ++-- 4 files changed, 75 insertions(+), 28 deletions(-)