From patchwork Thu Jul 18 13:02:09 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brian Foster X-Patchwork-Id: 13736478 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7ED031DDEA for ; Thu, 18 Jul 2024 13:01:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721307694; cv=none; b=YivLuJrfskI7Ww2JeTi4BNQPJl4w+aAwEVrcDWdzV1nqh4K7pPeRAW8fd9+NhhOrqTR/QfX+mLlHrk5+0yAOllLnX0mE5xb+IHRZT545p8x5taD6K57aqtjlqAkRrgzKB8pn1Bw6fxzjKFZRxsHY1D85NbQI2z7WE2ZPdl0ifV0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721307694; c=relaxed/simple; bh=R2slA10gNRg3+H0XvltJQefma7XhwHawvoEXRcRWd2U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=H5FK+S8SKbimDSllNwLkjuFpn48TCgxWiPmBr0lV2Ospov7hu1wpIt8ndL9DIwJMnLdpLiM5AwiXQLlrb/u6cBX1A9m/G1srA12WhyQn4e1exE7+s8aZxtVbHlA/CgCCTusu1woYxcqKWGdxiVJ5hFze2PlJT85B2Ao8LsqgkI8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=foSnqFR5; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="foSnqFR5" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1721307691; 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: in-reply-to:in-reply-to:references:references; bh=S+BiOiT3LndRWbM8oPe7FzMaXX4t+mACZ2hr5DvtRG4=; b=foSnqFR5ictCzXpDkXRzZWCnsYourmQ+lWA+hLf48XOkLlFdwOJ8t5RBn65xmZ6OhUZJdh R0HvzxDAbBIlidQKzEI5ltvA5fVndRD5woFRxr9FaUUCoFIoqONOjUOe2Z9tNOIkVsMA/c DwNQif/joj+L+5W3oKCJ2/Uvucf6sJs= Received: from mx-prod-mc-01.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-483-9k4PGyEfM4WkITIVpHz-4A-1; Thu, 18 Jul 2024 09:01:29 -0400 X-MC-Unique: 9k4PGyEfM4WkITIVpHz-4A-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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 7BA011955D57; Thu, 18 Jul 2024 13:01:28 +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 768BE19560B2; Thu, 18 Jul 2024 13:01:27 +0000 (UTC) From: Brian Foster To: linux-fsdevel@vger.kernel.org Cc: linux-xfs@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH 1/4] filemap: return pos of first dirty folio from range_has_writeback Date: Thu, 18 Jul 2024 09:02:09 -0400 Message-ID: <20240718130212.23905-2-bfoster@redhat.com> In-Reply-To: <20240718130212.23905-1-bfoster@redhat.com> References: <20240718130212.23905-1-bfoster@redhat.com> Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 The iomap layer has a use case that wants to locate the first dirty or writeback folio in a particular range. filemap_range_has_writeback() already implements this with the exception that it only returns a boolean. Since the _needs_writeback() wrapper is currently the only caller, tweak has_writeback to take a pointer for the starting offset and update it to the offset of the first dirty folio found. Signed-off-by: Brian Foster --- include/linux/pagemap.h | 4 ++-- mm/filemap.c | 8 +++++--- 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h index a0a026d2d244..a15131a3fa12 100644 --- a/include/linux/pagemap.h +++ b/include/linux/pagemap.h @@ -1217,7 +1217,7 @@ int __filemap_add_folio(struct address_space *mapping, struct folio *folio, pgoff_t index, gfp_t gfp, void **shadowp); bool filemap_range_has_writeback(struct address_space *mapping, - loff_t start_byte, loff_t end_byte); + loff_t *start_byte, loff_t end_byte); /** * filemap_range_needs_writeback - check if range potentially needs writeback @@ -1242,7 +1242,7 @@ static inline bool filemap_range_needs_writeback(struct address_space *mapping, if (!mapping_tagged(mapping, PAGECACHE_TAG_DIRTY) && !mapping_tagged(mapping, PAGECACHE_TAG_WRITEBACK)) return false; - return filemap_range_has_writeback(mapping, start_byte, end_byte); + return filemap_range_has_writeback(mapping, &start_byte, end_byte); } /** diff --git a/mm/filemap.c b/mm/filemap.c index 657bcd887fdb..be0a219e8d9e 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -636,13 +636,13 @@ static bool mapping_needs_writeback(struct address_space *mapping) } bool filemap_range_has_writeback(struct address_space *mapping, - loff_t start_byte, loff_t end_byte) + loff_t *start_byte, loff_t end_byte) { - XA_STATE(xas, &mapping->i_pages, start_byte >> PAGE_SHIFT); + XA_STATE(xas, &mapping->i_pages, *start_byte >> PAGE_SHIFT); pgoff_t max = end_byte >> PAGE_SHIFT; struct folio *folio; - if (end_byte < start_byte) + if (end_byte < *start_byte) return false; rcu_read_lock(); @@ -655,6 +655,8 @@ bool filemap_range_has_writeback(struct address_space *mapping, folio_test_writeback(folio)) break; } + if (folio) + *start_byte = folio_pos(folio); rcu_read_unlock(); return folio != NULL; } From patchwork Thu Jul 18 13:02:10 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brian Foster X-Patchwork-Id: 13736479 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 182B71DDEA for ; Thu, 18 Jul 2024 13:01:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721307696; cv=none; b=TRlSeW6J4ChNeVvFVD1tIe3FryC9nlYz4wHeQngwVG3jwmXe117uyqjUt3X7xwAkab20rPPjI2Be1vh7PN4ID2BAeM+i6rSrbOWW0STN2byV8aB1CDMxZoMMq0dF0E99+m5Ic5FJB1FnUmPMg+fSND3Wfzq8vD8SYYbz/pKuFMI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721307696; c=relaxed/simple; bh=tN33hKIpRs5sWw9AsupKYf+uzWW0a95CugBsXTfqRqQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=KeuAXwLKCRDRrBO+VRhFxqywE/vGGNkfwM7PdT7+2Wy5x312cmDIc23op+ewYkWLv1WvZJXjDjs0hDsl5wEJqVDn1e6Mk/UglvWxG77z6eILEjauvgwChgy4aw69sK0kX1U0usdyE4A4Vud9DBEwsKEagkcPHhhnaT480KGXPmg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=aTSWmEuv; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="aTSWmEuv" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1721307693; 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: in-reply-to:in-reply-to:references:references; bh=Ma4I3Wz0WluGWqW9yq9eTuWH2xOM0InZUvlarO3itoQ=; b=aTSWmEuvJJoIV3yE1eNl9C/8Prwa874LNyMdYMeUQgo8Mr+vGtUlgIbF3jfTHybGYZgpsC 2M12hfFO3zlzjpnzak2ko4OGkVPga1horx9r73erz8DDyktodq7y2NYcgBnKsBUFFH/WvA 6WQ28usIVI+/39iwOosniUXR0hyL4+4= Received: from mx-prod-mc-02.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-169-b6B1lnHEPlmv1tDiQhi6rA-1; Thu, 18 Jul 2024 09:01:30 -0400 X-MC-Unique: b6B1lnHEPlmv1tDiQhi6rA-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-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A25B11956088; Thu, 18 Jul 2024 13:01:29 +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 98CB61956046; Thu, 18 Jul 2024 13:01:28 +0000 (UTC) From: Brian Foster To: linux-fsdevel@vger.kernel.org Cc: linux-xfs@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH 2/4] iomap: refactor an iomap_revalidate() helper Date: Thu, 18 Jul 2024 09:02:10 -0400 Message-ID: <20240718130212.23905-3-bfoster@redhat.com> In-Reply-To: <20240718130212.23905-1-bfoster@redhat.com> References: <20240718130212.23905-1-bfoster@redhat.com> Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 The buffered write path revalidates the mapping on each folio lock cycle. If the mapping has changed since the last lookup, the mapping is marked stale and the operation must break back out into the lookup path to update the mapping. The zero range path will need to do something similar for correct handling of dirty folios over unwritten ranges. Factor out the validation callback into a new helper that marks the mapping stale on failure. Signed-off-by: Brian Foster --- fs/iomap/buffered-io.c | 28 ++++++++++++++++++---------- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c index d46558990279..a9425170df72 100644 --- a/fs/iomap/buffered-io.c +++ b/fs/iomap/buffered-io.c @@ -756,6 +756,22 @@ static void __iomap_put_folio(struct iomap_iter *iter, loff_t pos, size_t ret, } } +/* + * Check whether the current mapping of the iter is still valid. If not, mark + * the mapping stale. + */ +static inline bool iomap_revalidate(struct iomap_iter *iter) +{ + const struct iomap_folio_ops *folio_ops = iter->iomap.folio_ops; + bool iomap_valid = true; + + if (folio_ops && folio_ops->iomap_valid) + iomap_valid = folio_ops->iomap_valid(iter->inode, &iter->iomap); + if (!iomap_valid) + iter->iomap.flags |= IOMAP_F_STALE; + return iomap_valid; +} + static int iomap_write_begin_inline(const struct iomap_iter *iter, struct folio *folio) { @@ -768,7 +784,6 @@ static int iomap_write_begin_inline(const struct iomap_iter *iter, static int iomap_write_begin(struct iomap_iter *iter, loff_t pos, size_t len, struct folio **foliop) { - const struct iomap_folio_ops *folio_ops = iter->iomap.folio_ops; const struct iomap *srcmap = iomap_iter_srcmap(iter); struct folio *folio; int status = 0; @@ -797,15 +812,8 @@ static int iomap_write_begin(struct iomap_iter *iter, loff_t pos, * could do the wrong thing here (zero a page range incorrectly or fail * to zero) and corrupt data. */ - if (folio_ops && folio_ops->iomap_valid) { - bool iomap_valid = folio_ops->iomap_valid(iter->inode, - &iter->iomap); - if (!iomap_valid) { - iter->iomap.flags |= IOMAP_F_STALE; - status = 0; - goto out_unlock; - } - } + if (!iomap_revalidate(iter)) + goto out_unlock; if (pos + len > folio_pos(folio) + folio_size(folio)) len = folio_pos(folio) + folio_size(folio) - pos; From patchwork Thu Jul 18 13:02:11 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brian Foster X-Patchwork-Id: 13736480 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2652613D281 for ; Thu, 18 Jul 2024 13:01:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721307697; cv=none; b=GgL//sjv4LOkftPQtiR5mVe87z4a4zahEZRH4Bcp1KPSdYY7NTUZhj/GA/tvvvxreXrlFGEiBoiRXYycQ05rOn+CStSgZI1SPxzXaltR56B6a6CVDirXyyR+is4vca0aqVn/tweeR01TksZabQfQx+mEUnUzH6ZkdIvKnJs1lgM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721307697; c=relaxed/simple; bh=R0ttCVkJiqg1sJadYviwHgpVplEYAU31EcY4SLeC6Q8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=gUBA2loJrHvhB0ScAS9wWBzn5TN1obK037cn5//gbBpiWT6r8UIrFwbqY4Q0qqMll8pEiIrqD3x5OdWhy33UfNDmCNKv1PMrvm6l748V5M3erwkEqaEVe1imrHH+FME1cqH1Q4WymDyuElWkGHPeF5yme52r1kjbVoxKo+VheyA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Twh4v449; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Twh4v449" 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: in-reply-to:in-reply-to:references:references; bh=bx5WayJveBqE7cRKQVT93Q4qPgEATb10VO9hHxn66JQ=; b=Twh4v449LUeCGfGWtkMywqLBb9JMDbqrn2cat+1dQklT6HGWN5yhS8rq+vwrKJJJy6Xmdt f1fXigI4XfYdtvfJXFeZzc+c+X5od+YG0CHcHCuFIMCnVbvRX7knntOfx/D9W718KbV05W iCUHv6WWT80VF3O5G0wMK8bypfaTUa4= 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-505-6HTZOMWZN3qNicmmPh7_1Q-1; Thu, 18 Jul 2024 09:01:31 -0400 X-MC-Unique: 6HTZOMWZN3qNicmmPh7_1Q-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 A8B781955F06; Thu, 18 Jul 2024 13:01:30 +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 A137519560B2; Thu, 18 Jul 2024 13:01:29 +0000 (UTC) From: Brian Foster To: linux-fsdevel@vger.kernel.org Cc: linux-xfs@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH 3/4] iomap: fix handling of dirty folios over unwritten extents Date: Thu, 18 Jul 2024 09:02:11 -0400 Message-ID: <20240718130212.23905-4-bfoster@redhat.com> In-Reply-To: <20240718130212.23905-1-bfoster@redhat.com> References: <20240718130212.23905-1-bfoster@redhat.com> Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 iomap_zero_range() does not correctly handle unwritten mappings with dirty folios in pagecache. It skips unwritten mappings unconditionally as if they were already zeroed, and thus potentially exposes stale data from a previous write if affected folios are not written back before the zero range. Most callers already flush the target range of the zero for unrelated, context specific reasons, so this problem is not necessarily prevalent. The known outliers (in XFS) are file extension via buffered write and truncate. The truncate path issues a flush to work around this iomap problem, but the file extension path does not and thus can expose stale data if current EOF is unaligned and has a dirty folio over an unwritten block. This patch implements a mechanism for making zero range pagecache aware for filesystems that support mapping validation (i.e. folio_ops->iomap_valid()). Instead of just skipping unwritten mappings, scan the corresponding pagecache range for dirty or writeback folios. If found, explicitly zero them via buffered write. Clean or uncached subranges of unwritten mappings are skipped, as before. The quirk with a post-iomap_begin() pagecache scan is that it is racy with writeback and reclaim activity. Even if the higher level code holds the invalidate lock, nothing prevents a dirty folio from being written back, cleaned, and even reclaimed sometime after iomap_begin() returns an unwritten map but before a pagecache scan might find the dirty folio. To handle this situation, we can rely on the fact that writeback completion converts unwritten extents in the fs before writeback state is cleared on the folio. This means that a pagecache scan followed by a mapping revalidate of an unwritten mapping should either find a dirty folio if it exists, or detect a mapping change if a dirty folio did exist and had been cleaned sometime before the scan but after the unwritten mapping was found. If the revalidation succeeds then we can safely assume nothing has been written back and skip the range. If the revalidation fails then we must assume any offset in the range could have been modified by writeback. In other words, we must be particularly careful to make sure that any uncached range we intend to skip does not make it into iter.processed until the mapping is revalidated. Altogether, this allows zero range to handle dirty folios over unwritten extents without needing to flush and wait for writeback completion. Signed-off-by: Brian Foster --- fs/iomap/buffered-io.c | 53 +++++++++++++++++++++++++++++++++++++++--- 1 file changed, 50 insertions(+), 3 deletions(-) diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c index a9425170df72..ea1d396ef445 100644 --- a/fs/iomap/buffered-io.c +++ b/fs/iomap/buffered-io.c @@ -1385,6 +1385,23 @@ iomap_file_unshare(struct inode *inode, loff_t pos, loff_t len, } EXPORT_SYMBOL_GPL(iomap_file_unshare); +/* + * Scan an unwritten mapping for dirty pagecache and return the length of the + * clean or uncached range leading up to it. This is the range that zeroing may + * skip once the mapping is validated. + */ +static inline loff_t +iomap_zero_iter_unwritten(struct iomap_iter *iter, loff_t pos, loff_t length) +{ + struct address_space *mapping = iter->inode->i_mapping; + loff_t fpos = pos; + + if (!filemap_range_has_writeback(mapping, &fpos, length)) + return length; + /* fpos can be smaller if the start folio is dirty */ + return max(fpos, pos) - pos; +} + static loff_t iomap_zero_iter(struct iomap_iter *iter, bool *did_zero) { const struct iomap *srcmap = iomap_iter_srcmap(iter); @@ -1393,16 +1410,46 @@ static loff_t iomap_zero_iter(struct iomap_iter *iter, bool *did_zero) loff_t written = 0; /* already zeroed? we're done. */ - if (srcmap->type == IOMAP_HOLE || srcmap->type == IOMAP_UNWRITTEN) + if (srcmap->type == IOMAP_HOLE) return length; do { struct folio *folio; int status; size_t offset; - size_t bytes = min_t(u64, SIZE_MAX, length); + size_t bytes; + loff_t pending = 0; bool ret; + /* + * Determine the range of the unwritten mapping that is clean in + * pagecache. We can skip this range, but only if the mapping is + * still valid after the pagecache scan. This is because + * writeback may have cleaned folios after the mapping lookup + * but before we were able to find them here. If that occurs, + * then the mapping must now be stale and we must reprocess the + * range. + */ + if (srcmap->type == IOMAP_UNWRITTEN) { + pending = iomap_zero_iter_unwritten(iter, pos, length); + if (pending == length) { + /* no dirty cache, revalidate and bounce as we're + * either done or the mapping is stale */ + if (iomap_revalidate(iter)) + written += pending; + break; + } + + /* + * Found a dirty folio. Update pos/length to point at + * it. written is updated only after the mapping is + * revalidated by iomap_write_begin(). + */ + pos += pending; + length -= pending; + } + + bytes = min_t(u64, SIZE_MAX, length); status = iomap_write_begin(iter, pos, bytes, &folio); if (status) return status; @@ -1422,7 +1469,7 @@ static loff_t iomap_zero_iter(struct iomap_iter *iter, bool *did_zero) pos += bytes; length -= bytes; - written += bytes; + written += bytes + pending; } while (length > 0); if (did_zero) From patchwork Thu Jul 18 13:02:12 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brian Foster X-Patchwork-Id: 13736482 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0C57513D63D for ; Thu, 18 Jul 2024 13:01:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721307698; cv=none; b=BHjvQZi3oxsdN2CjKV/Lu8JyhUyqfvuZ2GOWl6jpVs/1mbte+ZbHclOJzs8KyaWw6bKeuvMnymfhGFVWltCFxcQ9ozqjrDvrgEp1cpx8vEEugxMK7PFCYBLaWIK20ztwZL/y79QXyyw7on4e1OKEn3Llsc6iewHgX1Yfiql4FR8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721307698; c=relaxed/simple; bh=v1ZKdLXLM9suGBhGOVb3oYBWJmJ2zwAEsSPI7Al97kw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=dexnTddcoQ7DuvMCwRjDzqNEDJZXG44GoTlvYd/l5ST7W0SyR+qSLXt+a9ny/E6YSf1KPpZbS2e7ScmecaZzPPEodCla43dUxWS1QEzjc7uQVPi4eH3pkSGXtfhGdQD21OtAR4fnFydTTrAGRLC19bZsz6oW2dXq6HquDwd5xcA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=eV1Ykoc5; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="eV1Ykoc5" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1721307696; 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: in-reply-to:in-reply-to:references:references; bh=bk8WncT64lzd4LgIcFxlqG71mv9F7AOrhpNIyzQF2CI=; b=eV1Ykoc5f7RyMTPO0gTisO1r1KoUWDCKLaYreFq05VRJuA8avsNPSdL7pqN/H8Kn7kXn// SNzjrseLyCL2SgkmYFN296gEohvdE3956ijfHkhgPD30gk6aUNOTp9xrcKz6Mmwriv0BqA Y/jgHIfEWIW51wxpR0Vcrdxzz97UhF8= Received: from mx-prod-mc-02.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-427-7098IFzjMyC3RB2-ZVHpBA-1; Thu, 18 Jul 2024 09:01:32 -0400 X-MC-Unique: 7098IFzjMyC3RB2-ZVHpBA-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-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 9BFC21955D60; Thu, 18 Jul 2024 13:01:31 +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 C565B19560B2; Thu, 18 Jul 2024 13:01:30 +0000 (UTC) From: Brian Foster To: linux-fsdevel@vger.kernel.org Cc: linux-xfs@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH 4/4] xfs: remove unnecessary flush of eof page from truncate Date: Thu, 18 Jul 2024 09:02:12 -0400 Message-ID: <20240718130212.23905-5-bfoster@redhat.com> In-Reply-To: <20240718130212.23905-1-bfoster@redhat.com> References: <20240718130212.23905-1-bfoster@redhat.com> Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 The EOF flush was originally added to work around broken iomap_zero_range() handling of dirty cache over unwritten extents. Now that iomap handles this situation correctly, the flush can be removed. Signed-off-by: Brian Foster --- fs/xfs/xfs_iops.c | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c index ff222827e550..eb0b7a88776d 100644 --- a/fs/xfs/xfs_iops.c +++ b/fs/xfs/xfs_iops.c @@ -862,16 +862,6 @@ xfs_setattr_size( error = xfs_zero_range(ip, oldsize, newsize - oldsize, &did_zeroing); } else { - /* - * iomap won't detect a dirty page over an unwritten block (or a - * cow block over a hole) and subsequently skips zeroing the - * newly post-EOF portion of the page. Flush the new EOF to - * convert the block before the pagecache truncate. - */ - error = filemap_write_and_wait_range(inode->i_mapping, newsize, - newsize); - if (error) - return error; error = xfs_truncate_page(ip, newsize, &did_zeroing); }