From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 DCEE530AD00; Tue, 31 Mar 2026 17:07:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774976861; cv=none; b=dAUcSRw+u08GGxL1XOSOP9eE61ZnYDo2jotvv81eP/m/xFdjZ16tq8+xrIhT7S4OwObVBKL6oBtnYib6cSmuX868rKW/b7MVEZ2oA6cwiutNNkUy/thbXUfQ2584Hig++w5dtZBSsKEftVrGJeiGAd6GyzEgSver6y9n0k/g408= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774976861; c=relaxed/simple; bh=pltbn0pyOGFx3zDDqLsqRrchh0Ekdz3mg2lpETr1rII=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IoOrPw4+MHiyktr4W85HTW54WCbokE4Iw5bVtc/Oe+53EiIkqqOu/bxdBRSbM5lRprjhfhIwkv6rwD+ksr0eOlmyb6O3zYPWvHFoi3lJm/Vm5f71PqDmtBUgiP7tBVPOvkn9BRA2xbwGn9Zbj8h9e1EI0NqjWqseP6VjUrEkEj0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=zeSaDoP3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="zeSaDoP3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 72455C19423; Tue, 31 Mar 2026 17:07:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1774976861; bh=pltbn0pyOGFx3zDDqLsqRrchh0Ekdz3mg2lpETr1rII=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=zeSaDoP3/Ba42HqVdHE2Zcc9BlZciOEhp0ScxmoA6w3+mVAplLvM1Rfb57kboUDcd SNg4y630XKg5YyNWgVg7+FRW2Uy0TGKKN599y60NVgaU8b4bPYGDdxz0elcU7pXjEo RFBivhk6FxXIXjjQa6NvO1xK2w+Jg3HaMVTSZNFc= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Gerald Yang , Jan Kara , Theodore Tso , stable@kernel.org Subject: [PATCH 6.18 256/309] ext4: fix stale xarray tags after writeback Date: Tue, 31 Mar 2026 18:22:39 +0200 Message-ID: <20260331161802.995678960@linuxfoundation.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260331161753.468533260@linuxfoundation.org> References: <20260331161753.468533260@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jan Kara commit f4a2b42e78914ff15630e71289adc589c3a8eb45 upstream. There are cases where ext4_bio_write_page() gets called for a page which has no buffers to submit. This happens e.g. when the part of the file is actually a hole, when we cannot allocate blocks due to being called from jbd2, or in data=journal mode when checkpointing writes the buffers earlier. In these cases we just return from ext4_bio_write_page() however if the page didn't need redirtying, we will leave stale DIRTY and/or TOWRITE tags in xarray because those get cleared only in __folio_start_writeback(). As a result we can leave these tags set in mappings even after a final sync on filesystem that's getting remounted read-only or that's being frozen. Various assertions can then get upset when writeback is started on such filesystems (Gerald reported assertion in ext4_journal_check_start() firing). Fix the problem by cycling the page through writeback state even if we decide nothing needs to be written for it so that xarray tags get properly updated. This is slightly silly (we could update the xarray tags directly) but I don't think a special helper messing with xarray tags is really worth it in this relatively rare corner case. Reported-by: Gerald Yang Link: https://lore.kernel.org/all/20260128074515.2028982-1-gerald.yang@canonical.com Fixes: dff4ac75eeee ("ext4: move keep_towrite handling to ext4_bio_write_page()") Signed-off-by: Jan Kara Link: https://patch.msgid.link/20260205092223.21287-2-jack@suse.cz Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman --- fs/ext4/page-io.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) --- a/fs/ext4/page-io.c +++ b/fs/ext4/page-io.c @@ -523,9 +523,15 @@ int ext4_bio_write_folio(struct ext4_io_ nr_to_submit++; } while ((bh = bh->b_this_page) != head); - /* Nothing to submit? Just unlock the folio... */ - if (!nr_to_submit) + if (!nr_to_submit) { + /* + * We have nothing to submit. Just cycle the folio through + * writeback state to properly update xarray tags. + */ + __folio_start_writeback(folio, keep_towrite); + folio_end_writeback(folio); return 0; + } bh = head = folio_buffers(folio);