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 A8D8AC3DA49 for ; Thu, 18 Jul 2024 15:36:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 159F76B008C; Thu, 18 Jul 2024 11:36:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0FD3B6B0092; Thu, 18 Jul 2024 11:36:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB96F6B0093; Thu, 18 Jul 2024 11:36:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 728596B008C for ; Thu, 18 Jul 2024 11:36:18 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id C56D1A59DE for ; Thu, 18 Jul 2024 15:36:17 +0000 (UTC) X-FDA: 82353274794.06.C33AAAD Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177]) by imf22.hostedemail.com (Postfix) with ESMTP id CA920C0028 for ; Thu, 18 Jul 2024 15:36:15 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=toxicpanda-com.20230601.gappssmtp.com header.s=20230601 header.b=xtnxq98F; spf=none (imf22.hostedemail.com: domain of josef@toxicpanda.com has no SPF policy when checking 209.85.219.177) smtp.mailfrom=josef@toxicpanda.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721316955; a=rsa-sha256; cv=none; b=Wl300dk1nZIBm51ESW7zA9JawxYewVdJZIbwSUUh71HcZt9v4FApMJZBDyzMqbwcAP6OpI cAjA2tcJwYI+CykaU/6dEMuB3cxIxA1KEIP+VCEHOKjaGLDbsn6PCITFZ6k6Ip28dVvRL9 HO1bpm3sxQHt8P7L1If96ap2g07yPQ0= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=toxicpanda-com.20230601.gappssmtp.com header.s=20230601 header.b=xtnxq98F; spf=none (imf22.hostedemail.com: domain of josef@toxicpanda.com has no SPF policy when checking 209.85.219.177) smtp.mailfrom=josef@toxicpanda.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721316955; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=7LV3Cxf4q1HjMCIjpb4AGa+AlPw7o2PO+PnWn6lO3j4=; b=47Fqcr39xJCjTZ03tUy32N/VfXzAD5zOUcHLpn5EJN8Q7qFKz7TqDMxseNrJ+rp1boyQSY 1CiMj5yUZ69h6gt1UZX8sv33n7l6Y2XQUas7eYe2e/MPY67vS15s7h7QHiCMfB3n20qzU4 WqnbcLNMgHgJq9eBlWabpImuzcQF9ug= Received: by mail-yb1-f177.google.com with SMTP id 3f1490d57ef6-e02c4983bfaso969086276.2 for ; Thu, 18 Jul 2024 08:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20230601.gappssmtp.com; s=20230601; t=1721316975; x=1721921775; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=7LV3Cxf4q1HjMCIjpb4AGa+AlPw7o2PO+PnWn6lO3j4=; b=xtnxq98Fgh1uJp+4CAh9/9NeV+nBR7NvJoTOxETBPMFUNvHEjZYHZibseWaFuw13Ms NgLmYzY0CfqQl42hUh0YXPvcZn1sBmHxb2zNLyXT9DzJhyfbhyiCZ74ZEb2gBM/n3tqa Ug34p6ReqmY1NJMXX5JAe2o8GP2lH9Zz6DbY2DGk5D8VQN24Yrmb9s0LwOzgcNk2y6Mw IH417zkh8Nzlcn3niZ3WHcI4FZb9UAvAxZf8bbCEjiInJQhw0X7eA/iOSEhMBN0YsVJT i8XEG1qIzRgaFiPODFlEMq0Mth9IZw4oU+si+mcznTThIG/nO8gSw6saM8U5/0zbX3Xr uE9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721316975; x=1721921775; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=7LV3Cxf4q1HjMCIjpb4AGa+AlPw7o2PO+PnWn6lO3j4=; b=LDYQ4uBbX1GUr95zMPXHgITKlhSltJlLWtNHZb42Ye/jNniCFxfSFwe+nCChNo5a+n Xf4pd2TtK3XdI2xyxbJkx8g0RgBj83oDQBjQk7jfpvSQoUwFWp3v1nrry4OWcvXn143c 9Ovr/ileZLoWU+BFWfTjAJyKNWaMaP1s3yDUB9TSO7D8S5egvz9tuSzE3fVpq+s/CHZe mEOqt9UHC/FoN/o//42+8Cy1xwYEXvEHmb80FrzqZp9LqHoNeHzoSkiBd1G+sVw/wOGn D7dt81b70zemzBGMxw1Y4+ABidIjEUrHNn2u+QZjuGI5mNpr/4eRSVvp4Z61nc+7FcyJ oQfQ== X-Forwarded-Encrypted: i=1; AJvYcCVyZ33MNMtx1h+/HWRLJAI9fKzX5a7G0HhJtmXsl3ObOsrC+yoDl1crj+VfYKb5UhaJ9vWPtGl8B3RWvYDvJRwGF2s= X-Gm-Message-State: AOJu0YwNtiO0L3JW+TTlyY1VtUu8ARBhDM6noZQaPLhOgvFiYWKVrW3N eRb1Vjk6bgtTFa7ToJhf02yYMA+60P0GILvpM9Ytwb8cSQjOr9SEAlkZTjOEd3w= X-Google-Smtp-Source: AGHT+IGpQagyNjAu7muByoPHcN4EkCU4xwHhJMJpp2C1+ze2pK7+P/IYq/dWegO6vizWM2XstHbU7g== X-Received: by 2002:a05:6902:2b93:b0:dff:3028:4631 with SMTP id 3f1490d57ef6-e05ed729577mr6768671276.33.1721316974708; Thu, 18 Jul 2024 08:36:14 -0700 (PDT) Received: from localhost (syn-076-182-020-124.res.spectrum.com. [76.182.20.124]) by smtp.gmail.com with ESMTPSA id 3f1490d57ef6-e05feb6949dsm367267276.59.2024.07.18.08.36.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Jul 2024 08:36:14 -0700 (PDT) Date: Thu, 18 Jul 2024 11:36:13 -0400 From: Josef Bacik To: Brian Foster Cc: linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH RFC 0/4] iomap: zero dirty folios over unwritten mappings on zero range Message-ID: <20240718153613.GC2099026@perftesting> References: <20240718130212.23905-1-bfoster@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240718130212.23905-1-bfoster@redhat.com> X-Stat-Signature: yxj91bhprx7gcqj7or71t3hqkwi9x8c9 X-Rspamd-Queue-Id: CA920C0028 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1721316975-25574 X-HE-Meta: U2FsdGVkX1+c5BAfJLCgSZq86uDP9eqjwE+ygLgiWVUxrW4a+mIm2l4HAT1p5oo/BZmlpowpx/s48DuKR06ldBGEEjMpJi2ustOHSGWzN8p4n0X1T8qONpKmOgRgKlEWxTiVbOl9lScKtNQ5tFyv5jIPjoAIOdOpbkDnGpQg8WrBNunqEnBuFXy6aG/HZ18m4fWKQEcJevMJ5eZdcwyUT7I4skfl8Raz0eBU/vzRpDZSasixJ71jKvfrVNKct17KUX9HcqSAQmUBm0G16l5OOLivdhBXArs4jII24jkOFwbgCdtQVOCPNb7hRMFm7EszxUPY9bXvoJ0wdew6KVAHLI6OLYkDVrn6xjbNqkwy/zr5s/iEERklBr/Zw1MHq6ht0xmJnPSR+ljNWAY8fagK71Y1mmVjVtLEfetHv7Ub1MoSUJIhdWfb7ditWQjyZF4Q74i5qQ8JS1EpPybP3KEuVcBP4+GsUw00fBGINviy3/M/pLhNmmsN+DeRyimbEQLRj7tr6z68lFeD8kgEPJQnTURAcFLdhf7CJdg26KPejzcj9AWExMcrYIZt1y1dBxdI5r4jwrfHiaP54HhcEVJJOw6mNaLdeRgsWX3qplJ+ek/4OJXbvfr8L6e8GsAublAKPRztkNjXuFRQgOVUfOdv4yTjPDPcUfGWx2uk1oosBTcMsebl6WJFAtNhDo2VfcQm+SOMMnRe3Y5fL3gy6hC9kesnKW8HmqFAQWhOsu3bDTd34KPS/t+8OEfgiOVl9yune7jfd9qhA7Dxe3nHkXFOQ4WGcCJ/L7xYUw8ZYOqLk2LACqS5ywaNl91vVPdVOYaqIi6F9+QhGjtU4buH+XOn7huXopSb/0JLxwTObJ7YlpkQZJNBk34CbC0yTXpTe85N357YfMI9s+gikMUlCcjwtG2tqYc1wK5AXEN7rpQ9UvOWmD2xRvetboKkv1tBhy98n4klUA/TA30XcVrRVgL z1VyVh/8 lD7cWnqzcEq9rKW5VRLRFcmb5sBV3nudpyJh/vIbujOWUNoqZo3l34pMsTsFDooryIXlxaqcO42tFJ6GaJJ3vDjeRI9uV7Wd3CB/v6ppqfmjHEH8rzMkyIDy2iIlq5Wa1c/tw9Mf5Hvb+WLUraomE1NO52FvNfu/JUIRIREHX3fE++MHDQJc3W4OLPDWkTlZvfSegKXSPrKUNJo058ufi//tg8/bL3YIhPgw0H3uMTH9kI5acMYUmWg9AOH4IOXM7jkdO0bBhEx78p44j6HJspEMCBqxh3IcraVc97CRwbDJXc13hC99Gsgc0PINx1Pa1X9j8jENamWKmABQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.005401, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Jul 18, 2024 at 09:02:08AM -0400, Brian Foster wrote: > 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. I think this is the better approach, otherwise there's another behavior that's gated behind having a callback that other filesystems may not know about and thus have a gap. Additionally do you have a test for this stale data exposure? I think no matter what the solution it would be good to have a test for this so that we can make sure we're all doing the correct thing with zero range. Thanks, Josef