From nobody Fri Oct 2 01:09:41 2026 Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 435DF3A7F6E for ; Thu, 6 Aug 2026 16:59:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.175 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035542; cv=none; b=nG1avLHKPB9DW6sL9/GtOaGlx19o3GNS5bIxpSu0chr3F4WikdbN7zE+pMiVScZ9OXDBIsa/uklskS6+XbavQ9oCe1Uf5hgs6dffpc24lR6g7bpLBQn9IqgkZHMeAFZZlvsb8JolHSZCqDc/+Q/JBRdAqIZzKN9n9KmJdhbVUtM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035542; c=relaxed/simple; bh=lzP4aegwZTPCQw0cJ3VVWrrvdN+pa1Cx+PvabTKZT/0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=b48qso+bJOj43D4UuXMg4yV6SdkB7A61eEs6pqBd8i8/U1mlH0QHfLgQaEZJxSS2DVpZ1jNpwsWD50r2TNpDlSDa10g2b+hEChpswzIBC/OrAVGJarkFQBzFA/nSNdDMoXd4MWz17sR8dLpHLCnWKKjOUDeVuGu9js+AykjiHo8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=pfdXrfjU; arc=none smtp.client-ip=209.85.221.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="pfdXrfjU" Received: by mail-vk1-f175.google.com with SMTP id 71dfb90a1353d-5bfa4c51c2aso774884e0c.0 for ; Thu, 06 Aug 2026 09:59:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786035539; x=1786640339; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=l4wawGSh1ayASvpYyyNUW0xG9j87AeVkrycNAPRNAqw=; b=pfdXrfjUkNr+YpIAxW3VGw7zEHPJpnM4qqP0VGAcK90I0ESgxg6n2lugFNQwdGQr6T BPonjuqzbAnVfl63svf4eLuxkOM8AjZFstSyYR77ttZFSv6fdkdle3O99IOdmH1CElSB iKV6emEWyJSIvk63ESopkxAU+GhZZs9+7dHy3ihJB+2VMnH59Zn2+0J9UMJr/Fm56qny b0mH2jjV+v0dSEcOWQsfrix5fOvbg7uZcQR03od6zRbrMdxhcHZm8KtGuiMhCTo5QTB1 cWCVsKV7mOMDB1J1EEj3u5X4aqrbThx0DNb+RyWieF+QBN1OnnNKmKWImgzw+YX75oDp rhiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786035539; x=1786640339; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=l4wawGSh1ayASvpYyyNUW0xG9j87AeVkrycNAPRNAqw=; b=AwTaR1olq5oie5UFWD2fxQNKe4Cl3T1n2b72VivI1AB0U/dFn+6QL3tgZxnSU5lX6F YQ9ZsG3ualOl1jj3+bdhvp7F/xaEU5Rcs+ouWbbeS1ZRZvTW/rKw3L/uBaOyo2l5zbpc asi+M/f7BrKz5Y6R0wT6373+n6QKat52gGEdQZwkvKT+Pv6DWuSGPtFcKRIEx1G4YKDb RxkThpnZrruhegydXi/5dXslSqUCd3c94S7DeiHBmhOw0wiLZXR4fgTKGbXMEsCyrWtL jDxtN0CVVq7qIbiZatr/d11uAwDKGiIIPozureUUvdx/UxqM2JJj7W8eES29cCxs+AdS sGWA== X-Forwarded-Encrypted: i=1; AHgh+RqZ5w9PKBKekHCe+Hz5nn1rIxzbOHtCgVYdQ6x8YxTbdpyDowcUuIFFpclVk/KpQ0zNjfhiwp0BGB1cjVM=@vger.kernel.org X-Gm-Message-State: AOJu0Yzr7BWTe8T1xHF/Rk4gqVEaJ6MOhk2eYNFERpdp+Dq7tLeInvjS GR4gQ/7PWdvZHGPHwzxL8Dls0zO/425YVBO0hdQfe6U2N+nc4Sp+1fcB X-Gm-Gg: AR+sD10UceZ/GbX2rlf05b0J1noxC2ny3du6diLJozqAa3+NTUCWjLJfmZ918DMS42X QeeZje+HXtMqW5WUG8m82hCqjRPV4SAw1gojkDR11WId0KjNTS5oxZtnJK3smtekpLSIYh9T3ZJ szpxnTOHX1q1w1S02PJ+sUH/U8WVyFrRE6DxyfxpqLQOPp1AaxU+fm7gI0OfOR2yIyQ9aZnzpM5 b3XkqPV2AZnyBbbmRqJMRFX31ABNGb6sdfNVC9zxTtcYMQbtK22T95MZVTysQp0rQWvG1Y/MC8i hR3x36e/8aEMcFCBqChGVqSCUdeXcl13Sy8PtgmX117vSaUZf4Smysb8o8zSYm2edwDUEPdyU7H 7o1viS8KFUdfnaS2My1HQLxgYpCJqrmAGWxPXq4ZU+ojXRXIHRaxQ9YpIvK6WMREzGpyfVf+CuQ zOczcE1/Z8eC0oB28DtQ1z4IQzE1XYozty8gSzWRGOeisUvFYsbnrLMkFxiH0hEtK5unxNT8b0D T8rqB4= X-Received: by 2002:a05:6123:2c7:b0:5bd:faa8:74e1 with SMTP id 71dfb90a1353d-5c3d92900f0mr2224979e0c.13.1786035539083; Thu, 06 Aug 2026 09:58:59 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c3d05c594fsm3706321e0c.8.2026.08.06.09.58.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 09:58:58 -0700 (PDT) From: Chao Shi To: Jan Kara , Christian Brauner , Alexander Viro , Matthew Wilcox , linux-fsdevel@vger.kernel.org Cc: Theodore Ts'o , Andreas Dilger , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , Zhang Yi , Zhang Yi , Bob Copeland , Namjae Jeon , Sungjong Seo , Yuezhang Mo , OGAWA Hirofumi , Mark Fasheh , Joel Becker , Joseph Qi , Andreas Gruenbacher , linux-ext4@vger.kernel.org, ocfs2-devel@lists.linux.dev, gfs2@lists.linux.dev, linux-kernel@vger.kernel.org, Chao Shi , Weidong Zhu Subject: [PATCH v2 01/21] buffer_head: Remove b_page Date: Thu, 6 Aug 2026 12:58:24 -0400 Message-ID: X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Matthew Wilcox (Oracle)" All users except bh_offset() have been converted to use b_folio instead. Convert bh_offset() and remove b_page. Signed-off-by: Matthew Wilcox (Oracle) Signed-off-by: Chao Shi Acked-by: Weidong Zhu Reviewed-by: Jan Kara --- include/linux/buffer_head.h | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/include/linux/buffer_head.h b/include/linux/buffer_head.h index fd2c7115c054..699970b4bbf2 100644 --- a/include/linux/buffer_head.h +++ b/include/linux/buffer_head.h @@ -59,10 +59,7 @@ struct address_space; struct buffer_head { unsigned long b_state; /* buffer state bitmap (see above) */ struct buffer_head *b_this_page;/* circular list of page's buffers */ - union { - struct page *b_page; /* the page this bh is mapped to */ - struct folio *b_folio; /* the folio this bh is mapped to */ - }; + struct folio *b_folio; /* the folio this bh is mapped to */ =20 sector_t b_blocknr; /* start block number */ size_t b_size; /* size of mapping */ @@ -172,7 +169,7 @@ static __always_inline int buffer_uptodate(const struct= buffer_head *bh) =20 static inline unsigned long bh_offset(const struct buffer_head *bh) { - return (unsigned long)(bh)->b_data & (page_size(bh->b_page) - 1); + return (unsigned long)(bh)->b_data & (folio_size(bh->b_folio) - 1); } =20 /* If we *know* page->private refers to buffer_heads */ --=20 2.43.0 From nobody Fri Oct 2 01:09:41 2026 Received: from mail-vk1-f179.google.com (mail-vk1-f179.google.com [209.85.221.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 424ED175A6C for ; Thu, 6 Aug 2026 16:59:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.179 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035546; cv=none; b=CAPBqLKlNi5ObaG1tLoXFFR2QJoqRxZbul3F7M5nwDYy650fETNt0xh+26i8vae5bENxIffl2VO9f/VXFXGJtlxHM0m7iTbUEATDvKKSHkyXJLXSR6tHHwEvDjRoJJ1ZpsM78PEMQlpKtz1SmAX27N/Kr5AxKjdhBzNlIyo/Yeo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035546; c=relaxed/simple; bh=hjREzgpzo5QzVUOXcfPLZusIOE1tYvynFiHWCGrfyGs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FuzrohzSIT4q9rMD4uX2ph0ao6GTiz22NE6ZH2gSPz7bLdTzIE9KBBA38NWYJ3pWBu55dTwfkhjOZD0WHVf9F2yLf5NcYkfq0I4UnCiu/lnfTkVlyB4a3lEXlVnY6NvMv8vYkEck2DMmFPr5U+I3upLD/cJ2kyftzGkbNF4r16Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=imPXJnGD; arc=none smtp.client-ip=209.85.221.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="imPXJnGD" Received: by mail-vk1-f179.google.com with SMTP id 71dfb90a1353d-5c3a1d005c5so1364228e0c.1 for ; Thu, 06 Aug 2026 09:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786035543; x=1786640343; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=k3JV3rYlfmcwigTL3Ipqk1+R5zcTkEoUEmgylrQxXIQ=; b=imPXJnGDOfb4roQ+X6WBd7zySacKBqMeFhpwQsWWzyRlY0bzQvWA5tzGbHSSfRTP+O JEPd82BDDRpW7jzNhiWTWvwNPmPOSQavFmTGp9CE1aeHqcHY4m9LcxpVCJLJlUNdtUI2 nqV2DwVMYn9IFLnoNM+UOysnnQNyIigX195mENSEbmcK327WAX2TTMEqZUD30CbrKhwj eJuxvk3MiOmT+reXUY7NlTlF0Goatu5YycGuQieG8stdK2CKx2vf5OEgvqxSMNlRv4+7 DfH/Pan8MtIoDaOpJZTeubjV4mijXnDPKo+NPk9HOoozb3EOGHarp959NPyHPNO+95d5 h90Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786035543; x=1786640343; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=k3JV3rYlfmcwigTL3Ipqk1+R5zcTkEoUEmgylrQxXIQ=; b=ckqtJoB0WRrU7ylX4QynlFXsz8jWMVW9vUdlF6N3Hiy+Yg6iCsrf3qTX1yDCZOCqKy qV9EtlhngP6jIC9YEAk7A61Tax4YD73YgDLLVBYkS2oJUot/UYyeXymYBZOzrhhFWl4h otr7IkUDec2683gJTxQL+Gqu2zRxJ/M9Ua+tdr+OJnreYbIFRUga7ckSO157t4uJ+uQt sk9kKjqB619+2Rs39LPNREBaAZFLyQLVCti0J5JGYbb3XNPIr5Sn2QAFEetqKntk8LpI Cilt3vGGDZ7iROa6QOamC3E0nva5e+MTaUWcv145p3yBK0U2HZd1ZZkvNNIeKoDeWosw 53pA== X-Forwarded-Encrypted: i=1; AHgh+RpCTFHrUGpNAa96kEen12TcS1Qc72IZwqRPpwfe5BunzG9NPABy5b1w1+bhK22FbCdE4yGPmbby10kmoRE=@vger.kernel.org X-Gm-Message-State: AOJu0Yx+eeugXxbtrHObrCzHehhJOj9dl0IpEQKSdW6fA22MxnHaNoez yiLO23CJyOL48i+YH4pjMIGrhc0siaz4dZ8zkQMaJb5SBAWVLaXXj+xX X-Gm-Gg: AR+sD13uRg76O2QO1khLJsEoNiW4NUFixQJaOJdBtH7H+nxUjqnxPpRrCw7WYKZkW5b odtUITrXezCZnbd2AByNsVHuvJ7ADGfbnzug0xBoklI9BD+RH22g8pydG3Eue+mTdtIuohZ7qmy YtE6138uLij1bizLo4sd80sT3T2FKvXElboDmU2mxrjizTTzU/hTl53Pr0UKd8g58yQX3j7SAj7 2qVjpBCTvsK2EnvB1lhMGjh97hu10ZcXjiXiqPrteDAIHHHBQmKJ9v12PghJBVv6RBAhVVWNDNc DhJYrlOHcDzYfjIfHt5toG1xj1htSXWYwYxgXoJMLoxOyhJqFBt/2Sl6m7Sko+mOGf/Xkw/l5+T UIM6EEmR9o6fRAtfJO61ls4Dvyg9uWLTWfh7BuYSDtKPvVMM5Vn4DFJ35g/0hKPcqaaWYwFTZNr b47D8iXhndl25kyV31fSO0sUqYtjg/lb1d7S0Pk1YV4bwF/VNBsDN5vRTXA9bPc/pEiOQsIJsnT OQ+UB0= X-Received: by 2002:a05:6122:8b8d:b0:5bd:ecad:8f80 with SMTP id 71dfb90a1353d-5c3f9e68046mr593111e0c.2.1786035543192; Thu, 06 Aug 2026 09:59:03 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c3d05c594fsm3706321e0c.8.2026.08.06.09.59.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 09:59:02 -0700 (PDT) From: Chao Shi To: Jan Kara , Christian Brauner , Alexander Viro , Matthew Wilcox , linux-fsdevel@vger.kernel.org Cc: Theodore Ts'o , Andreas Dilger , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , Zhang Yi , Zhang Yi , Bob Copeland , Namjae Jeon , Sungjong Seo , Yuezhang Mo , OGAWA Hirofumi , Mark Fasheh , Joel Becker , Joseph Qi , Andreas Gruenbacher , linux-ext4@vger.kernel.org, ocfs2-devel@lists.linux.dev, gfs2@lists.linux.dev, linux-kernel@vger.kernel.org, Chao Shi , Weidong Zhu Subject: [PATCH v2 02/21] buffer: allow a buffer_head to point at memory outside the page cache Date: Thu, 6 Aug 2026 12:58:25 -0400 Message-ID: X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" jbd2 builds a temporary buffer_head to write out the frozen copy of a metadata block, and that copy lives in slab memory. Today jbd2 points the temporary buffer at the slab folio backing it. A slab folio's ->mapping is not an address_space, so anything that follows bh->b_folio->mapping there gets garbage rather than NULL; mark_buffer_write_io_error() does exactly that, and we are about to start calling it on this buffer. Rather than teach every such helper about slab folios, allow bh->b_folio to be NULL and let b_data point straight at the memory. Code that needs the folio has to check. There are two places in this file: - __bh_submit() adds the data by virtual address using bio_add_virt_nofail(), and skips the cgroup accounting: a buffer that is not in the page cache has no owning folio to attribute writeback to. - buffer_set_crypto_ctx() returns early. fscrypt has no interest in a buffer that is not part of a file mapping, which is why it already returns when the folio has no mapping. Nothing sets b_folio to NULL yet, so this patch is a no-op on its own. A buffer_head without a folio is a narrow thing, not a new general capability. Most of the buffer_head API assumes a folio and will fault or corrupt state without one - touch_buffer(), bh_offset(), the async read completion path, and plenty more - so it is up to whoever builds such a buffer to keep it away from all of that. What NULL buys us is that getting it wrong fails loudly instead of quietly following a slab folio's overloaded ->mapping. It is also only valid over memory that is always mapped: buffers over highmem have no permanent kernel virtual address, which is why folio_set_bh() records a folio and an offset instead. Suggested-by: Matthew Wilcox (Oracle) Acked-by: Weidong Zhu Signed-off-by: Chao Shi Reviewed-by: Jan Kara --- fs/buffer.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/fs/buffer.c b/fs/buffer.c index be8b57a635cd..04fcc34e4fa6 100644 --- a/fs/buffer.c +++ b/fs/buffer.c @@ -1099,12 +1099,16 @@ EXPORT_SYMBOL(__bforget); static void buffer_set_crypto_ctx(struct bio *bio, const struct buffer_hea= d *bh, gfp_t gfp_mask) { - const struct address_space *mapping =3D folio_mapping(bh->b_folio); + const struct address_space *mapping; =20 /* * The ext4 journal (jbd2) can submit a buffer_head it directly created - * for a non-pagecache page. fscrypt doesn't care about these. + * for memory that is not in the page cache at all. fscrypt doesn't + * care about these. */ + if (!bh->b_folio) + return; + mapping =3D folio_mapping(bh->b_folio); if (!mapping) return; fscrypt_set_bio_crypt_ctx(bio, mapping->host, @@ -1142,7 +1146,11 @@ static void __bh_submit(struct buffer_head *bh, blk_= opf_t opf, bio->bi_iter.bi_sector =3D bh->b_blocknr * (bh->b_size >> 9); bio->bi_write_hint =3D write_hint; =20 - bio_add_folio_nofail(bio, bh->b_folio, bh->b_size, bh_offset(bh)); + if (bh->b_folio) + bio_add_folio_nofail(bio, bh->b_folio, bh->b_size, + bh_offset(bh)); + else + bio_add_virt_nofail(bio, bh->b_data, bh->b_size); =20 bio->bi_end_io =3D end_bio; bio->bi_private =3D bh; @@ -1152,7 +1160,8 @@ static void __bh_submit(struct buffer_head *bh, blk_o= pf_t opf, =20 if (wbc) { wbc_init_bio(wbc, bio); - wbc_account_cgroup_owner(wbc, bh->b_folio, bh->b_size); + if (bh->b_folio) + wbc_account_cgroup_owner(wbc, bh->b_folio, bh->b_size); } =20 blk_crypto_submit_bio(bio); --=20 2.43.0 From nobody Fri Oct 2 01:09:41 2026 Received: from mail-vk1-f170.google.com (mail-vk1-f170.google.com [209.85.221.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A1927433BA6 for ; Thu, 6 Aug 2026 16:59:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.170 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035552; cv=none; b=qsdBECpccg8sbDL0mQQpTCqXq8yaR/TmS96FVH1t7kH9n154F16v1OPwGZJWSGfUlqDtAWkxvOF9yYLAc+zFQEFkKUDcLHsLIO7kk2fgUxbEQCN1RUzX0HFjt8SlvIWfpVxw5fPQdnyhG866K4CTCOxoSX+dRty99XFRhGBE6g4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035552; c=relaxed/simple; bh=ABYpqZ4wdvX2qJo1aEQHOIyoxUhBwtpPontmC2KZtYA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jOXqyJgHrDxK17o6POEGh9AooIN8JsOQnsDcBfVEuLXHAJd/qA1QmlZqLpVc1nMMMhMi5FYPYO9PsDxkz+AXIZo74/+UBrcY8+aYbbCoHpy6NjMjcewiPLZqsyzK5Til4uCPXmyrpw+Bbt4LjWwZgApQibnsJN6IOzVlVE3EK0U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Tgsa97+b; arc=none smtp.client-ip=209.85.221.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Tgsa97+b" Received: by mail-vk1-f170.google.com with SMTP id 71dfb90a1353d-5bfaa014978so994589e0c.3 for ; Thu, 06 Aug 2026 09:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786035548; x=1786640348; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=lPJc5i9oK410kPZ6pKnGJ863FCeOeeCOTy1FxDFDZ4s=; b=Tgsa97+buIDLWDysMRhBS0mJigTpwqHhvCF8pFIWtY7VQpZH0DRiCT1NJk0M16TO95 /2oNTCwsN5/MC3h8PDRzsvEGKOO1+ewPnetOhOSmpf1xoHmtZkOwXpSbLcttdTbJPUaC 1s9jfJbloJyZSv+mz92li6NMRN19nANKqiWu4MEKjQcpxPCSbiQW7rfw1zCnOL9csz49 sUtbnZoibnjphdGLcJBBILF9U2kn/ERST92komYLPZu3Yf5yBzBKsaXvNK7UIfgZ/VCG 1RX7Ud68QzUEIFP/HtViecbQy7YHdPh8KKWmT8Yb1XZ4BN/gHTxkLFOrMUyMv8ZOjch8 rzbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786035548; x=1786640348; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=lPJc5i9oK410kPZ6pKnGJ863FCeOeeCOTy1FxDFDZ4s=; b=VnX93xwYQyvqL0kvi2t7wrJ6pFhVsgDknPyrSu/OBovYFa4re8pN7m5BVw0fByeh3k tbkIhoH88fWEzbETS3I85fPV2o5Eec+9pG9U154WDXmF8Fn4zXDuQCBWBQo+D7we9UZ0 MLOJ7S2oHVD4gXolajnaqdoCG/RFkAZHIdV1cEm32xsA11Yb2Adrf/XVKGoxV2mqH9bd BW8BGFpt9WSDlSF2gLm5+62qh4q0Sn7Vg3j0H3xREdQqEyA5+6G+sm5QbeSudPQ9E6cq F9ucWkdVi0tB33gmrdJNhBKARKdE5bWZd9ZZLhsj9k1NjF2f9Nag2efI25hWqUVjyqrF MFEg== X-Forwarded-Encrypted: i=1; AHgh+RrPmO07MkdQPZQw1BHsWDVAdhcBLGMfyVd/QjB80HxsBCLI6JlVgAxh8elFeF2zQeZGbF5+f6E42kr80mo=@vger.kernel.org X-Gm-Message-State: AOJu0YwwRI/EyXRcDCdDYDEhQtZI3lN52d7a8mGXHxX+GNgNc2s1Qx7M +0mCtt073E3BNVtdYWm0SagJwxZ54MzEgkZtSyAmF3fN+i515PRR3rjM X-Gm-Gg: AR+sD106VhsgRowYtu2FjUQ4NakrzW0gpcTlYs1tGqdz+nNE2VJSN9luYK8qYEKkiE/ kcaORlETtp3rgO0h+uMo14zm3xWOyoVWNvYMK9VzeyhJEVSs0a2iPQOJ1xPZSBol4jJMr+Nz6QC CkxwicI+Qps6o1Ne+7dlnrDVNQKO/AWPY94yZyB7cxjs2yrl4bFeyWpnWqFFs1ddCBz+/9rlnnV +j4UaW6bIoM9X0EcnPrhCDKmRV5nK0zmpRWgWCC3BG+U8CS1G/dmUwgzcg2UJfcTJ4ddl4/PUTs zk/XEKXsw+7dzw42JU26h1BO0/bNlYhKuEibYDMQDbNdJL4wHW+IxNOqHGEexaAcW3Ai9f0laUx dgDCxzikIpdrvE+NRYvR8CaV0BOCqyNtx4unsEZtUdPZGpSGIThxrd8bCWCrychIg17jolxfYLx tIAixnjgZ1dtSRmZ9FoONt/5s7Bg0zpbU5+sG3rMhCxJkn5NSYWmv0DzJ0kox4dH8h2hewxNGza r6azts= X-Received: by 2002:a05:6122:2191:b0:5c1:2b9a:7cae with SMTP id 71dfb90a1353d-5c3d90fad18mr2103554e0c.6.1786035548364; Thu, 06 Aug 2026 09:59:08 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c3d05c594fsm3706321e0c.8.2026.08.06.09.59.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 09:59:07 -0700 (PDT) From: Chao Shi To: Jan Kara , Christian Brauner , Alexander Viro , Matthew Wilcox , linux-fsdevel@vger.kernel.org Cc: Theodore Ts'o , Andreas Dilger , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , Zhang Yi , Zhang Yi , Bob Copeland , Namjae Jeon , Sungjong Seo , Yuezhang Mo , OGAWA Hirofumi , Mark Fasheh , Joel Becker , Joseph Qi , Andreas Gruenbacher , linux-ext4@vger.kernel.org, ocfs2-devel@lists.linux.dev, gfs2@lists.linux.dev, linux-kernel@vger.kernel.org, Chao Shi , Weidong Zhu Subject: [PATCH v2 03/21] jbd2: point the shadow buffer at the frozen data directly Date: Thu, 6 Aug 2026 12:58:26 -0400 Message-ID: <6140cd23beb88e99f40eaeff4044a16213f6caab.1785951556.git.coshi036@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When a metadata buffer has to be copied out before it can be journalled, jbd2_journal_write_metadata_buffer() writes jh->b_frozen_data rather than the page cache copy. b_frozen_data is kmalloc()ed, so folio_set_bh() makes the shadow buffer point at a slab folio. That is not something the buffer_head layer can reason about. A slab folio overloads ->mapping, so a shadow buffer looks like it belongs to an address_space when it does not. buffer_set_crypto_ctx() already has to work around this, and it is the reason mark_buffer_write_io_error() cannot be called on a shadow buffer today. Point the shadow buffer at the frozen data itself instead: leave b_folio NULL, which it already is out of alloc_buffer_head(), and set b_data. The previous patch taught fs/buffer.c to submit such a buffer. folio_set_bh() is now needed on only one path - the one that journals the page cache copy directly - so it moves there, and new_folio, new_offset and the flag that used to pick between them all go away. The two commit-path checksum helpers reach the shadow buffer's contents through a new kmap_local_bh()/kunmap_local_bh() pair, which handle a buffer with or without a folio. Memory outside the page cache is always mapped, so for those there is nothing to map or unmap. Mapping it anyway would be worse than pointless: with CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP, kmap_local_page() hands back a one page mapping even for such memory, which is not enough for a buffer bigger than a page. Tested with ext4 mounted data=3Djournal,journal_checksum on a metadata_csum filesystem, writing files whose every block begins with the JBD2 magic so that escaping forces the copy-out, then crashing with sysrq-b without unmounting and replaying the journal on the next mount. Recovery completed, the file contents matched, e2fsck -fn was clean, and an instrumented build confirmed the b_folio =3D=3D NULL path was taken. Suggested-by: Matthew Wilcox (Oracle) Acked-by: Weidong Zhu Signed-off-by: Chao Shi Reviewed-by: Jan Kara Tested-by: Luca Weiss # sm7225-fairphone-fp4 Tested-by: Srikanth Aithal Tested-by: Venkat Rao Bagalkote --- fs/jbd2/commit.c | 8 ++++---- fs/jbd2/journal.c | 29 +++++++++++++++++------------ include/linux/buffer_head.h | 29 +++++++++++++++++++++++++++++ 3 files changed, 50 insertions(+), 16 deletions(-) diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c index 3029cb6f6d64..0c85af91f9b2 100644 --- a/fs/jbd2/commit.c +++ b/fs/jbd2/commit.c @@ -330,9 +330,9 @@ static __u32 jbd2_checksum_data(__u32 crc32_sum, struct= buffer_head *bh) char *addr; __u32 checksum; =20 - addr =3D kmap_local_folio(bh->b_folio, bh_offset(bh)); + addr =3D kmap_local_bh(bh); checksum =3D crc32_be(crc32_sum, addr, bh->b_size); - kunmap_local(addr); + kunmap_local_bh(bh, addr); =20 return checksum; } @@ -357,10 +357,10 @@ static void jbd2_block_tag_csum_set(journal_t *j, jou= rnal_block_tag_t *tag, return; =20 seq =3D cpu_to_be32(sequence); - addr =3D kmap_local_folio(bh->b_folio, bh_offset(bh)); + addr =3D kmap_local_bh(bh); csum32 =3D jbd2_chksum(j->j_csum_seed, (__u8 *)&seq, sizeof(seq)); csum32 =3D jbd2_chksum(csum32, addr, bh->b_size); - kunmap_local(addr); + kunmap_local_bh(bh, addr); =20 if (jbd2_has_feature_csum3(j)) tag3->t_checksum =3D cpu_to_be32(csum32); diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c index 09efa337649e..6e05dc47e20a 100644 --- a/fs/jbd2/journal.c +++ b/fs/jbd2/journal.c @@ -327,8 +327,6 @@ int jbd2_journal_write_metadata_buffer(transaction_t *t= ransaction, { int do_escape =3D 0; struct buffer_head *new_bh; - struct folio *new_folio; - unsigned int new_offset; struct buffer_head *bh_in =3D jh2bh(jh_in); journal_t *journal =3D transaction->t_journal; =20 @@ -348,24 +346,31 @@ int jbd2_journal_write_metadata_buffer(transaction_t = *transaction, /* keep subsequent assertions sane */ atomic_set(&new_bh->b_count, 1); =20 + /* + * b_frozen_data is slab memory, not page cache, so when we use it the + * shadow buffer gets no folio at all: b_folio stays NULL from the + * allocation and b_data points straight at the copy. Pointing it at + * the slab folio instead would hand its overloaded ->mapping to + * anything that goes looking for an address_space. + */ + spin_lock(&jh_in->b_state_lock); /* * If a new transaction has already done a buffer copy-out, then * we use that version of the data for the commit. */ if (jh_in->b_frozen_data) { - new_folio =3D virt_to_folio(jh_in->b_frozen_data); - new_offset =3D offset_in_folio(new_folio, jh_in->b_frozen_data); do_escape =3D jbd2_data_needs_escaping(jh_in->b_frozen_data); if (do_escape) jbd2_data_do_escape(jh_in->b_frozen_data); + new_bh->b_data =3D jh_in->b_frozen_data; } else { + struct folio *folio =3D bh_in->b_folio; + unsigned int offset =3D offset_in_folio(folio, bh_in->b_data); char *tmp; char *mapped_data; =20 - new_folio =3D bh_in->b_folio; - new_offset =3D offset_in_folio(new_folio, bh_in->b_data); - mapped_data =3D kmap_local_folio(new_folio, new_offset); + mapped_data =3D kmap_local_folio(folio, offset); /* * Fire data frozen trigger if data already wasn't frozen. Do * this before checking for escaping, as the trigger may modify @@ -379,8 +384,10 @@ int jbd2_journal_write_metadata_buffer(transaction_t *= transaction, /* * Do we need to do a data copy? */ - if (!do_escape) + if (!do_escape) { + folio_set_bh(new_bh, folio, offset); goto escape_done; + } =20 spin_unlock(&jh_in->b_state_lock); tmp =3D kmalloc(bh_in->b_size, GFP_NOFS | __GFP_NOFAIL); @@ -391,7 +398,7 @@ int jbd2_journal_write_metadata_buffer(transaction_t *t= ransaction, } =20 jh_in->b_frozen_data =3D tmp; - memcpy_from_folio(tmp, new_folio, new_offset, bh_in->b_size); + memcpy_from_folio(tmp, folio, offset, bh_in->b_size); /* * This isn't strictly necessary, as we're using frozen * data for the escaping, but it keeps consistency with @@ -400,13 +407,11 @@ int jbd2_journal_write_metadata_buffer(transaction_t = *transaction, jh_in->b_frozen_triggers =3D jh_in->b_triggers; =20 copy_done: - new_folio =3D virt_to_folio(jh_in->b_frozen_data); - new_offset =3D offset_in_folio(new_folio, jh_in->b_frozen_data); jbd2_data_do_escape(jh_in->b_frozen_data); + new_bh->b_data =3D jh_in->b_frozen_data; } =20 escape_done: - folio_set_bh(new_bh, new_folio, new_offset); new_bh->b_size =3D bh_in->b_size; new_bh->b_bdev =3D journal->j_dev; new_bh->b_blocknr =3D blocknr; diff --git a/include/linux/buffer_head.h b/include/linux/buffer_head.h index 699970b4bbf2..20b8fca1abfa 100644 --- a/include/linux/buffer_head.h +++ b/include/linux/buffer_head.h @@ -172,6 +172,35 @@ static inline unsigned long bh_offset(const struct buf= fer_head *bh) return (unsigned long)(bh)->b_data & (folio_size(bh->b_folio) - 1); } =20 +/** + * kmap_local_bh - Map the data of a buffer. + * @bh: The buffer. + * + * Buffers usually live in the page cache, but a few are built over memory + * which is not. Those carry no folio and b_data is already a kernel addr= ess + * which is always mapped, so there is nothing to do for them. Pair with + * kunmap_local_bh(). + * + * Return: A pointer to the buffer's data. + */ +static inline void *kmap_local_bh(const struct buffer_head *bh) +{ + if (!bh->b_folio) + return bh->b_data; + return kmap_local_folio(bh->b_folio, bh_offset(bh)); +} + +/** + * kunmap_local_bh - Unmap the data of a buffer. + * @bh: The buffer. + * @addr: The address returned by kmap_local_bh(). + */ +static inline void kunmap_local_bh(const struct buffer_head *bh, void *add= r) +{ + if (bh->b_folio) + kunmap_local(addr); +} + /* If we *know* page->private refers to buffer_heads */ #define page_buffers(page) \ ({ \ --=20 2.43.0 From nobody Fri Oct 2 01:09:41 2026 Received: from mail-vs1-f41.google.com (mail-vs1-f41.google.com [209.85.217.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7A8593B6C0A for ; Thu, 6 Aug 2026 16:59:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.217.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035554; cv=none; b=n5n6RQ/OpBjcYRfSDTwkRabiirsVLuy2L7+jdTPkyWIS6ytbMMJeguQKCwVjCbTMOgsZ1vBkMr918PXQFyx+RD9/E9zByfk/u9VNIiqou2mk2j7J0x5VFPB8ttfsdN4lBr2T0t1zNwISRRDmqilk17QFL2JqtZ5ToarSxrvVN3w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035554; c=relaxed/simple; bh=nXfjVTs2WwI7r48njT1474MNwTWULNnJflHmHfHsQpo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XFnSVjgGEpseYjjyGn+A02yfsSEIgUkhBhNp5eE7Aov5dLJ68/iBm30cjqsMsEV68GEraBfQJF3xWDZ0U5Gt0i2TxcfgbwUce8DZM8CXJzSkMcPgzZDJOWB6PSQDhG7VWjMx+8BLfYbpgcTDsdB3KQk8mWo53pziAaHJS2ZDuTw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=rCjwZ9ZH; arc=none smtp.client-ip=209.85.217.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rCjwZ9ZH" Received: by mail-vs1-f41.google.com with SMTP id ada2fe7eead31-754ac74c495so704034137.0 for ; Thu, 06 Aug 2026 09:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786035551; x=1786640351; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=/lKy66WaG7+TnlzmHpXjsimPtvzEbNlkmMtBXzg/7M8=; b=rCjwZ9ZHWX41u7MfJ+MryPhCI8vGY/L8sYpgkXPgIfdNOuJ357cyBStukNEZ+WPC8x pKvE1d5mqR9qjiUoJ28Djmysne+CaumKECJBG1EXqQctXaCyGT6voAWXZ0y5Jrtytqha LhG3ndoxi4p32VUIJPd1zRasy5YjXlVop2LKrJr8LAoYUVE36vunoOZ2tmqylhpIQ0Wn +osJFGgG2OWfKyETBj7A+zIP+OLgNlIArcYpTGrtQTfFn1MFg2o7UJNtdMJXJnx9gG0d fEi0+4jSKrpxlc+cagh2eEGliYPxweH1BRLN/nyRwlWiYJ5VebD3a52EhtEdRPTlzK2e QhrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786035551; x=1786640351; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=/lKy66WaG7+TnlzmHpXjsimPtvzEbNlkmMtBXzg/7M8=; b=BzXJirG7JXP5CIYA8++7sI9JTyhmdEQ2UBTpQR9pzp4RCn5Zz2oXCSUe+ZBUYG/eyv 2pGiPXyOAwSisrHZbYythy/8zXzsc/9wtMZTpYAmtpqCZ7qLc85Y6ONK/6A1yemt2AI4 dqZN7zy3fqF/kSMXsYMtQ2Ya9qN3vYe0B7+ksh3vA+EVW+AGp93a9GyyT8Zdg+IomlQH zcOlP1/Q91dINUmFv9sE2YW+qHQS7tCetBSd/g/2/82t4ipWw0hVZajx7qN1URaZLGCY W+yOJ/LjaTnn/bZAsSTviSdMpztIcT3ff2DB1mlHCWseMyCKWh6K2Bri+CI9v8btlbZq NtqQ== X-Forwarded-Encrypted: i=1; AHgh+RrWnrOKM83x/fFKYdrbmqILFknwWMY9NNIbc1q+dCyEJ9nL5HlEZ7dMPMPSVLLwis6VxRjuRlLkjjHMs6Q=@vger.kernel.org X-Gm-Message-State: AOJu0Yz/MFwdLvEBdoxAw6pGMs2qz0+6nkG4/HBiM9m7TkzNhWlGpCcf 1X/6EW9G7/x8H9t3YJyTOIs11ZqOtP7/5RnACXjnr0MSu3T49B7psbOZ X-Gm-Gg: AR+sD11jz/34ySw3gKNj0B3KpPiIXIkZvYNDX+w4UqsSJPaSZ+ov1ZHFmvbOnp0vtsF GDE0FFc01jtMtLnyamxIpE+FBjuhL5srP1CWLfoUO0p459E488ab3bLNnCS3FY7CYrUaZCYj8Iq nBwttqeduhWzkudlULaNmx01Cga/BJGowpUZjSXynSJhw/SuFfyEcIWmoyv+x+pKIZfyzeDf7+S P5AapOudQGxlnyc8DZd/Uw0e7Nyxr9tIpBvyR+IjR+QEMVIa0yAMJKjZc0HVEkyqE2jyTvAD4kQ 9And3v7zsxNe41GvG//RFcd6TU4oMKWZCxkz69c8XAkroUDmd154n712Qd097b2aUVdDi8WAu2g o+cQ1/EjrYLWo6epwAIXcl1VoUQEQanSjen4Z6iluXYCGoEXdos12sTwAtSNCrPiFzp/7aV7yxb df21OdBp3JPw54GA9Au5I6K16jLOjbCvva5rhatAxAhF5fG0yuR0wKwIp9WQHy+YYaTrhcyq68C FiunmY= X-Received: by 2002:a05:6102:f09:b0:6f0:3ba3:7d84 with SMTP id ada2fe7eead31-760e77f0ff5mr4020392137.5.1786035551228; Thu, 06 Aug 2026 09:59:11 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c3d05c594fsm3706321e0c.8.2026.08.06.09.59.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 09:59:10 -0700 (PDT) From: Chao Shi To: Jan Kara , Christian Brauner , Alexander Viro , Matthew Wilcox , linux-fsdevel@vger.kernel.org Cc: Theodore Ts'o , Andreas Dilger , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , Zhang Yi , Zhang Yi , Bob Copeland , Namjae Jeon , Sungjong Seo , Yuezhang Mo , OGAWA Hirofumi , Mark Fasheh , Joel Becker , Joseph Qi , Andreas Gruenbacher , linux-ext4@vger.kernel.org, ocfs2-devel@lists.linux.dev, gfs2@lists.linux.dev, linux-kernel@vger.kernel.org, Chao Shi , Weidong Zhu Subject: [PATCH v2 04/21] buffer: read the folio's mapping directly in buffer_set_crypto_ctx() Date: Thu, 6 Aug 2026 12:58:27 -0400 Message-ID: <3fe72ec37bf8491a69031db5f3ba1319da935b97.1785951556.git.coshi036@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" folio_mapping() was doing two jobs here. One was to turn a slab folio into NULL, which is what made this safe for jbd2's shadow buffers; the previous patch removed the need for that by giving those buffers no folio at all. The other is a hazard. folio_mapping() maps a folio in the swap cache to its swap_address_space, so if a buffer_head were ever attached to such a folio this would hand fscrypt a swap mapping and dereference ->host on it. There is no reason to want that here: this path wants the file's mapping or nothing. Read ->mapping directly. Buffers with no folio are already handled above. Suggested-by: Matthew Wilcox (Oracle) Acked-by: Weidong Zhu Signed-off-by: Chao Shi Reviewed-by: Jan Kara --- fs/buffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/buffer.c b/fs/buffer.c index 04fcc34e4fa6..2851830995d8 100644 --- a/fs/buffer.c +++ b/fs/buffer.c @@ -1108,7 +1108,7 @@ static void buffer_set_crypto_ctx(struct bio *bio, co= nst struct buffer_head *bh, */ if (!bh->b_folio) return; - mapping =3D folio_mapping(bh->b_folio); + mapping =3D bh->b_folio->mapping; if (!mapping) return; fscrypt_set_bio_crypt_ctx(bio, mapping->host, --=20 2.43.0 From nobody Fri Oct 2 01:09:41 2026 Received: from mail-vk1-f172.google.com (mail-vk1-f172.google.com [209.85.221.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0C85846A60A for ; Thu, 6 Aug 2026 16:59:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035556; cv=none; b=myAcqzGuLzWgPhsiKiQmum2EIxz52OozlaFR13E+XEZLe2iIwXv6oyW7QKHtBdKd77HFPTNF9x6hyUs3jEnbs4ixf5RwAmhyaZ8t1ugo4g2YbXAxXxtGt8sG9wSDLu/h8Lcdx3idtX2QJYTLHeeB8gYdbS8uRGsFs7khYFS1oxU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035556; c=relaxed/simple; bh=5Z1GSiO2bc0sbRA3/0yuB6INnEL0uS+pxP2xPMYMvWY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=O7Z0SvrJNV9Y0z5EE+XWI1OXIC6lWGzC1hkwCwMMDQmZ2VbFd4BgyQbTjkfPSgErWC8swc9mradHRI0u1zYrlDQ/ljk8/m/+37lVibJ6hdEwh59n2e1VLEnaPqx9o+EaeFtnFCC68EAgXYzsNdBj4udCkKZAmS/04WwofQpGSog= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=qk37Wmp/; arc=none smtp.client-ip=209.85.221.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="qk37Wmp/" Received: by mail-vk1-f172.google.com with SMTP id 71dfb90a1353d-5bf959b820cso1630880e0c.3 for ; Thu, 06 Aug 2026 09:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786035554; x=1786640354; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Ft6ziQssPBfawpI3vOIh0QGxtSEYHeudqaZ7dvpKRmU=; b=qk37Wmp/CtD/1kafq+OBtkVnhWi4T9bibGAL69z78ETPBUq2jUUdtCmYmR9EGWeIkV QA7wAo8NWiYw+DjG+w6Fc3StZRMLlswI6mjhyr1Z586dr69ff56iqFH7+BcHrVDNNQ9l 9OohvovEjMUDchjHqe+AIAQYrpGE2LVban+ffN/loaZ/82ZrvyClcLer5BFWkbgZO5u6 aeJENLErJTWzQpFbkUqWi7zZnacELJv6m/hc3UMcivc6n/WGLLkhBjZS4pssx0lwakkK hxjc1/QOl0yuqP+BeB68Fa6JeN1PL8XuhfQ1aR7/dGLcdpG1C2sLjBu/IsBGiJlcOcTl YmeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786035554; x=1786640354; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=Ft6ziQssPBfawpI3vOIh0QGxtSEYHeudqaZ7dvpKRmU=; b=Cxx0yP7nyYyGNEonGCkwUP8yV5Gv+9IjqvqKeTWeAsBlpoVwMg0Q8Lu4Wo0UkTTgyn K1josU0FpaWpU4qQbMj0l0TGfE1LRw1sUWQHs1CjmtRduhxN6fpY/rovyulIfXZBl9mB OFtyCv0IiOxHNiNxmOno9hauAyINTI971VZJXOFvVIAdvTNZoBWBNC8HZZr+U2uvVGT9 kb293ZMJOwqbjZgMqjU5U4trb1t9Cqd2dTzoxiaouQ/N/9sRjl57hcsRdF82kn0Obf9R RjN1Ywy7Beyee05ztDG0vM2mnKRC6ZK+najr2HSTDafG6R79PJYiGyOinEmw85Nfc1YL Pfkg== X-Forwarded-Encrypted: i=1; AHgh+Rr4hKCMvChhdARxYNiBCzU7SMty0jvduVM5ELoonlEpFUfjSV44nm6jl0LABLcv3OXt6ATozCo+BAqmYZQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yxe/efAdLhTFuuDKTGX/ChIyP+yFc14yA3sFXTnIdepRXyEjgTn 4eHNqjl8/wVl4jsA2MD1AQ4xX3w8XVh/RKh5g5DWbvf5Vg40WCsXMOJR X-Gm-Gg: AR+sD101ulFZmmEBHEO97E4SQ/Y3SjG8haCI9YkHcujPBL8h2aewy1ONPFMTBD/2zhZ Ytk3Taf1Sp+zztR06ytxqeJGR+8raZOZ8kU795Wzm9fIfuoSG8B8da+GxzxB4oayITZVKdrbC+O cY2ALqfB/5cEwBj+BTaKk4IE2EpyM+rEHrah121UCpXnNR9MZbRp97Q9WzaXBxmr58U+ew2VheJ fmfEeJBjTQKi+FbVhqnD4r2Y48oaNVJDb1+2j8nSMyLwN3XhISJV6fXykZ6avVyr8bwCrQTHFmg TMtK+jxCDXdkM/Xkz1AyzyDQIQU3pERY1xy1oTtp3P1rfJKVo0mrJKOuIFpGff1Wz3MU96W8C2P zbeioS1ML28sQgwBlJGrWEoCQgobIuhgiUPcHhzQunpWgd6wXraDl256pF3pqButwcz0W7jFyMs xZ95Man1WZ2DbXGkft1alhziHd1feVkcIxQLKF7hJtmkC+UvozuPQpwoD1EiaX0RVnE5NRq+FPx zzXNQE= X-Received: by 2002:a05:6122:1c85:b0:5bd:8c84:59aa with SMTP id 71dfb90a1353d-5c3d9162e78mr2479549e0c.8.1786035553890; Thu, 06 Aug 2026 09:59:13 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c3d05c594fsm3706321e0c.8.2026.08.06.09.59.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 09:59:13 -0700 (PDT) From: Chao Shi To: Jan Kara , Christian Brauner , Alexander Viro , Matthew Wilcox , linux-fsdevel@vger.kernel.org Cc: Theodore Ts'o , Andreas Dilger , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , Zhang Yi , Zhang Yi , Bob Copeland , Namjae Jeon , Sungjong Seo , Yuezhang Mo , OGAWA Hirofumi , Mark Fasheh , Joel Becker , Joseph Qi , Andreas Gruenbacher , linux-ext4@vger.kernel.org, ocfs2-devel@lists.linux.dev, gfs2@lists.linux.dev, linux-kernel@vger.kernel.org, Chao Shi , Weidong Zhu Subject: [PATCH v2 05/21] buffer: clear BH_Write_EIO when a buffer is forgotten Date: Thu, 6 Aug 2026 12:58:28 -0400 Message-ID: X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" BH_Write_EIO records that the last write of this buffer failed. It is cleared when the buffer is written again, but a filesystem freeing a metadata block never writes it again. It calls bforget() and hands the block back to the allocator, so the flag outlives the block it refers to. That does not matter much today, because the write error is also recorded by clearing BH_Uptodate and the buffer is discarded soon after. It starts to matter in the rest of this series, which stops clearing BH_Uptodate on write error and makes BH_Write_EIO the way a failed metadata write is reported. bforget() is where a filesystem says it no longer cares about this buffer's contents, so clear the error there alongside the dirty flag. Suggested-by: Jan Kara Acked-by: Weidong Zhu Signed-off-by: Chao Shi Reviewed-by: Jan Kara --- fs/buffer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/buffer.c b/fs/buffer.c index 2851830995d8..381690479520 100644 --- a/fs/buffer.c +++ b/fs/buffer.c @@ -1091,6 +1091,7 @@ EXPORT_SYMBOL(__brelse); void __bforget(struct buffer_head *bh) { clear_buffer_dirty(bh); + clear_buffer_write_io_error(bh); remove_assoc_queue(bh); __brelse(bh); } --=20 2.43.0 From nobody Fri Oct 2 01:09:41 2026 Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com [209.85.221.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0499236DA04 for ; Thu, 6 Aug 2026 16:59:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.178 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035565; cv=none; b=IwXFQvSpQ3hk4AsEnzh5hEbZSPosIRzpopFaLnFpEP8Ib/OSXm1LwurUnhxFrF2jemOf0fdPa+jzetQ7UjczZ2DQTOo3hmS5tbimmtj5QrB4D1c+T5BZu+jh5Y45YDmTbJZg2M6QqQjT1zE0QuLPe1kHOsPsSw+G6blAw9vDW1E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035565; c=relaxed/simple; bh=kuaP2Ip3RQshQpbYi/ZOrxn5Jrkw64bBBtC+6NgGKu4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=G/zVPCHiPQfy0Rjogt3yb2+OtmGHB3TywXaiTlddyiIDxuQLn1mKmQFuO6Gb+0C4T2iWvWyqcBEVmQqe04Pcl9r29qj5AHssgZR5SqSt8ZOaRRXOcdbGk5GtlpVaSvadjC0egT2Qxa1qCRoq7/33umLfFX6HJR82cSXrXglx1j8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=S/25BVFC; arc=none smtp.client-ip=209.85.221.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="S/25BVFC" Received: by mail-vk1-f178.google.com with SMTP id 71dfb90a1353d-5c2dbaf828eso857883e0c.0 for ; Thu, 06 Aug 2026 09:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786035563; x=1786640363; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=y4mp7C2u8iNxOV7vEnH4xyJiQARLq+7PYATgmrobvgA=; b=S/25BVFC4tQmExvrcnyrL4T+C1uYJLjrko+D058nwwfiFqQv5R4W5QwuMHJ3X5fpUc p4US9nxxhggMLbHAQQ3aGWJfVlACWXvwV1WGbhC3cFwRkG3KZM1sTvSqYadGrEFPNNWA Bj41weHqHIrica/WvG7zopeKK1gHUcXYJpPRtPm/Fg+IFrMytw81V5pgI6gc3iwIUJ2Y KyI2HDTHgjuQf+hnQ+zpKkfS+f0wYDaM01MNC7CAB2JgbgAfKUmMfvQ/nXZ5O00yIapR N3JE1Dh03CaAA2AlVwXwviKgBWMllrr8q9YavlsLMZA3ix9E2e2jJGAA/PHGfLuzPxbH HUHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786035563; x=1786640363; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=y4mp7C2u8iNxOV7vEnH4xyJiQARLq+7PYATgmrobvgA=; b=Se4EXbk46DBvEo4lMBRd/l4kICXYs1a8ig9HraDDMiwflbeRhZzSpCJjSg1q9jbVNB fAGlp8XTb+pZmfuHyF5DCIEIBpbh8CzYenLPd9kniW1UsuwtHe+rwMR/I2jc8FSrnq2v 0YyryZIfX1MGc4mSctU/6XWazzYPmrLVY07TjbEfA1zkqRSdHPYJ6XkUZEnBohiTzW45 /oflGwsHY/6ljkngx9DsSUtsazs7Vlb0WlxfdfDJvtVgSPNP3NGH3hnX2mC2jWUkpNFV NDvV+Q5PWJB1vxjILZEWHapU0tu4Bxac1aODlk6B8CDG/KdVnpXlWO9G1WVoZ24npB6D CCTQ== X-Forwarded-Encrypted: i=1; AHgh+RrSY+RJjq1lrYRTaKqjTrrtF33poE8JfNwTdDZ+annFPgKuJLFkFTIck4TziTqeeo6xKSK7kkauw8j6mqk=@vger.kernel.org X-Gm-Message-State: AOJu0YzKZrXLCIBJpzD5hdjDa1ehhnEyhhG0aSq3cP0XwLl6DjvEla3f nnjoZDmxQSNXS+158Y3F2RycvdlevDoxaSaTTsjWsNe3SnUzq2nE9GlR X-Gm-Gg: AR+sD12fgI1kDTE37LZE9IhNRrGqzwHKd7iNkS49H8xm+q9954sFRZcP5GKwtDRpDtQ V9lIw1tNK6S7YiVZ8iOjh8MqvPWHMG5R5PKF7SYFCY0vB3NXJhqLkce0Q1IhuIPrsT5SYqIz9pj zJepXHRs5EvYbiJLKdtiKuJSltQQCPR98BtKsDkyP3lyQ2pyJwcWOwxMOO/+HDEQASc/nyxwLZo cu41d+aEFrliUlQtEvcTs8k9rPU4ae2oQ3ABBD5myjKpXkK/N15FYV8tTXKBmXO9keOd5DmWwHI 5kKr0HBqWszk2QbwbB4U8Q0heWINjqaL0v3NcwZ8BogZNsNFIKNZ1oFToXO/V0MapQs1hG96eDz Axud3Tp3ieEUP6oo7uzg7h+hKIGh6AQFTmuclElsNPJJgSqVQjuqqHYNtMfDylU6SWBnQXYs+9r Ffl8zycxOQApAxegyKMlQ2vwqPLIe3H3fSvLiLB4SDryJEV5EZgE5ETfVvjSc5lTKNN9GFnRGLR Nu48I0= X-Received: by 2002:a05:6122:8f88:b0:5bf:b3a0:388c with SMTP id 71dfb90a1353d-5c3d91849cemr2184457e0c.6.1786035562798; Thu, 06 Aug 2026 09:59:22 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c3d05c594fsm3706321e0c.8.2026.08.06.09.59.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 09:59:22 -0700 (PDT) From: Chao Shi To: Jan Kara , Christian Brauner , Alexander Viro , Matthew Wilcox , linux-fsdevel@vger.kernel.org Cc: Theodore Ts'o , Andreas Dilger , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , Zhang Yi , Zhang Yi , Bob Copeland , Namjae Jeon , Sungjong Seo , Yuezhang Mo , OGAWA Hirofumi , Mark Fasheh , Joel Becker , Joseph Qi , Andreas Gruenbacher , linux-ext4@vger.kernel.org, ocfs2-devel@lists.linux.dev, gfs2@lists.linux.dev, linux-kernel@vger.kernel.org, Chao Shi , Weidong Zhu Subject: [PATCH v2 06/21] buffer: discard BH_Write_EIO along with the rest of the buffer state Date: Thu, 6 Aug 2026 12:58:29 -0400 Message-ID: X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" discard_buffer() strips the state that describes where a buffer lives and what has happened to it, because after an invalidate none of it applies any more. BH_Write_EIO belongs in that set for the same reason: it describes a write of the data that is being thrown away. Leaving it set means a buffer_head reused for a different block starts life carrying somebody else's write error. Like the bforget() change, this is mostly theoretical today and becomes load bearing once the rest of the series makes BH_Write_EIO the report of a failed metadata write. Suggested-by: Jan Kara Acked-by: Weidong Zhu Signed-off-by: Chao Shi Reviewed-by: Jan Kara --- fs/buffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/buffer.c b/fs/buffer.c index 381690479520..570ce7f495d3 100644 --- a/fs/buffer.c +++ b/fs/buffer.c @@ -1518,7 +1518,7 @@ EXPORT_SYMBOL(folio_set_bh); /* Bits that are cleared during an invalidate */ #define BUFFER_FLAGS_DISCARD \ (1 << BH_Mapped | 1 << BH_New | 1 << BH_Req | \ - 1 << BH_Delay | 1 << BH_Unwritten) + 1 << BH_Delay | 1 << BH_Unwritten | 1 << BH_Write_EIO) =20 static void discard_buffer(struct buffer_head * bh) { --=20 2.43.0 From nobody Fri Oct 2 01:09:41 2026 Received: from mail-ua1-f50.google.com (mail-ua1-f50.google.com [209.85.222.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1DF0242EED8 for ; Thu, 6 Aug 2026 16:59:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.50 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035568; cv=none; b=F0u/ifneuubyoA5tE5FyO6aE8jkk0bb9AN24cQ8ay109U+Nz/w/xhRSXGxIF7WxkqUjDniOd+KM7pQo07OjqHkLDx74SWSaYNK1fk9tXQYEwzNeWGK9P8/gIxKAjDWNZ8JRXgPzM/Xx6AfffbmF3I7w9vclbR9qW0YDXRgNG1zY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035568; c=relaxed/simple; bh=rnhWvDAamvoYeIKRmdifnx08e4HD3+YvwIOGYnqYA4o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GTNMR7zjvzG5ZjAEi7EbfgcvM1+FHzM8OXWirpnvA8jDuX4yaYa8N1Rknbwc8pIDugf+m5oMR+cXucYHg7yNDxnj7dlFdcTM8OwCqGNivzCOkbOZH8aRefFINWtDA6UaE5cm9p006ZVONNVe6bvkMBJWu6LzFLY4Z5HsmZ/Jbxs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Pou6BHbJ; arc=none smtp.client-ip=209.85.222.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Pou6BHbJ" Received: by mail-ua1-f50.google.com with SMTP id a1e0cc1a2514c-969524c1aefso799227241.3 for ; Thu, 06 Aug 2026 09:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786035566; x=1786640366; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=ByrJwOVSq2vYDCfCPUNcQuCIafVp6X3bai0sLx612mw=; b=Pou6BHbJ8C0nRs23QcGZLdXsAeVbkCeZZUAlD8+PI0C3YMw4ZPeU+ag8R+lUVhQh4Q GktYmqZuFCQq2HPObxCy4z3hHoWjy/Za5rIhwJHGiINyx9zp5p7YCq7o0KmnLXcNVmV4 upodZHe1S0ATqzCNqJLR9JdsSe9M38UH8S5XZgo+nE4u7UjNezwTZyUDdupXb2ywbDCd 9uJszE3xFsH9zUxvw8ek+TkEEAYsuT/Ovt7zg8kzkXgBKmcer2wM+XjgpWKfw6Awgodn VrG95N7ITzH3u7i/kBFsEqQiCwvtYx/xgxVlSKpDXd06zj2ZkKbPLa9RZ7YDf8Jd2k7q AKlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786035566; x=1786640366; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=ByrJwOVSq2vYDCfCPUNcQuCIafVp6X3bai0sLx612mw=; b=HnEdzfns7S4ikL7u1fDTc+RR1juqPuE1zPG5KLtvhnGXKV/OzeubZvwRZTMMMcs8vT lSper5BLE2Pc0xSeZqA9R9fgDpv/DvQH3NTxqc/TEIW3kz9VDWfdg+XX7XNA4QwpQdMc K5vU4UepDFgUM4qafFTH1r5xJaMJ+smOyyAzXbi6NvK+NqczLdSoCy1unL71vlUWti8J VU0xIH6Q23x5i3ywiRLPghSVH9wBy1drb53z4Py0UkiikG4E1cRqu9GEhxJ8htWEY+WX 7GlSaTjeRnPUexoquSS8PROaCFrbtYJFe9AGRg9RNtT7KQvI0EZtmkVMLxbk8rYd5Btj NhFw== X-Forwarded-Encrypted: i=1; AHgh+RpeS7c8/vbc3DzO9+IYXzOvmw2oFNjvQB0sPQYd7GklAv1s68XHXvUwCSsLhILyUmnt86ZJpSm+0VzZiDc=@vger.kernel.org X-Gm-Message-State: AOJu0YxxB2hsjldoJu6wuY5PGmgDPiKpgGfO4tw+ho5aylgF6hGj01nH 8EpGVcQYjvyQ6x34hU5m3/B56lHBp1/3bgrzWyUQFCQ4xKZNsMG0j8Bx X-Gm-Gg: AR+sD10uIr1Bxs9RJJXLgSCRHoSM+ROviqB4lxtKWbTn/kknUy6hGCE/UaHs3l8BQr5 N5nfW6zq2NVtGPqVDp5CmFTz1Gq3JlmVQlTL1raAuwggkuyB3rRJzINfgzFMcK9Goq+tsk72NpX ykt9/uWDeV38AVgJ70CLf1nahmHtkzptKyOLrQVFbiT7qWx36/M7HHtGWizWkFfWT7YaN2Ybry5 1MGGNXg9MUze7r5f2x7GnG7yB+l9gdJ87uJ+hQD+jWKjHM7ju6gkUz6x0uZCdNXcC7OuxWTsz1u /v+fPIxeENiBgwJcgCP2Hes0O0T9YmpH0gj/d47akcrd6tHvQHklBVCsTDhBJANLdmSmn9dRkvs 9QPCTuELl1WvVBgLvg8rHbUNT3Bg1z44rLhQvQBV7f/sCZhqx3YI1/cb2dIrJmonnuYnEcyKlt3 0HVlxbGIzGN6CoJz2pPkEDpu26FahUwxe7ciwAImL7U83ZydB0FEwgrfcE4hKd05ogvh5GYYQyY nsmi9g= X-Received: by 2002:a05:6102:6c7:b0:631:28c1:154c with SMTP id ada2fe7eead31-760e9e4714cmr4097167137.9.1786035565908; Thu, 06 Aug 2026 09:59:25 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c3d05c594fsm3706321e0c.8.2026.08.06.09.59.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 09:59:25 -0700 (PDT) From: Chao Shi To: Jan Kara , Christian Brauner , Alexander Viro , Matthew Wilcox , linux-fsdevel@vger.kernel.org Cc: Theodore Ts'o , Andreas Dilger , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , Zhang Yi , Zhang Yi , Bob Copeland , Namjae Jeon , Sungjong Seo , Yuezhang Mo , OGAWA Hirofumi , Mark Fasheh , Joel Becker , Joseph Qi , Andreas Gruenbacher , linux-ext4@vger.kernel.org, ocfs2-devel@lists.linux.dev, gfs2@lists.linux.dev, linux-kernel@vger.kernel.org, Chao Shi , Weidong Zhu Subject: [PATCH v2 07/21] buffer: detect metadata write errors with buffer_write_io_error() Date: Thu, 6 Aug 2026 12:58:30 -0400 Message-ID: <2b309196b883cc8979800911a47668e225401b2c.1785951556.git.coshi036@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Both places in this file that report a metadata write error to a caller do it by testing !buffer_uptodate() after waiting for the write. That works only because the write completion handlers clear BH_Uptodate when the write fails, which is what this series is removing: a buffer whose write failed still holds the correct data, and saying otherwise makes callers rewrite, re-read or WARN over a buffer that was never wrong. BH_Write_EIO is the flag that actually means "the last write of this buffer failed", and both handlers already set it via mark_buffer_write_io_error(). Test that instead. No behaviour change: today a failed write through bh_end_write() or bh_end_async_write() sets BH_Write_EIO and clears BH_Uptodate together, so the two tests agree. They stop agreeing at the end of the series, and this one stays right. Acked-by: Weidong Zhu Signed-off-by: Chao Shi Reviewed-by: Jan Kara --- fs/buffer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/buffer.c b/fs/buffer.c index 570ce7f495d3..aebf74abbc49 100644 --- a/fs/buffer.c +++ b/fs/buffer.c @@ -618,7 +618,7 @@ int mmb_sync(struct mapping_metadata_bhs *mmb) } spin_unlock(&mmb->lock); wait_on_buffer(bh); - if (!buffer_uptodate(bh)) + if (buffer_write_io_error(bh)) err =3D -EIO; brelse(bh); spin_lock(&mmb->lock); @@ -2743,7 +2743,7 @@ int __sync_dirty_buffer(struct buffer_head *bh, blk_o= pf_t op_flags) =20 bh_submit(bh, REQ_OP_WRITE | op_flags, bh_end_write); wait_on_buffer(bh); - if (!buffer_uptodate(bh)) + if (buffer_write_io_error(bh)) return -EIO; } else { unlock_buffer(bh); --=20 2.43.0 From nobody Fri Oct 2 01:09:41 2026 Received: from mail-vk1-f169.google.com (mail-vk1-f169.google.com [209.85.221.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D4C13483818 for ; Thu, 6 Aug 2026 16:59:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.169 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035573; cv=none; b=shrE4XJTIJqTvZsVLdPVHk/ZYShIxdqk3CsxbofDBjVMVnuswq3RCYwjIxxnV7WHblpAnJCaZ8Gi4yaMcTygMv21HEUZiY3LgNwj6j8zt0xXLsrq4pjsDUgwNLqDtnmGXJnI9mtH6RUS/eXY9L8qap6JpVTe4Vph8z8ieu9kFww= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035573; c=relaxed/simple; bh=XCQvARYs03Jg6cCkHO2H308pJ7dd7LthVfdbsY3TGbk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bbeOt7yTZBT0RgU0Yq0kr0Wc8X3hiSC2ZtcVDfLxBKBXebibVJWrY15PpKUdyBMLLr8CC4i8V0aOC5n84na4U4t2N0d0hdqbpHmch6fsG3TmUTI8kKevEaWs4pkioKobIRXysP06+CNkBLDdUJIrdmyzC2m2/lvuQT1mtXVmrBI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=p3w7NRw3; arc=none smtp.client-ip=209.85.221.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="p3w7NRw3" Received: by mail-vk1-f169.google.com with SMTP id 71dfb90a1353d-5c2dbaf828eso857923e0c.0 for ; Thu, 06 Aug 2026 09:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786035570; x=1786640370; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=W/UkvZ9btqQ9UcKZM3gfiOG/tPkCxSDzu5UxeQemPOo=; b=p3w7NRw3KIrR80GcScsOy40s/lALyhTKudwesZMfKknNR8x1gXe5vHuVU9hYF1ivv2 602Siw/IvGzD55HABAY9E5VZdSrcuK9FRtmtf5zQn5vJIPR1ly4rUvKrjhQ4Ahp5wIqj j2gLgFQgAMDgCS7dwgC70Mua1Ykq8G3ffD/IyyMXXcDfkD91iYLNUdltKI2kDlX2Oy8S NB83SAxhmYB+KCu79bFrerlpRiN/gNyVoHYpub+SIX+s7wgVgnmF68y4lbGEs320s0yk AaAjsSOEbkWaOuDjYG9AsM6JUBT6L1kNvppiOafOzx8encGz0caVWk2TOT9W187BhzwJ xZxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786035570; x=1786640370; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=W/UkvZ9btqQ9UcKZM3gfiOG/tPkCxSDzu5UxeQemPOo=; b=j5uz7vKVXcy71d3uXND4q8l6sswhQP4YP7jV/QHP7+03RDLXk+YP44FM5vnY9pOvmV A/FDvR7Vxk3b0zm6obkHbhzByyrd4kWt2dV720+2vH5u0PaSrjk8fEwaxJLLpvXILN8G TGf4E7XLNCRPvxv1SF0XJ/jmHkhz96tABGJ1ZfZYr/3yjttJoR23t00evRhczwcOa8pJ lVmFTTebX50i1yjm5v2fd6u28H5Q7e3uC0kUZEhUoQiJRbyRlrqIVKrvnKl/VlAmA9pa HOhusddT8r439vwpuH3NBI5ZE2l+w1YDLdZ7CF06LV1AKvFCbXRlru8CObzYsswXt5ax gPVw== X-Forwarded-Encrypted: i=1; AHgh+RqdkGpd7LUCpFLq7HnFD9HsAgR2bhB1fUeFS79uaXFy2UFaq5uzFSFo8sOICG5vgVZ7APLhOEjhIemkMKk=@vger.kernel.org X-Gm-Message-State: AOJu0Yxkg5Mhv4DixuUGQuetjRNkP3dIn8od60ZkdhC5NqNzW6n9+Gg0 I2aA8J9bdvKDY/Qad9Xl99t0hWBKdupa5baK7ndThkioxgAP+0WNtebx X-Gm-Gg: AR+sD12jehc6I/COcYSOrUig8frtY8L5YkJ2t9G2guZlrFn5qPIruMDJ//sFAYhhN+J oAi5cWNLw2GhlyzMWuE3xpQIAr/GAZlLWhiu25SyJjsn8Cq25vTMezT/M4jfCYs1c7ay97NovD4 Is8QqrbSeBVUzOShUPfy28FYmPLp9B0nkmjxpbxO1hcY/0skMdXa2LtHBmL8tXzNhaINlSK7NxY 63II1LsIMd/heDyE2CocVnSAK5Izii3ONqhVSkxmYiNwjmgoRMm+JvxrX0YKuXffh3klAbfctIG 6SdTMOpX2kwB/XhAOXWzDRWCmmi7HEFU5wRjNLiy0W/UJ2zREhC4RvZRrfwbPOJVr0Eo62CWZJi nTDYEzgdOJieOvMYdlTUUdCpS+Kt1vj0MLuvjQgNi2v0kAlXUcMmcc/6dhIrFLKslaXZkpw7/tF pUr4jCEw4uBfsRXg3lZ1k3pgJiC9VRVapTsimARoe79iObPG50YPSy6S/JRNxoEsDaHhS0yuyEZ dHFwfa03Pwep3OJqg== X-Received: by 2002:a05:6122:e248:b0:5bf:9bd1:791 with SMTP id 71dfb90a1353d-5c3d912095cmr2047468e0c.1.1786035569648; Thu, 06 Aug 2026 09:59:29 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c3d05c594fsm3706321e0c.8.2026.08.06.09.59.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 09:59:29 -0700 (PDT) From: Chao Shi To: Jan Kara , Christian Brauner , Alexander Viro , Matthew Wilcox , linux-fsdevel@vger.kernel.org Cc: Theodore Ts'o , Andreas Dilger , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , Zhang Yi , Zhang Yi , Bob Copeland , Namjae Jeon , Sungjong Seo , Yuezhang Mo , OGAWA Hirofumi , Mark Fasheh , Joel Becker , Joseph Qi , Andreas Gruenbacher , linux-ext4@vger.kernel.org, ocfs2-devel@lists.linux.dev, gfs2@lists.linux.dev, linux-kernel@vger.kernel.org, Chao Shi , Weidong Zhu Subject: [PATCH v2 08/21] adfs: check for a directory write error with buffer_write_io_error() Date: Thu, 6 Aug 2026 12:58:31 -0400 Message-ID: <05cf8ad911ad7a6eb68f42e38f1eea39c38e246b.1785951556.git.coshi036@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" adfs_dir_sync() spots a failed write by testing BH_Req together with !BH_Uptodate. That relies on the write completion handler clearing BH_Uptodate on error, which this series removes: a buffer whose write failed still holds the data the filesystem asked to be written, so declaring it not up to date is wrong and makes callers re-read it. BH_Write_EIO says exactly what this code wants to know, and it implies BH_Req, so the pair collapses into one test. No behaviour change today - a failed write sets BH_Write_EIO and clears BH_Uptodate together. It stops being a no-op at the end of the series, where the new test is the one that still works. Acked-by: Weidong Zhu Signed-off-by: Chao Shi Reviewed-by: Jan Kara --- fs/adfs/dir.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/adfs/dir.c b/fs/adfs/dir.c index 11afa9e157aa..b8cc6a697a05 100644 --- a/fs/adfs/dir.c +++ b/fs/adfs/dir.c @@ -191,7 +191,7 @@ static int adfs_dir_sync(struct adfs_dir *dir) for (i =3D dir->nr_buffers - 1; i >=3D 0; i--) { struct buffer_head *bh =3D dir->bhs[i]; sync_dirty_buffer(bh); - if (buffer_req(bh) && !buffer_uptodate(bh)) + if (buffer_write_io_error(bh)) err =3D -EIO; } =20 --=20 2.43.0 From nobody Fri Oct 2 01:09:41 2026 Received: from mail-vk1-f170.google.com (mail-vk1-f170.google.com [209.85.221.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 758D73D9DA8 for ; Thu, 6 Aug 2026 16:59:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.170 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035582; cv=none; b=R5AGvf3iT2WGwKca54Y5b2eybmLPyEk4u3mZJbYJ6s108E5ki1ZujXHH9P9xIybTAqpkfBOs5gPMTv5aFUWL6vX7rJUA7f2k9LwCo7EDDZXp0rU2DIRVXymdXvnT1RbUzJi6dwzwX1Pm4H8h36qFfQQ1Wpe/JHxzdtvz99SESLo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035582; c=relaxed/simple; bh=tpriWxWOl+J6JwWfTTr6TdF9jz0JsOXJvxWyKOuU9Fk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=AVGKwzwsvspARZgjOcfz80U6rDV21mUtzSOcaXEzDC/SWZYXKftbYtKMPwzjjw/BCYsr7yi6izuvx8zUvwz00G8CY6g+AnRZe0DholPDxKb3qqp8NtIG2gmR28YegC4BXE97Tj/UB5676+ObzIExCazDAAzg70ZL26rBmLVdcx4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=bo0d+42b; arc=none smtp.client-ip=209.85.221.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="bo0d+42b" Received: by mail-vk1-f170.google.com with SMTP id 71dfb90a1353d-5c27e38ee18so1233968e0c.1 for ; Thu, 06 Aug 2026 09:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786035579; x=1786640379; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=duwKRHlWbKUb/BOL4rfzAJNO2P4dXrVaNM+8BQLZ4gY=; b=bo0d+42bvRuWcxvl9oRfa245IM6mXsp/UqtsZ81UG6HCbTeG1P+89qWhMg8tJj/TtC I2TEUZCbYsLqS/GjLCMj92lPj2KygZ+5Y5YGbsLsKmEqHGMQxRL8vkOYyPOronlXlGkk l3ZKvlAgM8OuXeMl3nxvjLosaZ00O6z7tkbSRPMkr7t0jhMVXfot1TXvK9W3RujchWgN i13gt9oN58lUIbPpUI2yLkX5chiNtH6AQOHtXPXSmw3KaGjNy5S3ICbPlSC731OCsTwb DGGIWgjIHseapbdUvrjtrpH5Gu9gNUSmiI9YqVOlazDSLSF8anKVNDTHLkKgu8hBZUnt WUaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786035579; x=1786640379; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=duwKRHlWbKUb/BOL4rfzAJNO2P4dXrVaNM+8BQLZ4gY=; b=Eaodikif3dYV2mA7Q5keo/EptJtQcpZ8VmkFGWhG2KwqGagG3Lu3nlDYCFjLtFEys3 733MzwOKjgfI9SRZBZn6NC98GehjMVUfY8u3jRUzQ/CWsyFyOdVh+UevRcKi/AEtz73j z7cNJHar43nqYgG4JRLkpJy6NVBOEVqusGPngBavU/VO3IdP1CvbKvNuXi3ZWIG+NPf3 kFiQ2F9Jr7RUfn8SraFUaSaOe5Mj57PB4I8hUGoEcHRoCRrA9V2YBVfye7Kxa0uuprOi y7ir0iCDH/6w0sfuDaJ7zac5Du3Qx74VA8ka0Orf/jZ/fiTsTZWdRZgOI2ElNAlidXXX AvaQ== X-Forwarded-Encrypted: i=1; AHgh+RpbqsHgxmAgQGD0SGMedGSuPwqNyLIeSubfeHxY9U8UWxTtQx2Vt1sqR6xjI09fw9tFgtnIETqJZsuw/dY=@vger.kernel.org X-Gm-Message-State: AOJu0YwD49q8v47N9FzMB7q0Pgjl6H6ozT7DrOs8lVC9Rq1lSHwuyKfC NMlbs8Lvs+QwT+3ZgEHnnfB9aYxfSO73gBdviINJ2Y3Zdn8Cw91Ot5FU X-Gm-Gg: AR+sD10B8Pgr+HVBxe61wyForIN+VRcGZy5RAojsBzCli1qP9yR8JShnyVG3juLVomI FamlxUxuaJ/xgKKMpj7Afa2X/X9W/JJFXhxamel3GI1qH7jBcwcBq3QXDKhdql+G+X1mXP61wDB Evod4pFje45VZ+QVkA02uN/WMr7qf2lq8oJjSZHJwYh15Q65MZUYJwa7ZfftW8qkr9nys9KVGPI 8cFgd2VpxO+Z6XkUSSR50AbJ+SXgGILsQ6EJFgfWmlfPAeco/LyfSw9TyvQpYNgqqamdUcv6QHn /VY17V4cAU0YP3koyKpxKhw/IaRA+oODJYUgPcR/Gfn7o95A/xoE1X4xO1EoEv8q9tFEslCTH1b kl08KBVrStiaN39VkJ9+ZOXUOeb+oy+XWx0jveFQ0x/v19euyPysi+5+LOiMKLkOxQpl99SLf7X XuV5HGcVAsjxwiEkcS1GMVcd/sZRJmsrvyYh7jHbu7/J0uLcWbj/2wlz1oB2pgp8G2WXykA9ji+ FH6i1D4FgEaBIfrHg== X-Received: by 2002:a05:6122:3d0e:b0:5bd:b27c:bace with SMTP id 71dfb90a1353d-5c3d926476emr2526056e0c.14.1786035579340; Thu, 06 Aug 2026 09:59:39 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c3d05c594fsm3706321e0c.8.2026.08.06.09.59.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 09:59:38 -0700 (PDT) From: Chao Shi To: Jan Kara , Christian Brauner , Alexander Viro , Matthew Wilcox , linux-fsdevel@vger.kernel.org Cc: Theodore Ts'o , Andreas Dilger , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , Zhang Yi , Zhang Yi , Bob Copeland , Namjae Jeon , Sungjong Seo , Yuezhang Mo , OGAWA Hirofumi , Mark Fasheh , Joel Becker , Joseph Qi , Andreas Gruenbacher , linux-ext4@vger.kernel.org, ocfs2-devel@lists.linux.dev, gfs2@lists.linux.dev, linux-kernel@vger.kernel.org, Chao Shi , Weidong Zhu Subject: [PATCH v2 09/21] ext2: check for an xattr block write error with buffer_write_io_error() Date: Thu, 6 Aug 2026 12:58:32 -0400 Message-ID: X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" ext2_xattr_set2() spots a failed synchronous write by testing BH_Req together with !BH_Uptodate. That relies on the write completion handler clearing BH_Uptodate on error, which this series removes: a buffer whose write failed still holds the data the filesystem asked to be written, so declaring it not up to date is wrong and makes callers re-read it. BH_Write_EIO says exactly what this code wants to know, and it implies BH_Req, so the pair collapses into one test. No behaviour change today - a failed write sets BH_Write_EIO and clears BH_Uptodate together. It stops being a no-op at the end of the series, where the new test is the one that still works. Acked-by: Weidong Zhu Signed-off-by: Chao Shi Reviewed-by: Jan Kara --- fs/ext2/xattr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ext2/xattr.c b/fs/ext2/xattr.c index be63f89402a3..39005ec23fe5 100644 --- a/fs/ext2/xattr.c +++ b/fs/ext2/xattr.c @@ -769,7 +769,7 @@ ext2_xattr_set2(struct inode *inode, struct buffer_head= *old_bh, if (IS_SYNC(inode)) { sync_dirty_buffer(new_bh); error =3D -EIO; - if (buffer_req(new_bh) && !buffer_uptodate(new_bh)) + if (buffer_write_io_error(new_bh)) goto cleanup; } } --=20 2.43.0 From nobody Fri Oct 2 01:09:41 2026 Received: from mail-vk1-f180.google.com (mail-vk1-f180.google.com [209.85.221.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D60173B0AE3 for ; Thu, 6 Aug 2026 16:59:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.180 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035592; cv=none; b=lI4Wf4S2/4Wd2pUJDFSpG71SB6rGUcbIz0kJXl0Q+0KeB2KBbdwXmP7+qQdlV7/mF+2u0XoF5rb+iTQ0NBrt6Q/VuOn6khGfVG/gT+9meemXXE6bKxvkLdKzCUAWDX4raIG4wea5qS+UuvGitsJQdvC6RRVUpXMchnKNECRjif8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035592; c=relaxed/simple; bh=oJD4nFEyaXWgVqYToy/GNwtnNE2Mg2QHu3WCWAeSWAs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=txUQjKDmHp8/4Zg4nqVnsNKYKOsyiB7Blr1zCy9tbpYAt2uOOp9eKIL0EI8LUPz+veAGx9UtcGxqrTfYQpIgGNpHmG3QBQbHPlGej+eZiBmSHH6huVdtTrri25m3Uv7bSaXWDNr+qIH/7CNUcOO5FskiQL5nyUAuLtKODBV3aqY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=F4InoYPE; arc=none smtp.client-ip=209.85.221.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="F4InoYPE" Received: by mail-vk1-f180.google.com with SMTP id 71dfb90a1353d-5c3163a88a1so677867e0c.3 for ; Thu, 06 Aug 2026 09:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786035587; x=1786640387; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=i1O4+GTfBoV2V1bEoIh5L2jSUBNvl32w940uX7HvSIA=; b=F4InoYPEd7e4RlzP/rCzVMcbllbtFfDmi4H5AlZl4mehvdu9C6eLjw0+2rrfBHnw8k m/xCJRI93plaouBs7wlDC3LcUu3epffd9nlF5MBl+0Lgq/Yxu163lrMGKqBks2ONRENl rVWlq9pvvs63vIzhmUMVgK17woMEQrkTJGm14fIC6EXHS466O4AwDO3DdUnYnZIQeO1x 9CRcfjVMBROY4ylwdaVX6a1w1qF3kr5ZNYgoFWHHKnH8dbaNAoaPEKAdllMysktMZ3lw ykXd6Kr+y9IaeKi3VfIa+FCCLmP9vIgcuct6iNuWNdBeO82L41MdbGq3wAYRNPKUeBRb QBYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786035587; x=1786640387; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=i1O4+GTfBoV2V1bEoIh5L2jSUBNvl32w940uX7HvSIA=; b=kvXLMVwLnWdcYfShshgNy9415I9/gVRxoDBal8EmtN9zvs+pHZjvw6krCd5TfaggP3 yG68KpRbxLTvPAjxcfq8fBtxCqd9UubhOt0GWE9vIWws31pGj1YZZ0MgScKdQkQ6MFzl TFlq0OfnInYdMiuLKw+akbEJiAOQcken4WPEaLzgwkN1rHc/RZHooKb7ktV16JScGB9e LPdEvBVC5aCTpvyk9j86mR6WPHLPKvUw3z3uJfET3har16RPNzZQUtZaZ9QtY6pq4mwe 7zVXOQ0jRqnhldZnlR+tSR4/0xEAfAgfwUCjtsAKFPZ9lOp9b1bm2Q5O+fBCFzKERlAk frLw== X-Forwarded-Encrypted: i=1; AHgh+Rou4xQ/wbmTJmfQ/G2Mi2b/GgOZuwCSKUUvZWewfTVbD5eN5G9gGJrXJ3vVJ03Bg9wrddr9F94mLvIkIVo=@vger.kernel.org X-Gm-Message-State: AOJu0Ywd6LhIRrtJURfBMyEHnPiw1Y3k6GrIznxdZX3AzphH3DN/Lbc9 4wRpxU5u7zNXhAJeriVpkOVfr9GBLJb8xozrl/WmjQeNv+Az5Vp2OPw7 X-Gm-Gg: AR+sD12GKRBgAr+4GZb62jkSA5sGST1xHmLAhiewvxWUuz53i01YdZMzrJ4Oodf9zEh cgpTUEFA7Tavnk6DX4bPc2VV4MCS51SK16peTaGOfPCcURu4wBCrXdGOCELC8oMsgxOJENoqz/x klz0OgzFearLnfxUxNNpAjXeL/F1I43Pqd++IClFOj1NVzpAJUDKIQ1I5bWdaCy6ATJxRqHoUXs ohH5IFuUAUMDo+5AsLI06qcLDyP8/RgIaqbWX0ebsTQSO3Wx2p5TSraRvN5BnTBzZKHOU7blwmj Y14QvITWl4V5//LdCjLCEAwblcvHOIS1LAXDMlsrbqWy31Fa9qTh6gsPoFDp0CrXdoL7qHu1gH6 gUFi0wsKNkQKbssxQSilSj+0pz9GJ/1KZi9gFpUW8K5bEg89aWE3Z4XrAcBHHVxLCWYLgUuTYnq 7pZnBFpTI8Nz0CgQdA9jrk2wNEzjzgv0HYzL9zEeGur6654273V0XZwsl74F+Do5C0QpKoGs/t5 +k3Kkk= X-Received: by 2002:a05:6122:3a0c:b0:5c2:ac92:eb18 with SMTP id 71dfb90a1353d-5c3d919ab80mr2046889e0c.7.1786035586648; Thu, 06 Aug 2026 09:59:46 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c3d05c594fsm3706321e0c.8.2026.08.06.09.59.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 09:59:45 -0700 (PDT) From: Chao Shi To: Jan Kara , Christian Brauner , Alexander Viro , Matthew Wilcox , linux-fsdevel@vger.kernel.org Cc: Theodore Ts'o , Andreas Dilger , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , Zhang Yi , Zhang Yi , Bob Copeland , Namjae Jeon , Sungjong Seo , Yuezhang Mo , OGAWA Hirofumi , Mark Fasheh , Joel Becker , Joseph Qi , Andreas Gruenbacher , linux-ext4@vger.kernel.org, ocfs2-devel@lists.linux.dev, gfs2@lists.linux.dev, linux-kernel@vger.kernel.org, Chao Shi , Weidong Zhu Subject: [PATCH v2 10/21] omfs: check for an inode write error with buffer_write_io_error() Date: Thu, 6 Aug 2026 12:58:33 -0400 Message-ID: X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" __omfs_write_inode() spots a failed synchronous write, on both the primary block and each mirror, by testing BH_Req together with !BH_Uptodate. That relies on the write completion handler clearing BH_Uptodate on error, which this series removes: a buffer whose write failed still holds the data the filesystem asked to be written, so declaring it not up to date is wrong and makes callers re-read it. BH_Write_EIO says exactly what this code wants to know, and it implies BH_Req, so each pair collapses into one test. No behaviour change today - a failed write sets BH_Write_EIO and clears BH_Uptodate together. It stops being a no-op at the end of the series, where the new test is the one that still works. Acked-by: Weidong Zhu Signed-off-by: Chao Shi Reviewed-by: Jan Kara --- fs/omfs/inode.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/omfs/inode.c b/fs/omfs/inode.c index 1d915ef72119..bc37029a4afb 100644 --- a/fs/omfs/inode.c +++ b/fs/omfs/inode.c @@ -145,7 +145,7 @@ static int __omfs_write_inode(struct inode *inode, int = wait) mark_buffer_dirty(bh); if (wait) { sync_dirty_buffer(bh); - if (buffer_req(bh) && !buffer_uptodate(bh)) + if (buffer_write_io_error(bh)) sync_failed =3D 1; } =20 @@ -159,7 +159,7 @@ static int __omfs_write_inode(struct inode *inode, int = wait) mark_buffer_dirty(bh2); if (wait) { sync_dirty_buffer(bh2); - if (buffer_req(bh2) && !buffer_uptodate(bh2)) + if (buffer_write_io_error(bh2)) sync_failed =3D 1; } brelse(bh2); --=20 2.43.0 From nobody Fri Oct 2 01:09:41 2026 Received: from mail-vk1-f174.google.com (mail-vk1-f174.google.com [209.85.221.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DC902391832 for ; Thu, 6 Aug 2026 16:59:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.174 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035592; cv=none; b=sU9/RdZ79bYCEP3vlyU0xHkTT8bqkKVD3vQYNhHcZjpzRUQDuoAVnuTRU9Lp0e6D34bE2CmpRv668AWmO/CAfOM9pZXcx91JOdHMA/MEOqn/3pSFIQj+OmTHPc4y2csOgeXjv5XtuIZ8fL0dbldJzV39znfviKUTy8qV1or0ZLM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035592; c=relaxed/simple; bh=D13OR5xsYh8JEaA5aDJc/1Dh9iYDdCdoFjWLWDwwfds=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eTAUn01j+i2Ud3DgOIxixakF7ccssj2FMT7MMQwymT7ApZy2qoH0C8N9a1G2oU0SZW9r+i0yF1rL6r6ck0rqKHd3KXnEMWtcf1zFQjaYLyqa/kY5zY6Q7OAy6atRfPBcKgkqjE7vygAYceJWXSr6e16G98o9p54Xaq01z6gtQz8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=JokYjx9r; arc=none smtp.client-ip=209.85.221.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="JokYjx9r" Received: by mail-vk1-f174.google.com with SMTP id 71dfb90a1353d-5bf8e1edc3aso1269478e0c.0 for ; Thu, 06 Aug 2026 09:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786035589; x=1786640389; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Rb7ASnE8Sx91CLFoiOKNMQmqUcK+VC1xbbyNQo6vc/k=; b=JokYjx9rwzZFWo1aPiBFemi/KMNKkCeFR98eUzj2VARFxYoSgnSHz6lfHPqYFh3UPG xkU9PzoHD9JFlml5dt3QPAqdES2lOMfZaDCpOBUruI6n/G91+30AhmsFLXyVhYKKO0rt 5fw3YwAQ87MiwX1ih0+i2crNk0Q2hYOZ/Jg5rTusgajx0KcgW/65Atrk+u84U+XndVD7 mssxHvhLOOhAiqIPyqesfw/qGrGoV5Xki1sHTtVMC5pdHtn8C8KKm067gwz7MDcMcrE9 ktNZoS9earIIfwKs51e3S1AI0RERs8WroyArPj8V0Ef2puUOeb4rveoqyoJ2fYd/LhP3 C7gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786035589; x=1786640389; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=Rb7ASnE8Sx91CLFoiOKNMQmqUcK+VC1xbbyNQo6vc/k=; b=C3FRY6YA63Ggg+VlOyiMeC0oplhSWsQIMBVZ9kX7DdmiOIJyA9QJV5dKtx8SPDQ1bC 4yXhj9pSeOBiHr16HY9Ig+bJi87bQQCUJDQ9SC7NuJvOiLlvIFyIoGzo9PvgL4gN/Fdj JkLlDba0gytr9YqP4F95so5V5gdPQTo59yMWbw8/Wwye9qUnqT2FTAsVuifiwiRdPdwS pK16BHxrkhFG6+QLx1iYXL7qGrbjDTqEBNR5H+/KNCg7EreUshZaObqYruRQO8J9ASzs wnmJ5agXjtyh8r9HZcrHQ2u8fvcQa2OnNAxDNLcnvkHrQXXF3DWGZCXrjdyRwdH+ShSy zsug== X-Forwarded-Encrypted: i=1; AHgh+RonGfKH3y5rnD1PyQTjEEhH3sCUuKNMlsoVYWo+PIDukk2s3WlEW92I+1Jae/E+eNTrfse+tNBdVhQJHxE=@vger.kernel.org X-Gm-Message-State: AOJu0Yx3dss385/q90Gh/qyUA60JRR1HGxjQGX9Vv6ByWScCJwNIe5NI z/vc9KD+Im9fSDCj3npZzR20q7zD5dMrTObzeEVG4Bya4dc6SD14EG1V X-Gm-Gg: AR+sD12pw/H7+MdN944OXC9ZQSzSx70SMwo02STKCIQYad2lpGuNUQJVjYPbQeuRsH0 y1P5aGgyZ/n3wMfVN84UTVHBqwkEs9yE5/9ml/U/uUk1inUjBuw4YpIONq1ULCSnpqFjzB5BNcz DRW5Hjoc8Q01zKwjxw4YiTspPSmudp8HCx+8794aSPizXXd9NeOtD5W/RiILih16jHy+uBRNkn3 J3aUgIC8Cq5svLToC69x+KY6/a45kbUK9JJvI6mD0PhlWEXrM1sw68Mf8SJjnFjEmGqDcBtQn9O rgYPSxaP8rKC8fIuszorY/dWH7VB+PoZKzn7AEOA5FBHiLYmpph6nox97Bf8A2M7Qi3l97eDoTS CB32WUPqgXhfB1Is6iSPNj3emw5LCUjevOqhS2lx6ApRpSSi9ENIUqpYKprneBxB+Wu7sZYma6y itkv5LM8uX22uGyTN4fd95XxT8hH1VO2Z4C0RSafozq1z1ca61jao5CPrycQGCXsBiXdWEb++sV j2ktOM= X-Received: by 2002:a05:6123:2e6:b0:5c2:b8a4:95c9 with SMTP id 71dfb90a1353d-5c3d924e663mr477877e0c.11.1786035589499; Thu, 06 Aug 2026 09:59:49 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c3d05c594fsm3706321e0c.8.2026.08.06.09.59.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 09:59:48 -0700 (PDT) From: Chao Shi To: Jan Kara , Christian Brauner , Alexander Viro , Matthew Wilcox , linux-fsdevel@vger.kernel.org Cc: Theodore Ts'o , Andreas Dilger , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , Zhang Yi , Zhang Yi , Bob Copeland , Namjae Jeon , Sungjong Seo , Yuezhang Mo , OGAWA Hirofumi , Mark Fasheh , Joel Becker , Joseph Qi , Andreas Gruenbacher , linux-ext4@vger.kernel.org, ocfs2-devel@lists.linux.dev, gfs2@lists.linux.dev, linux-kernel@vger.kernel.org, Chao Shi , Weidong Zhu Subject: [PATCH v2 11/21] exfat: check for a directory write error with buffer_write_io_error() Date: Thu, 6 Aug 2026 12:58:34 -0400 Message-ID: <0784ef63a525434e7c0aff730eca7b43e043095d.1785951556.git.coshi036@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" exfat_update_bhs() waits for the writes it issued and then tests !buffer_uptodate() to find the ones that failed. That relies on the write completion handler clearing BH_Uptodate on error, which this series removes: a buffer whose write failed still holds the data the filesystem asked to be written, so declaring it not up to date is wrong and makes callers re-read it. Test BH_Write_EIO, which is what the completion handler sets and what this code actually wants to know. No behaviour change today - a failed write sets BH_Write_EIO and clears BH_Uptodate together. It stops being a no-op at the end of the series, where the new test is the one that still works. Acked-by: Weidong Zhu Signed-off-by: Chao Shi Reviewed-by: Jan Kara --- fs/exfat/misc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/exfat/misc.c b/fs/exfat/misc.c index 6f11a96a4ffa..dfd0bbf31c94 100644 --- a/fs/exfat/misc.c +++ b/fs/exfat/misc.c @@ -187,7 +187,7 @@ int exfat_update_bhs(struct buffer_head **bhs, int nr_b= hs, int sync) =20 for (i =3D 0; i < nr_bhs && sync; i++) { wait_on_buffer(bhs[i]); - if (!err && !buffer_uptodate(bhs[i])) + if (!err && buffer_write_io_error(bhs[i])) err =3D -EIO; } return err; --=20 2.43.0 From nobody Fri Oct 2 01:09:41 2026 Received: from mail-vk1-f181.google.com (mail-vk1-f181.google.com [209.85.221.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1B16847AF49 for ; Thu, 6 Aug 2026 16:59:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.181 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035594; cv=none; b=a2nzvCPHHTzUmC8dhk0DDNS3JalAMKTfxHBH+1zPPLaZpLpjNGB2oMAl926dfppj8bgh8fR0c6xf3KB5mLZSQV1sE7YhI6e6rBiZcj/8hY+d70lzz4JoxNGLg8asMNJBTtXDlz14pmNQq+mauEYS49D0IwHvOp/JrsNQBVAv7n8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035594; c=relaxed/simple; bh=3V2E2gAPInTwE0n7u+WtHxKrTSKd6q7DUDLR8AMb2Ys=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uPipGyXZj42g7pwtmtlH0y/+Y1SXKiBEwL1DGpvi3i/VC4NpPa7HmjvpkA/gErUDloC6I+60r4B2XLvddqZLIjFiEZ0Jk4oiNg9931idwnQxxamT61KVzz2afCD9+DiEPFd7WaouzVk4niTCxWuXPwN6MAivdtiWhqZOIqm8oEI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=TuaoA23D; arc=none smtp.client-ip=209.85.221.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="TuaoA23D" Received: by mail-vk1-f181.google.com with SMTP id 71dfb90a1353d-5c27e38ee18so1234073e0c.1 for ; Thu, 06 Aug 2026 09:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786035592; x=1786640392; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=V2GNnxLBSrWkOcqqCLfBVyKRdpTurr41NHkw8NmYzAw=; b=TuaoA23D0SdIAExb4Gehe+KsbZn2uo5RY+BP4Q0vGRgX2ExuLN67k9MgXIkX1r40DF l+yWKpUCpjw12MnLTpVkWD8dNuH/Q3vlfk/wIL4EfzRid43guZxQDEP+YZH+RPzoPX/0 QPDLW40xqJaExMdwGlKGE4iCXAYD515+z9F3Xt/IO7wm/swnP3OcIh1j466KAgChJ9dq TXfOrTBav1JB+Zpr/FL0hM198idL7VRMhpHHNPQJoZQgWR5AoDdZ0FM6UHQ4vqm0dDjd sCzgQQdEneikW6jmq2UtuosRVwX293K1IYVfVGDvIarGLBMTdIpkXBzdouquMW/f35xS Qhiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786035592; x=1786640392; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=V2GNnxLBSrWkOcqqCLfBVyKRdpTurr41NHkw8NmYzAw=; b=PsUG26Co/tqbFDwdacxdIJLpOHce40gdztWaTJ88UPZQShOg1Bwp6vmIgFL3fPG64c Zyw0X9620UzCTb568Gr6CuYnylHM4hXYDPcH6lN6nngz9M3f/I/yWqAQgygJNMMjaJSs gSBH5a6hLPRKMZzNfPyFgIdrUh8zu1MZOEdN654GIttd48rdz7oEA6qr9fWw4dZwMqgc h1eYVr1rKIKG5d8Q2izXv0OT5PABGXNmglDDhK5wfER877Oc+5M+iPtX0uGglnRn7qzy V9plU7qzswkWHPeoHZOa0Ee0opgYllzUH5TDzKu94ci1dPRYHpBezppkgQ0Cg2HbAIXE o87A== X-Forwarded-Encrypted: i=1; AHgh+Rqr5DvU8bFsVNkymDdOBo6ns7G4frpSplzNicVGQRxL7sW4ItV6JCG+D81wAvo1JGCkXoiq/jgl6t6oj0M=@vger.kernel.org X-Gm-Message-State: AOJu0Yzg/j1ve9SJ53+BtCteWOPnvkOZcAUcw2UeWx/zA/9izH7xAR3E 2FbV6856S2ZhkH15RE44afNcBSG6nVLQ9vOZPuJhkV5E+pHAbQfVbv9x X-Gm-Gg: AR+sD103b2zXashFI+PmNNpBOb9yAmpw2epaQN+OFnV39buz4+6XLVE07wS2IOciXJU GXITMs6o758NETJ+koLTxKGhW98Gc6hx3HFCHhU1cS2XniLi/bXxXMtLxw3kavZPoCehryCudKr RBuWxDVHsVEedAUfmys1b3OIiQWA/eVPc0C80PM6u0X4+CSQJBOcyr5RU8jJL/YWEdTO5Asf22L h+drIDMUm9D5lG99YPEhrvzSz8gmiL9KxVz81jHPWFgIRU4R9HWh7IW6MMHwXmtcfmyPBl64Qde mKXUi4AzXtPy+5pPjMTgYOlpY0O7PkIfMLAoims1cJ5/VNX6KMbU946n/MHcB58Ql1y3Ce9lZ4c 99kcOXPhoGaVm/A6UWph3Aiy+sjxXmeETNOMEciAl7v8irZjDqgPLgcC9EQ+6azbN5Kal5BVdjf Qqwd3ddaD/4NdnNBswXsiY8uXqpaZO9mUIH2sQ02QUkTMpEyh0DM16+lLIv4SEZEieOCyu8gxHu ULhTVKtG0SgjY7NUQ== X-Received: by 2002:a05:6122:179f:b0:5c3:367c:c001 with SMTP id 71dfb90a1353d-5c3d923fa4bmr2401901e0c.12.1786035592033; Thu, 06 Aug 2026 09:59:52 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c3d05c594fsm3706321e0c.8.2026.08.06.09.59.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 09:59:51 -0700 (PDT) From: Chao Shi To: Jan Kara , Christian Brauner , Alexander Viro , Matthew Wilcox , linux-fsdevel@vger.kernel.org Cc: Theodore Ts'o , Andreas Dilger , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , Zhang Yi , Zhang Yi , Bob Copeland , Namjae Jeon , Sungjong Seo , Yuezhang Mo , OGAWA Hirofumi , Mark Fasheh , Joel Becker , Joseph Qi , Andreas Gruenbacher , linux-ext4@vger.kernel.org, ocfs2-devel@lists.linux.dev, gfs2@lists.linux.dev, linux-kernel@vger.kernel.org, Chao Shi , Weidong Zhu Subject: [PATCH v2 12/21] fat: check for a metadata write error with buffer_write_io_error() Date: Thu, 6 Aug 2026 12:58:35 -0400 Message-ID: <4b6019b5a48b83c8235918b084248983a57692e1.1785951556.git.coshi036@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" fat_sync_bhs() waits for the writes it issued and then tests !buffer_uptodate() to find the ones that failed. That relies on the write completion handler clearing BH_Uptodate on error, which this series removes: a buffer whose write failed still holds the data the filesystem asked to be written, so declaring it not up to date is wrong and makes callers re-read it. Test BH_Write_EIO, which is what the completion handler sets and what this code actually wants to know. No behaviour change today - a failed write sets BH_Write_EIO and clears BH_Uptodate together. It stops being a no-op at the end of the series, where the new test is the one that still works. Acked-by: Weidong Zhu Signed-off-by: Chao Shi Reviewed-by: Jan Kara --- fs/fat/misc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/fat/misc.c b/fs/fat/misc.c index be18f6b5819b..4a4cd0111e47 100644 --- a/fs/fat/misc.c +++ b/fs/fat/misc.c @@ -356,7 +356,7 @@ int fat_sync_bhs(struct buffer_head **bhs, int nr_bhs) =20 for (i =3D 0; i < nr_bhs; i++) { wait_on_buffer(bhs[i]); - if (!err && !buffer_uptodate(bhs[i])) + if (!err && buffer_write_io_error(bhs[i])) err =3D -EIO; } return err; --=20 2.43.0 From nobody Fri Oct 2 01:09:41 2026 Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 823C043C078 for ; Thu, 6 Aug 2026 16:59:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.175 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035597; cv=none; b=Vj6vGRL9UB0ZEgKox3aVS/iDtGaruimGxYCiAFpnK7YNiGPNzKeCZVKAXhXq9ZsXv2LKNi+n/R/nrVuEn21R7vBF8/iGRULB0vbai532mTWPgWlzdULYU9Zl1iq2OJ2elFwWippGXNKU666Y6Rq17AvNG5u/JUHq+Y/IvxOgVcY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035597; c=relaxed/simple; bh=PhUfiLl4o8/gnM5dBdAr9/CI3mtr8neFPCeerCnHCbI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GDzXJwgVnvG0iWAjVPS2MeTyXsol29V009xZcrrqzQ2+UNGwGJIqFeNqOHvKQQxJsoCRg4IXsZJ9k7Y6urZjtw0HeeLz47yBeNrJcmPT+tfJX6m2JfP21noPYo/QxGG8fSj1fC5y/LWaayz/YJzhL+M5S7Hbc6qln72vAfoyUq8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=iK9FazpK; arc=none smtp.client-ip=209.85.221.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="iK9FazpK" Received: by mail-vk1-f175.google.com with SMTP id 71dfb90a1353d-5c3a1d005c5so1364825e0c.1 for ; Thu, 06 Aug 2026 09:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786035594; x=1786640394; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=a0eDfGNL18OJWRoQDXpl4mokl45SZAvTsQakbJs+ewI=; b=iK9FazpK4YT7CI/a0908Op2Wo+SMHFr5IcWGldEOkw0g0Vox3sVreDirnyg/dxtMU0 gW85+Bpx3hkC+xU/FrHIVnDFdW34dHo+HXI48f0DCxlSUo35WrRPSWEfAA+SYmnLbDXp Nu1eu9oWwpjwORQtH/uSf6dBIwGrxv/S8PiFdekbqIWvELMz9BzbWbNpucDj14fxow5F rSSmDu39oQkBjwLAMXw0Mt58OhYwU3U2/ncLkH6vX4c/P3i+IhbvliyCwiE0EkrFQZ1q pJrNTtApqq+hGpHlvo//W1F3z3wSZhUhfLkPdM8gA23YuGjr+u/1ip3JIFoaHJq8kQp9 T6JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786035594; x=1786640394; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=a0eDfGNL18OJWRoQDXpl4mokl45SZAvTsQakbJs+ewI=; b=qILcURmIsVKwdhFkO9FAYYgf/SlMdMiXYfbpetPEviVDykoGC0+6Pbvt5srp7zizYu CNPKrcAJlSvmbKbkZYGlQ/1dUWoi7GB8zstI2HVp3iCJKoE85BLKK2VFBNR2+1B0noQE N8uAyClNwXb/Y+vGdq5s5nW8vx1RWRhRCbsgEv2OIzU3yLFgUdNTJJIKz9AofP9PZjNM oJDCKGdmzsKqm6w68nCy98QrmfbjKkPWQfJFpwvxxzKVePPE3wQDgJwYseCwJCeJLzOz rc1zBFPSHUoi2iBv10gode+w+foFdUKBawxYC4n0OhoeKpj3enuIMh6gqyYs0xS5rm46 ELqg== X-Forwarded-Encrypted: i=1; AHgh+RrjCA+PPsumv+eMxhL2IYq9DRhuoPRdk29t592meDcB8cacw4BcskfvtK8fJgIf+1QBOHnStDYP4CQP7Oo=@vger.kernel.org X-Gm-Message-State: AOJu0YzHwJ4meX1vgd2k/q2YrM2eayzQ5iivwNq39POTeTMhdla074dr vRl9wNgY3Deo2++k9BCOKzVzPu4Q1UyX47IXIjvdV/BsCnJdehvzSaPw X-Gm-Gg: AR+sD10ZlLAPn9NxvDiJMlMGtuJ5YPA5zkYB1/ubf/AbFoSWmVho2PZHCeHM9Z4B3D5 4S+lFWLFAK7mj65uTmFj2GbFMvzw2zvW974vV9+c1JnDidjmYk7QMBHQkNn4NRKZhxaRdhgNIL9 NUazElBMa8LsYutmM+c1KNYLuuisYyx/VJKprDJPdcQL3VPhpTWlS+OqJnJVKKmmyU7bUcjdHwS snETgxQtkW4LzpaMcyx6UkDa867NWxDzFYez++Jl0tbub9ZanZIFSI4m6jqREalD1AIT5yTLsgJ h3BkpEppZHHz/vFUA9FwFrxyn+Ov+2nA91dnZV9I5G7wzdHAffrqrTiNFbLQ1aU7FGKBdXbIM9n i/iXIvC0TSr0vRUmU1qMSOkLxL8rTjNZ/+fGT+zF1gNBRkbBIoXx2LpSJDimvietrxnrD7LxuGi Nfj4RZ+fP/GSvHKqxwhRclJ/h30+ZjJ5rMA7XSllCUKSs1b6FpW7mEp2NI7QGIt8esVYZPROQId E1MwfY= X-Received: by 2002:a05:6122:8b8d:b0:5bd:ecad:8f80 with SMTP id 71dfb90a1353d-5c3f9e68046mr593995e0c.2.1786035594156; Thu, 06 Aug 2026 09:59:54 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c3d05c594fsm3706321e0c.8.2026.08.06.09.59.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 09:59:53 -0700 (PDT) From: Chao Shi To: Jan Kara , Christian Brauner , Alexander Viro , Matthew Wilcox , linux-fsdevel@vger.kernel.org Cc: Theodore Ts'o , Andreas Dilger , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , Zhang Yi , Zhang Yi , Bob Copeland , Namjae Jeon , Sungjong Seo , Yuezhang Mo , OGAWA Hirofumi , Mark Fasheh , Joel Becker , Joseph Qi , Andreas Gruenbacher , linux-ext4@vger.kernel.org, ocfs2-devel@lists.linux.dev, gfs2@lists.linux.dev, linux-kernel@vger.kernel.org, Chao Shi , Weidong Zhu Subject: [PATCH v2 13/21] ext4: check for a metadata write error with buffer_write_io_error() Date: Thu, 6 Aug 2026 12:58:36 -0400 Message-ID: <568e57d184da17041872fd4b498f31dd6259a4c1.1785951556.git.coshi036@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Two places detect a failed metadata write by testing !buffer_uptodate() after waiting for it. That relies on the write completion handler clearing BH_Uptodate on error, which this series removes: a buffer whose write failed still holds the data the filesystem asked to be written, so declaring it not up to date is wrong and makes callers re-read it. ext4 already does this correctly for the superblock - see ext4_commit_super(), which tests buffer_write_io_error() - so this brings the other two into line. In __ext4_handle_dirty_metadata() the old test also required BH_Req. BH_Write_EIO implies it, so the pair collapses into one test. The new test is also strictly stronger than consuming sync_dirty_buffer()'s return value, because it still fires when the buffer was written by background writeback and that write hit an error, which sync_dirty_buffer() does not report. Note that the failing write does not clear BH_Write_EIO, so an unrepaired itable block now reports on every subsequent sync of that inode rather than only on the write that failed. That is the intended behaviour, and matches what ocfs2 has always done with this flag. No behaviour change today - a failed write sets BH_Write_EIO and clears BH_Uptodate together. It stops being a no-op at the end of the series, where the new test is the one that still works. Acked-by: Weidong Zhu Signed-off-by: Chao Shi Reviewed-by: Jan Kara --- fs/ext4/ext4_jbd2.c | 2 +- fs/ext4/mmp.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/ext4/ext4_jbd2.c b/fs/ext4/ext4_jbd2.c index 02b066299164..f338d6e3c29f 100644 --- a/fs/ext4/ext4_jbd2.c +++ b/fs/ext4/ext4_jbd2.c @@ -413,7 +413,7 @@ int __ext4_handle_dirty_metadata(const char *where, uns= igned int line, } if (inode && inode_needs_sync(inode)) { sync_dirty_buffer(bh); - if (buffer_req(bh) && !buffer_uptodate(bh)) { + if (buffer_write_io_error(bh)) { ext4_error_inode_err(inode, where, line, bh->b_blocknr, EIO, "IO error syncing itable block"); diff --git a/fs/ext4/mmp.c b/fs/ext4/mmp.c index 7ce361484b38..4b18ddef468d 100644 --- a/fs/ext4/mmp.c +++ b/fs/ext4/mmp.c @@ -49,7 +49,7 @@ static int write_mmp_block_thawed(struct super_block *sb, bh_submit(bh, REQ_OP_WRITE | REQ_SYNC | REQ_META | REQ_PRIO, bh_end_write); wait_on_buffer(bh); - if (unlikely(!buffer_uptodate(bh))) + if (unlikely(buffer_write_io_error(bh))) return -EIO; return 0; } --=20 2.43.0 From nobody Fri Oct 2 01:09:41 2026 Received: from mail-vk1-f172.google.com (mail-vk1-f172.google.com [209.85.221.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4821E485CCA for ; Thu, 6 Aug 2026 16:59:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035599; cv=none; b=fuqWt9EdFSfS8WQNXusFtX+x5nxtFCh+c0RcAbAfE/ZKVvCm27zXlDftBZHXlc0nlJgSOdMb5FnINCvyGBgFd6AJO45//7LtXOwXcJrdvM7eyGXq6c9gzc6XB14ftbOsWQmE223JtQt4TjjADYodkJw6dCoI4gnPEkteL9houoo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035599; c=relaxed/simple; bh=0neISYJFH5vf1iYeHnX8wDVudHaEvy72ntuqHszFLec=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Q9ctOMrkAuWaIH/zlZgpjEGHMY/Pg9EgQtv/qPZImDWz653orYks3ZIuXidvGvYQHoE9kI/R6HBL+tjLAZyG0ZQ7dCr8bNWrW+mH+GMCWt0BlstWsklWKVg/w/ucHmwM4pVx20upwdQXoEJo3wIHCH0tDRH/vcTlkgQBgmwZ95o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=J3fTBh0R; arc=none smtp.client-ip=209.85.221.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="J3fTBh0R" Received: by mail-vk1-f172.google.com with SMTP id 71dfb90a1353d-5c38568d9e1so883634e0c.3 for ; Thu, 06 Aug 2026 09:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786035596; x=1786640396; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=DRJjTotyJT+hr0WWdtFL/ctkn8lHZ3M1r+YQr9eg6EA=; b=J3fTBh0RFlRULbxcBAkmHv7k0HwAUDpVGxIh0ib6BjHpitYK/lQlhSFW4kA2A/zl1s yY/4XLTCHApnP4f0DpfgswegGLdz1Jyp6O2iTiXt91o9fEKa4ru9slUyB9Zj+NTcNUg2 pPaObPPMVj7bBxcGrMhNMENPt3WOD6iQnlqmVhF4jcF+5SmQOJwiDndOpiqn3zUvY+OS e2oJN0tNk3sWBLeXJEj29tnf88O4CPXNIH1iATv4TJnh3wkOocV7kYeC5cidRsQuGf42 SDfeqLRexGlN6OPfaU8hie7YLbDCdztdNO2xgG0QsyLkO7luIv0L6sZXyPWc/3eUBwBm hCaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786035596; x=1786640396; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=DRJjTotyJT+hr0WWdtFL/ctkn8lHZ3M1r+YQr9eg6EA=; b=UHi9i/WHuOHhjyvKzULf+kwgSRoBk//1E+3hC96JsRVskl4+h4fHIM6oC2ayOrL7vd 4z1ICrklFcIXSn5NlGfhb2rzD1n2jOeZ3W0oLXPJbsUgJon6ZgB64hk9l9k4ZJBJ7Ii2 Lr+3KPDecnwLC1+kJ2mO8WNazellxJygUftM0KUbvs40mNjcojURyGoyjt3jFhhJaWmp eXaJNOyrEbvgw6ebu1G6w4923ivIE2hiLH7Y0+yHZ/Od8EMtY+PMvULxnabtj/M7l0ON fM0hKNMmqjFO7f6oY7HDETXwEdnE3umTqQguPDJ8llUj3V/v8khxlwYEADSXcdHXaKdX rEkA== X-Forwarded-Encrypted: i=1; AHgh+RoQ7+MK6soziqfFi4SZVfGoMSQbKldbg3eszLSdlv29G/c/dzAzLgFLiXc7b++98i3jzpD1TZOCfTL4GB8=@vger.kernel.org X-Gm-Message-State: AOJu0Yx+wu42d43+Z7ZI0XBa/5rz1akqFsp0Bj6rFf3BMZMwVAR8y3vG ntI2a6EM4dc5fipesUJsbCCtCSbzX6g6X1J3xZHwZJSaV7P1nRvr9lmU X-Gm-Gg: AR+sD11csq09zXaO+gG4T4TbxwJ0u7I2dufhWEgSM9QQpSlwgbJvdT9lAuEfrtoXCec k4uU33jn3VsQ1PsS/NTP/NS6TxS69V0DLlGU0u9EF+MLptd2V7dPiaoV3czvGJvPBeZMF9I3pIn 2wtjy6YkzL2PnbfBYM3A9MGSu1AyRAd3o7mMo/+Nvl+kJg0vXMSha4rXt9ppqcaQy2Khjl1xw4N cVG8XBM5AkweAyeO6Nrs3ouuAWQ2a3G7UlhhGrcHFxA9wOYa7816eKMkLcq0DS1u3GcUD3BJJP+ WQEFgpr+kOHpvYKQLP57ySLhaEqP0ZtyQghLqIr7ymWLjiIdrnwsEe6lvV3leRtNUoyWt+QheE1 gTevN7MXxMjYNjGfsJvbNCVn5Ka58b1qj40gXnIbcAEMYSCVI8kQYoL0KIbSVIn3WKRDJ2LrlH6 W26LsC0Q84LjIudXb3D68HeuxWWh2HjEJSwxMclY60sxktJ4BlFDTG/QjjXGpuf/kCAb1E3R9jQ 4szf7Q= X-Received: by 2002:a05:6122:678b:b0:5c3:cbde:1bcf with SMTP id 71dfb90a1353d-5c3fe48e12dmr170712e0c.9.1786035596101; Thu, 06 Aug 2026 09:59:56 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c3d05c594fsm3706321e0c.8.2026.08.06.09.59.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 09:59:55 -0700 (PDT) From: Chao Shi To: Jan Kara , Christian Brauner , Alexander Viro , Matthew Wilcox , linux-fsdevel@vger.kernel.org Cc: Theodore Ts'o , Andreas Dilger , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , Zhang Yi , Zhang Yi , Bob Copeland , Namjae Jeon , Sungjong Seo , Yuezhang Mo , OGAWA Hirofumi , Mark Fasheh , Joel Becker , Joseph Qi , Andreas Gruenbacher , linux-ext4@vger.kernel.org, ocfs2-devel@lists.linux.dev, gfs2@lists.linux.dev, linux-kernel@vger.kernel.org, Chao Shi , Weidong Zhu Subject: [PATCH v2 14/21] ocfs2: check for a metadata write error with buffer_write_io_error() Date: Thu, 6 Aug 2026 12:58:37 -0400 Message-ID: <05cd3c34f2dc69b542db7baaef058cd75005d4cb.1785951556.git.coshi036@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" ocfs2_write_block() and ocfs2_write_super_or_backup() detect a failed write by looking at BH_Uptodate afterwards. That relies on the write completion handler clearing BH_Uptodate on error, which this series removes: a buffer whose write failed still holds the data the filesystem asked to be written, so declaring it not up to date is wrong and makes callers re-read it. Test BH_Write_EIO instead. Note that ocfs2_write_block()'s test is the positive one, so the sense has to be inverted rather than the flag simply swapped. The comment in ocfs2_write_block()'s error arm needs updating for the same reason. It said the clustered uptodate information did not have to be removed because the buffer was not marked locally uptodate; after this series it is, so the reason no longer holds. Not advertising the block to the cluster is still the right thing to do - the data is in memory but not on disk - so only the justification changes, not the behaviour. No behaviour change today - a failed write sets BH_Write_EIO and clears BH_Uptodate together. It stops being a no-op at the end of the series, where the new test is the one that still works. Acked-by: Weidong Zhu Signed-off-by: Chao Shi Reviewed-by: Jan Kara --- fs/ocfs2/buffer_head_io.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/fs/ocfs2/buffer_head_io.c b/fs/ocfs2/buffer_head_io.c index 7bfe377af2df..733ceda79ca1 100644 --- a/fs/ocfs2/buffer_head_io.c +++ b/fs/ocfs2/buffer_head_io.c @@ -66,12 +66,14 @@ int ocfs2_write_block(struct ocfs2_super *osb, struct b= uffer_head *bh, =20 wait_on_buffer(bh); =20 - if (buffer_uptodate(bh)) { + if (!buffer_write_io_error(bh)) { ocfs2_set_buffer_uptodate(ci, bh); } else { - /* We don't need to remove the clustered uptodate - * information for this bh as it's not marked locally - * uptodate. */ + /* + * The buffer still holds what we tried to write, but it did + * not reach the disk, so don't advertise it to the cluster + * as up to date. + */ ret =3D -EIO; mlog_errno(ret); } @@ -446,7 +448,7 @@ int ocfs2_write_super_or_backup(struct ocfs2_super *osb, =20 wait_on_buffer(bh); =20 - if (!buffer_uptodate(bh)) { + if (buffer_write_io_error(bh)) { ret =3D -EIO; mlog_errno(ret); } --=20 2.43.0 From nobody Fri Oct 2 01:09:41 2026 Received: from mail-vk1-f177.google.com (mail-vk1-f177.google.com [209.85.221.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 14F88486B80 for ; Thu, 6 Aug 2026 16:59:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.177 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035601; cv=none; b=QdWr0zvhrxLqUfZxsnahQ1eJ2vaWrXRU8wtQZj+G6GjP2iJnaRCal16MS5+rLUyMfIimwzmkdxQMcYzDvZenh+zYYrMcqvRUdzcD5lu+XaX6TwWViDAM8gwXn8jCvNJOisw17Sgu9eG7CRwMorznOfp6egBQipxsbZlLpy9mf20= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035601; c=relaxed/simple; bh=HkO8BGQDQ+F35lZWVjrmgSFoTizhXNL+tmvKt5ZHgXU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IMdjdpKh7uGVyo6KVJR+0jKMetx4Lwj6HdF8kbA2zlxxAxCF8SF3jQgaTjNhDpgzih4N9wmmofzOi7z2YMMa0v+LHpoDQ/AD+op9jIVYHCfbEeYKCxPa4hR7xQ4+S6nK3zaDXYx25WUwANHZmTC7zKepVS/GBkakeqzxIfcU9Gg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=aWG/QPYD; arc=none smtp.client-ip=209.85.221.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="aWG/QPYD" Received: by mail-vk1-f177.google.com with SMTP id 71dfb90a1353d-5bf95ade656so843857e0c.1 for ; Thu, 06 Aug 2026 09:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786035599; x=1786640399; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=ZCchMwHGHYssXWVL8RzH7mG+qMzuQy0Z9sJHAbSWGok=; b=aWG/QPYDgObiC5oHwi3r4RGEv8fl5Qqg+vzRkoHqLwL3M7xaao4P1JP+Q0GtXy6kxy 52iWjvnt0VfQmtTBS3/TJLHn1aKhppIHkVIVFun6gSHoUn65a7CPRiFzC02gx9+q6Fii EGb2REQlnMOq9Sl6cYjBvwN/r47X09oUdWMsJbRhyWSOM+kAl6i6BHoH4NJj69ise5gu 3hUm69dOh1DwFMFvahHUiCt+kdTGuUDIma8DUh3EDwJWBbHFss86RZpMcn19+GPRsBzH Tw/924LU6IvKMCbELJARidOlBgfi/kgCJgKsa4BLJmGVrXM643dWAZH9ZV549qqCtXYb JMRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786035599; x=1786640399; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=ZCchMwHGHYssXWVL8RzH7mG+qMzuQy0Z9sJHAbSWGok=; b=ZfSxiYS/0Uzg8ou+XLLzfWZNtN17Xe5LYgHx5S58nlNRJEcupU9Ubo6NpE/tSyEhqS GiKKy28ANkHkwijm/89oeyqnDmk9UbT6Wu5PpmezqpZndurkABKwyxte9V7DMMlG3iD9 q0MSuMuOli8dRH+xghUc3aR92tJEZoot21p8h/Vf2z3CbMtPKDZ4yRWu5vtOW9ucLwDX cWOOMkahKaQX50NrIKZ4oEaTaiPlO9f6YcnGDQ4T8dRl6u3i/scVIyacQKnXbPpz2ORK CA++EDKqKFVUJrbe7s7usnjkfWdce74f/jeZKs3toR8XzQQVeyN7V61c0lhAtCIIRsqb EOcA== X-Forwarded-Encrypted: i=1; AHgh+RrkKdtvCH2BvD0YsSSHyXfGze1lu5lKR6iwJ09/sO5vVQez+S9onC7gnOeXklE1yvfXBFMcTt/zsPZl5F4=@vger.kernel.org X-Gm-Message-State: AOJu0YxHU5jR91TNuwmotQdyzluTVj/aRtrA6qPKQryH/iemn7L+IWXe /jV9YWMUG2cfTY9QPh5PhfFLrYJ2yKLRxDp5WJS2JnbZP0uVu6t0t2AC X-Gm-Gg: AR+sD12GlezsPY25k/WHE4RRgtAvag1+uVtuZZMb/0xd9nFW9yRSvmhblZ0+tijrceJ uVYHLZS0R1uUx8xBu9CAuX20YvQmTvdU8V1gz0aWxr1Qp+beqlLhI66Isf/siUvilFtjdVLEBKs 3jbEG8FgFz/tii/OAqI1ScwC/Vz1+0Fa4YiJDGK2G9gbDjEUfNX0as830+coXqgAIlQ5pxQJwAR hxweHfdY7y0PRoMbQw60a+mNRvlti1tPdLtwK+n9ULaOnl5nlTLTMjXC5SbytERbOG5+kPyYTDj a+obMA7w8pTYs9FRNluSKV+LbSuA37/Vu0PX09JSnPTAvKGvwXiRwC93sl+Px+HjKswAxB/GpHH XTTO2E76A3QpqOHbl04wGfTz7cBOfiR2Kpe/uqMnenH177wGVuALRRn+CeJIN0QuclVEmzpDYMy KeiLrop6o66NgeOrbshJD8A65V8iLbbKJz+0uBzB4/HuCSmNo8YhCSaBnD69yD7eQM+P8uHxWnb 3DIFC4= X-Received: by 2002:a05:6122:1310:b0:5a4:6680:64f0 with SMTP id 71dfb90a1353d-5c3d9120508mr2112740e0c.4.1786035598926; Thu, 06 Aug 2026 09:59:58 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c3d05c594fsm3706321e0c.8.2026.08.06.09.59.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 09:59:57 -0700 (PDT) From: Chao Shi To: Jan Kara , Christian Brauner , Alexander Viro , Matthew Wilcox , linux-fsdevel@vger.kernel.org Cc: Theodore Ts'o , Andreas Dilger , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , Zhang Yi , Zhang Yi , Bob Copeland , Namjae Jeon , Sungjong Seo , Yuezhang Mo , OGAWA Hirofumi , Mark Fasheh , Joel Becker , Joseph Qi , Andreas Gruenbacher , linux-ext4@vger.kernel.org, ocfs2-devel@lists.linux.dev, gfs2@lists.linux.dev, linux-kernel@vger.kernel.org, Chao Shi , Weidong Zhu Subject: [PATCH v2 15/21] ocfs2: check for a stale write error before reusing a metadata buffer Date: Thu, 6 Aug 2026 12:58:38 -0400 Message-ID: X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" __ocfs2_journal_access() refuses to journal a buffer whose previous write failed, and turns the filesystem read-only rather than risk metadata inconsistency. That check sits inside an if (!buffer_uptodate(bh)) block, because until now a failed write also cleared BH_Uptodate. This series stops clearing BH_Uptodate on write error, so that outer test would never fire again and ocfs2 would silently start reusing buffers whose last write failed. Hoist the check out of the debug block, where it does not depend on BH_Uptodate any more, and drop the now dead second half of its condition. The mlog() pair keeps its own !buffer_uptodate() guard: it is a separate "we can safely remove this assertion after testing" debug aid about being handed a buffer with no valid contents, which is a different question from whether the last write of that buffer failed. The unlocked test followed by a locked retest is deliberate. BH_Write_EIO is cleared under the buffer lock, so taking the lock and looking a second time avoids turning the filesystem read-only over an error that a concurrent rewrite has already cleared, while keeping the common case lock-free. The code in this patch is Jan's, from the review discussion linked in the cover letter. Suggested-by: Jan Kara Acked-by: Weidong Zhu Signed-off-by: Chao Shi Reviewed-by: Jan Kara --- fs/ocfs2/journal.c | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/fs/ocfs2/journal.c b/fs/ocfs2/journal.c index d8afbc1a76bb..ea6802d894c2 100644 --- a/fs/ocfs2/journal.c +++ b/fs/ocfs2/journal.c @@ -676,19 +676,20 @@ static int __ocfs2_journal_access(handle_t *handle, mlog(ML_ERROR, "giving me a buffer that's not uptodate!\n"); mlog(ML_ERROR, "b_blocknr=3D%llu, b_state=3D0x%lx\n", (unsigned long long)bh->b_blocknr, bh->b_state); - + } + /* + * A previous transaction with a couple of buffer heads fail + * to checkpoint, so all the bhs are marked as BH_Write_EIO. + * For current transaction, the bh is just among those error + * bhs which previous transaction handle. We can't just clear + * its BH_Write_EIO and reuse directly, since other bhs are + * not written to disk yet and that will cause metadata + * inconsistency. So we should set fs read-only to avoid + * further damage. + */ + if (buffer_write_io_error(bh)) { lock_buffer(bh); - /* - * A previous transaction with a couple of buffer heads fail - * to checkpoint, so all the bhs are marked as BH_Write_EIO. - * For current transaction, the bh is just among those error - * bhs which previous transaction handle. We can't just clear - * its BH_Write_EIO and reuse directly, since other bhs are - * not written to disk yet and that will cause metadata - * inconsistency. So we should set fs read-only to avoid - * further damage. - */ - if (buffer_write_io_error(bh) && !buffer_uptodate(bh)) { + if (buffer_write_io_error(bh)) { unlock_buffer(bh); return ocfs2_error(osb->sb, "A previous attempt to " "write this buffer head failed\n"); --=20 2.43.0 From nobody Fri Oct 2 01:09:41 2026 Received: from mail-vk1-f172.google.com (mail-vk1-f172.google.com [209.85.221.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 20557486E78 for ; Thu, 6 Aug 2026 17:00:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035603; cv=none; b=Qwv8wHRNzam/XDJxlNx5nytcva9QIaEWDbi0S8btvHhDmG+EoxYA4E2XQxFbSwQWCBoQ1G0Tp/qResSBaUOxfCkQpiw7G7d7PXmJzTjSCMioAX42JecpiPbbJG6K4c6/WBLijI5IOb9uIU4AlwY4/wCJlzO9HKtNSL1b3jlP9xQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035603; c=relaxed/simple; bh=MXEWU902YGIdYxhsplvnnMAlAsOIW5B35iOVcX+SwuQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=p//QKl8FKMNcLeYqZEBS7Tv2u5QRKbDRE1tz2Bb4kZp60BW6HiNSpy8vrnqPYa4Kv6iagAI4I8bkAQFDxiVN/62C83urZuKJ2M/rs18+XC96e0aThxPEb7JwcH+mZTYxvpR/0rgSJQFxh7EIEkMAFfmAwlB4tE43XmXqXMDdmYM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=CeaUzuYS; arc=none smtp.client-ip=209.85.221.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="CeaUzuYS" Received: by mail-vk1-f172.google.com with SMTP id 71dfb90a1353d-5c3a1d005c5so1364890e0c.1 for ; Thu, 06 Aug 2026 10:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786035601; x=1786640401; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=dTojca6QcAoa5sJYmeZWsS9cCWtcJ0fPl4l3Xf8SOVQ=; b=CeaUzuYSQ3enDOlK1H7lHo3zY4g/E5FMxkIobVwsLT5LdMUU6mjXlBLjOG1Z6BwVD1 yOIG/XpFLgEZgRgxXr7aTcIwlP8hftYPuuD7I2qv/Uakt3gsJe3uh+ubDvfDaVRZvBVr kmzjUh9Is3a6uAMM86MthWTkjeK3REUYk7IvawYEx3k4aphnHv1dEflZdNxP8cqgI+zj 1lRpNAHWrwU6eNdDgHn6gQJZ32Yzpu5uujZ51SvxVsW8HgBIHynr44GG/R5rcz9pqusy FEErmqp0a4wzYCgJtsIbxUnI7jXpwH22ggp2hJDFAhzdS6jCtp0ho9u+SykPnOb5qWhB 8qHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786035601; x=1786640401; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=dTojca6QcAoa5sJYmeZWsS9cCWtcJ0fPl4l3Xf8SOVQ=; b=EkrGX3d4E1XTZH0VQ7dXo8bt8xzfi4lMe4idpkAnbMz6UMH6W8viLJw2UIHebVqvAs PEpXNLqhaHTcQeVlXgLAnh7ROXHQqEx6wtYgqhIf093EbJmvozn8hG03Ds1qtYz7LVHN 2CKFGdx/3NHEXU4Z1/M/YIA+N4i9dm14P/hZC5fKjMrr1CRnpbCLJkTfqBD+sH7ioCpN fotRLdqB/3YcwXI6dcR17JtYYuV30RCdTb3Yqu+SXYOxpYxOh1DANmL3lMWE5r27p0Ng KikdZcYvKvmGpXCBTLG9+JEsfNLPvasKFyKvu+BBjW2PItbYul8Rua27q+LxhhK6Kkoo 84rw== X-Forwarded-Encrypted: i=1; AHgh+RoB2K1A7PYGT4lpSPGw1swnejJtbeImXGxl/5lPznHY4nxNdP1uBLEvjC9UrH0XckttCxcA/JqKeex/vIo=@vger.kernel.org X-Gm-Message-State: AOJu0Yy9QROspwarXp1kOeFlfCilejxQPEyxE9ATTBS8t1yHfDXAkFDH TpNTeuyEHlqxTdb47ev8oeGUUMCUn2LxLqhXtjSeAOQNn7Gc0ueBE2Pj X-Gm-Gg: AR+sD13v2skmHHX7UVrAMByfhvRczJG0FIzno84j/JYGhqNFSV0idAwzO53ZkyN9mc7 AMcQ6DtET5H7CCysMuO+AHwARVfRv3bDEkPYT46HTtyQM3psKuLCztNXvB+JhWtiLifoX6Bt+xd U1HQEe7lI8B28kOTepj8RF8wcPGOmhzLkx8oUxBA7T+e5A5bIBT6csIM3n7mDR8nUVnUFX0MoPi UxU7nEhyyiXSWClbLcMSNTiNctuvu4UNKrL8HFlAk0lGQb6gUf6ldmQXURXDJsCBw6N/z651h2g bTfLL4fVF5Nx2O0SmCE2SUekYtB6hHBJ7dbmzjDv9s8qdJ5Fh3PETUjnI8WCRC6nNLRUz/kEDve GG5+3E/PWSELb4SMVB/TGm0qnZLEimeaB7fLhYKotrXOPCufQQ0O55SuNWgqucVANvRRTsofQOB SMTxkQMZ39JcMK44Ys6HDt41Bsm0rqB2o8GNlG9g/bqTOdDM0vv+YKA82ytCl6EQ8sddyLA51or g/7SsI= X-Received: by 2002:a05:6122:178d:b0:5bd:9c71:11e with SMTP id 71dfb90a1353d-5c3f9eb0727mr555265e0c.4.1786035600948; Thu, 06 Aug 2026 10:00:00 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c3d05c594fsm3706321e0c.8.2026.08.06.09.59.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 10:00:00 -0700 (PDT) From: Chao Shi To: Jan Kara , Christian Brauner , Alexander Viro , Matthew Wilcox , linux-fsdevel@vger.kernel.org Cc: Theodore Ts'o , Andreas Dilger , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , Zhang Yi , Zhang Yi , Bob Copeland , Namjae Jeon , Sungjong Seo , Yuezhang Mo , OGAWA Hirofumi , Mark Fasheh , Joel Becker , Joseph Qi , Andreas Gruenbacher , linux-ext4@vger.kernel.org, ocfs2-devel@lists.linux.dev, gfs2@lists.linux.dev, linux-kernel@vger.kernel.org, Chao Shi , Weidong Zhu Subject: [PATCH v2 16/21] gfs2: check for a metadata write error with buffer_write_io_error() Date: Thu, 6 Aug 2026 12:58:39 -0400 Message-ID: X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" gfs2_ail1_start_one() and gfs2_ail1_empty_one() decide whether a buffer on the ail reached the disk by looking at BH_Uptodate once it is no longer busy. That relies on the write completion handler clearing BH_Uptodate on error, which this series removes: a buffer whose write failed still holds the data the filesystem asked to be written, so declaring it not up to date is wrong and makes callers re-read it. Test BH_Write_EIO instead. In gfs2_ail1_start_one() the test is the positive one, so the sense has to be inverted rather than the flag simply swapped. This is not a pure conversion for gfs2, because gfs2 already has a private write completion handler that behaves the way this series is heading: gfs2_end_log_write_bh() calls mark_buffer_write_io_error() and leaves BH_Uptodate alone. Buffers completed through it are therefore invisible to both tests today, and start being caught once they look at BH_Write_EIO. That is a real behaviour change, and it is the one gfs2 wanted: a failed log write now withdraws the filesystem instead of passing silently. gfs2_pin() is a different case and gets a different treatment. Its !buffer_uptodate() test is not only a proxy for a failed write - a buffer with no valid contents at all is equally a reason to withdraw before pinning it into a transaction - so the write error test is added to it rather than replacing it. Left alone deliberately: the BUG_ON(!buffer_uptodate(bh)) in gfs2_unpin() and the two WARN_ON()s in fs/gfs2/rgrp.c. After this series they simply stop firing for write errors, which is correct; turning them into BUG_ON(buffer_write_io_error(bh)) would newly panic on an I/O error. Acked-by: Weidong Zhu Signed-off-by: Chao Shi Reviewed-by: Jan Kara --- fs/gfs2/log.c | 4 ++-- fs/gfs2/lops.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/gfs2/log.c b/fs/gfs2/log.c index 78bba8cc10b8..e3e0dcb1f567 100644 --- a/fs/gfs2/log.c +++ b/fs/gfs2/log.c @@ -107,7 +107,7 @@ __acquires(&sdp->sd_ail_lock) gfs2_assert(sdp, bd->bd_tr =3D=3D tr); =20 if (!buffer_busy(bh)) { - if (buffer_uptodate(bh)) { + if (!buffer_write_io_error(bh)) { list_move(&bd->bd_ail_st_list, &tr->tr_ail2_list); continue; @@ -321,7 +321,7 @@ static int gfs2_ail1_empty_one(struct gfs2_sbd *sdp, st= ruct gfs2_trans *tr, active_count++; continue; } - if (!buffer_uptodate(bh) && + if (buffer_write_io_error(bh) && !cmpxchg(&sdp->sd_log_error, 0, -EIO)) gfs2_io_error_bh(sdp, bh); /* diff --git a/fs/gfs2/lops.c b/fs/gfs2/lops.c index 6dabe73ad790..3df6e4b7e8b9 100644 --- a/fs/gfs2/lops.c +++ b/fs/gfs2/lops.c @@ -48,7 +48,7 @@ void gfs2_pin(struct gfs2_sbd *sdp, struct buffer_head *b= h) clear_buffer_dirty(bh); if (test_set_buffer_pinned(bh)) gfs2_assert_withdraw(sdp, 0); - if (!buffer_uptodate(bh)) + if (!buffer_uptodate(bh) || buffer_write_io_error(bh)) gfs2_io_error_bh(sdp, bh); bd =3D bh->b_private; /* If this buffer is in the AIL and it has already been written --=20 2.43.0 From nobody Fri Oct 2 01:09:41 2026 Received: from mail-vk1-f172.google.com (mail-vk1-f172.google.com [209.85.221.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3454B481A82 for ; Thu, 6 Aug 2026 17:00:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035607; cv=none; b=OI6NORtdrbKms7IRV/Zh7C9MMRlhjL7F0VwdGcGf2BpGEJsngj+aqVBqloshMZgspu1AQd946Yvm2lgxGzzDF3j1vJYAFxbodxE2+nBOdI4QSEs53xjLp6hQd50bM3qYP2in8J2dEOwSByGRAeak+3KYTlJBExYnqdDwNSSRoyY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035607; c=relaxed/simple; bh=0Xc44NcsBrwibOoz0erVurOyZIpK7szMhrJzMbzCwzM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NKA7miswqN2RLf3MEnrL37K0ZgOFWrdKCjDqOQYvELmZ5stTzShXL+39KfabEMya9kkO7OSvwJD2NkJND2GgGShJavkFRySMUukiboC4/nMZtVcsH0TJy16gVWOgrp9XiqIuqeAhG8Caqmp6vC2x1ztmdaIM6ZNknJzjJDwCblo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=q0YZKXQ1; arc=none smtp.client-ip=209.85.221.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="q0YZKXQ1" Received: by mail-vk1-f172.google.com with SMTP id 71dfb90a1353d-59b074ec7ceso899363e0c.1 for ; Thu, 06 Aug 2026 10:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786035604; x=1786640404; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=strVwQ0MT1DlcADT982qPWz3+mjqKycZhsT3ISgkZz8=; b=q0YZKXQ1P/RE2QS5L0BG0JRBDW2ZaYAqxHt0h8DPluGopl0qTilJWD4RJuupSUm/R0 eIF8/cINMoy9kCJ5Zlk4NCT6a2mI6pFHC+oNsPVyVMywN0X+ugOvwUua5ZgXoiAMSRyj MIgCUjBsij4a1X2YtQnSSXgN47E5jx0vEq/Xk02DlCZcu/ANijOmjdJ6fl32pToDGBLg spNG84PaPJQV1O8jrDk4/beLjZIc8hrnkbwJ4SAA1Y8i+pzvH3rag5NdisG9BmCYzaQy Kek3m4d9h/QwNFmQj/9/OrJJisM1jedUR0BL4xFV5UHT+U1LZHOg9dxzvX7XPrC95mGA d6MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786035604; x=1786640404; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=strVwQ0MT1DlcADT982qPWz3+mjqKycZhsT3ISgkZz8=; b=eshaty3j1EncUYcYzI9byOXuO1AEm4Z976JOCyJn0Oj0xp/teEJSQy7Cl8DzHUrTs7 MhJ5h22khXQOadu62CtSTFs2qy4At0AsQqFYbF9kQOr0Tnz2sKX16W/MyZ+23++yFn3m XSfgsd6LVE08I8OFIk3ZFCnzQ0VaLXP/AUet8dTE2+hI0Rh91I3mWG5BpTx7hRDgWVj1 SvXRAbGpyGhjTz1JC25dQorHUsOUCNDZtWfzO6myz2uoVnpO5VHkTJbq62RQvbbGo/Nu 5iqGHAd9fXUx/sIwkbBzM+oRb0I21vOKMPpiqRpJT+9SfOcerOABV/q3loXzIOLFY3U9 OuZg== X-Forwarded-Encrypted: i=1; AHgh+RrcNyGvmNjEGpW7wXg6l/uoJl1tpitDxgHpQkaIwn3a9yJplprP11ZQgEBdCDevI4TtvPiJZJqUdpIvzQQ=@vger.kernel.org X-Gm-Message-State: AOJu0YzPX7U10N0EWd0W1lIMfMjOQY/qYlTx7AFMmxr7hDdjwG7bgtZa V6aVDbj+ZTLyKtC1rr2GoX7mS1tL3yMowE+GoFs/k5opieLbGGOjagoO X-Gm-Gg: AR+sD110OGAoYeEyuy8aG43AbD+KaSxxZ0M+7nRKfVyNPHv7Uum/VzHGdpxBqxOE9Ih VfTy/aeTCdEUVIHjGSOwYLPdFmuz8qQrGwmVHghTpcYs9V70bi3r+SOKKFyPIh4Y+Dhd7S7xpDh 3aplND8CL5ZR+QQpoV0cUMSrCM8Fnvcr7bHig/eHoKl23OX3kxgklY3n2DllG/zkyb9OhfKwgai 0z9POZU6RQMX+NYYObkt3EXi7TCz2NPJ6ulbpEcWNNzMQbyFjZyfgnEIn7+kmMbQcFUZywhOJak hVOKVB++sh71ubEq8U2KJsyzLdyZFoDe6r7ZoHHKQkUItAXzjR8V9FZnFZiIzhgInsuXhcxdDLN +aLEt5wGYUEVST8l2K/nCffQ9onwKXbOmXULFBfJ4Wzvn/dYctF377kDF5/XP/kRZIdGO4MOkwS HZJeJ+hpJyZiZ5L92Ob20s+Q1SpjXgJYcfMBrur++c0G+aFk+To46RqWArB10b7KW6qQSrbHRpo xtpm8U= X-Received: by 2002:a05:6123:2c7:b0:5bd:faa8:74e1 with SMTP id 71dfb90a1353d-5c3d92900f0mr2225801e0c.13.1786035603729; Thu, 06 Aug 2026 10:00:03 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c3d05c594fsm3706321e0c.8.2026.08.06.10.00.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 10:00:03 -0700 (PDT) From: Chao Shi To: Jan Kara , Christian Brauner , Alexander Viro , Matthew Wilcox , linux-fsdevel@vger.kernel.org Cc: Theodore Ts'o , Andreas Dilger , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , Zhang Yi , Zhang Yi , Bob Copeland , Namjae Jeon , Sungjong Seo , Yuezhang Mo , OGAWA Hirofumi , Mark Fasheh , Joel Becker , Joseph Qi , Andreas Gruenbacher , linux-ext4@vger.kernel.org, ocfs2-devel@lists.linux.dev, gfs2@lists.linux.dev, linux-kernel@vger.kernel.org, Chao Shi , Weidong Zhu Subject: [PATCH v2 17/21] jbd2: report journal write errors with BH_Write_EIO Date: Thu, 6 Aug 2026 12:58:40 -0400 Message-ID: X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The journal's own write completion handler, journal_end_buffer_io_sync(), reports a failed write by clearing BH_Uptodate, and the three places that wait for journal writes look for that. This series is removing that convention: a buffer whose write failed still holds the data that was supposed to reach the disk, and saying it is not up to date makes callers rewrite, re-read or WARN over data that was never wrong. Set BH_Write_EIO instead, with mark_buffer_write_io_error(), and test it in journal_wait_on_commit_record() and in the two commit-phase waits. The handler stops touching BH_Uptodate in either direction. Setting it on success was never needed: every caller marks the buffer up to date before submitting the write, because a buffer with no valid data is not something you can write out. The local flag is renamed to match what it now means. The two changes have to go together, because commit phase 4 waits on a mixed list: descriptor blocks are submitted with journal_end_buffer_io_sync(), while revoke blocks go through write_dirty_buffer() and land in bh_end_write(). bh_end_write() already sets BH_Write_EIO, so converting the consumer alone would keep working for revoke blocks and silently stop detecting failed descriptor writes. With the handler converted, both halves of the list report the same way. mark_buffer_write_io_error() is safe on all of these buffers. The shadow buffers from jbd2_journal_write_metadata_buffer() have no folio and no associated mapping, so it does nothing beyond setting the flag. Descriptor and commit blocks are ordinary buffers on the journal device, and marking the journal's mapping with the error is what write_dirty_buffer() already does for revoke blocks on the same device. Acked-by: Weidong Zhu Signed-off-by: Chao Shi Reviewed-by: Jan Kara --- fs/jbd2/commit.c | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c index 0c85af91f9b2..cd7ef783bd36 100644 --- a/fs/jbd2/commit.c +++ b/fs/jbd2/commit.c @@ -32,14 +32,12 @@ static void journal_end_buffer_io_sync(struct bio *bio) { struct buffer_head *bh; - bool uptodate =3D bio_endio_bh(bio, &bh); + bool success =3D bio_endio_bh(bio, &bh); struct buffer_head *orig_bh =3D bh->b_private; =20 BUFFER_TRACE(bh, ""); - if (uptodate) - set_buffer_uptodate(bh); - else - clear_buffer_uptodate(bh); + if (!success) + mark_buffer_write_io_error(bh); if (orig_bh) { clear_and_wake_up_bit(BH_Shadow, &orig_bh->b_state); } @@ -169,7 +167,7 @@ static int journal_wait_on_commit_record(journal_t *jou= rnal, clear_buffer_dirty(bh); wait_on_buffer(bh); =20 - if (unlikely(!buffer_uptodate(bh))) + if (unlikely(buffer_write_io_error(bh))) ret =3D -EIO; put_bh(bh); /* One for getblk() */ =20 @@ -834,7 +832,7 @@ void jbd2_journal_commit_transaction(journal_t *journal) wait_on_buffer(bh); cond_resched(); =20 - if (unlikely(!buffer_uptodate(bh))) + if (unlikely(buffer_write_io_error(bh))) err =3D -EIO; jbd2_unfile_log_bh(bh); stats.run.rs_blocks_logged++; @@ -877,7 +875,7 @@ void jbd2_journal_commit_transaction(journal_t *journal) wait_on_buffer(bh); cond_resched(); =20 - if (unlikely(!buffer_uptodate(bh))) + if (unlikely(buffer_write_io_error(bh))) err =3D -EIO; =20 BUFFER_TRACE(bh, "ph5: control buffer writeout done: unfile"); --=20 2.43.0 From nobody Fri Oct 2 01:09:41 2026 Received: from mail-vk1-f182.google.com (mail-vk1-f182.google.com [209.85.221.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F3FE248B385 for ; Thu, 6 Aug 2026 17:00:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.182 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035608; cv=none; b=onwrKGZrgs7MOmOGwo6rvlzXcikZQJyN5vZpxsIY+dPtsLO5uCdwh46q1giCa3JT3ZROqMqmGWvoMvTJUzaMpevMay5qZ+vzBVp3UW3JSrjk+WTbVbKixzzeV2+sdnZ9F10IrL2Y1Ezzr9qngKsyo/qFa39+oi7cX59LaJ/Z0Bg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035608; c=relaxed/simple; bh=nwDfftK6tDKKFwsyIY1zmP/nNMRDmqL5O9HNMSOfLoA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=karXQ5OpzfWHXG5dNTDdPUw454QptN1CYvJjUuac6/PsSMkFATwiOAeiv+B/ILfy3Bff2znyUd0xmVvKtn7HUz3HTLCxzUqqDFQUtER0Fhd12moKtxUEUI7yw+7oH+hxkvxic0AGBIyw3+tVo8z5Tfl48aFEBfJnwkJHLOF0Jzw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=RpJjo3Df; arc=none smtp.client-ip=209.85.221.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="RpJjo3Df" Received: by mail-vk1-f182.google.com with SMTP id 71dfb90a1353d-5c3163a88a1so678097e0c.3 for ; Thu, 06 Aug 2026 10:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786035606; x=1786640406; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=VOSQ52yeWBlRERTYkX4++c0c05H07NL60x8ILsT5aXA=; b=RpJjo3Df9WQveeK5T0fUBs9J7PtwKjP6ioFb1A9txPdlCDx0C30fHZz8SkCYXE9rXT vleecIQEGfHJtpZcIhsM7jqm+xVr0aCFNRX0/X7mSCfVkrSbunGL7BWRDx/0L6ovsFh/ HFKnEh9dt5/H4ecILk9rfj+ElJQqahGBT9ILKccOnbElXJLsaHSwxQK7nH04BNmB3k2b GUQTrrMxcUEf5NSI1p9U3ogHsfCLme+6vl9l43I259uy7drmEHz+MromgdxrLR8PvIDK tlQY0/sUZa0iOnRQTEd/QScs8bSIGkMoHa3ICCftGpd1M2nEkyheJjM6zfH2Q2tfz1rO EZmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786035606; x=1786640406; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=VOSQ52yeWBlRERTYkX4++c0c05H07NL60x8ILsT5aXA=; b=TP8h7NQQ4tgZIZpO5wwrA9ahYbCV2EQDVGm7BNBy08PRhvRUvBq7+PjLurzo6Jy20V fDyri3dN2uLebg2vso34AkaDc+AznjgPjutfRcPmyPcW9E1Eg2TAg7sbFMfKHbEqwo0S S/DMbS4v+s3wbB1vKk3+ij2lAQ6Fs+gDb8UKT7y+qMGSI4gUcnxc3o1tydMZ+XJx4kfm NiuaE/Pl9tewLeTDhuHODnwmVi5+ErWBM6mOmBsTxyF5G81xi68VTR+pht2hfzyTI4PB 0dAgS61eNQp6gs18Dk7LHLcCCHHyoYzRQksG/tc4OmF8zxKXezGNR8r2BAX3rgjTgHk4 p3CA== X-Forwarded-Encrypted: i=1; AHgh+Rr+K1JwXjJF5IWtqpIFHLd7le+oics76of5nwMgaex4R3U7Qo7d7M4sHSXSVSEM4fZ7o3Pn6wheS7uu0V8=@vger.kernel.org X-Gm-Message-State: AOJu0YwDrysKPARrTD6cAW/k3WLyfo6TznqVVbt5UhcCoHSQf/iZnmYf zp97feeevwde2Xd/Et3yVqNDGWnh51dgcTMHY6PO3neB1Vx197c5URJb X-Gm-Gg: AR+sD12IlajcHEkxG4qFCCtY1tJzTWXGNzU9ewcaeujR95VMVT8sHW11z+bzoKMqXCl EWUJuKReNIzu5NQ9H3Igd7Zt08jnBimX6v07icxuUBrCmkzWm5QPMK8Y2o1OrJtoPVRlxYtGmz1 Qz2/sbcwuygPJSnQFUR2NLUjFMN8Q21BevhmP4M4jbjZD5F3rUesNbuwGknKGl+Aq/GSnlge+xs W4ovA2KBlTmNNptYzRHLEcyTiFwgcO56yUdpr5sW/h3CY18Slk6e/LUUZhuUyfrVyS/hW27u5Bx SSMo6pY6kciVEBwbHGA0clJOVyNmQBOd5k+H6NFuGKCrEj6IXR2ZFPjXX/a9VKwaIQ+MgiDpI7c va+7Ez/bEX9Sc212//S5IzD5AkwfecZ1+YqC8iOnEaOEFW7lnRAQPZx7uVAf3j+0f8DeFwXi+14 fFRqER+vZ1HaWH2cNuQ+mJB+pBdAhpc6i4uvRSnOwDCaMZCtYGYqvGGM47hKSBjvbAXE6kzzxtx XMQgmg= X-Received: by 2002:a05:6122:8f88:b0:5bf:b3a0:388c with SMTP id 71dfb90a1353d-5c3d91849cemr2185136e0c.6.1786035605840; Thu, 06 Aug 2026 10:00:05 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c3d05c594fsm3706321e0c.8.2026.08.06.10.00.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 10:00:05 -0700 (PDT) From: Chao Shi To: Jan Kara , Christian Brauner , Alexander Viro , Matthew Wilcox , linux-fsdevel@vger.kernel.org Cc: Theodore Ts'o , Andreas Dilger , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , Zhang Yi , Zhang Yi , Bob Copeland , Namjae Jeon , Sungjong Seo , Yuezhang Mo , OGAWA Hirofumi , Mark Fasheh , Joel Becker , Joseph Qi , Andreas Gruenbacher , linux-ext4@vger.kernel.org, ocfs2-devel@lists.linux.dev, gfs2@lists.linux.dev, linux-kernel@vger.kernel.org, Chao Shi , Weidong Zhu Subject: [PATCH v2 18/21] jbd2: say what jbd2_freeze_jh_data()'s assertion is actually checking Date: Thu, 6 Aug 2026 12:58:41 -0400 Message-ID: <713ffb9c0cdfe55499b3cdd2c06a59a2c152c46c.1785951556.git.coshi036@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The assertion that the buffer about to be copied out is up to date is correct and stays, but its message - "Possible IO failure" - describes what a buffer that is not up to date used to mean rather than what is being checked. Once this series stops clearing BH_Uptodate on write error, that reading is wrong twice over. A failed write no longer makes a buffer not up to date, and a buffer that does carry BH_Write_EIO is fine here: it still holds valid data and the journal will write it again. What the assertion is really guarding is that there is something valid to copy at all. Say that instead. Suggested-by: Jan Kara Acked-by: Weidong Zhu Signed-off-by: Chao Shi Reviewed-by: Jan Kara --- fs/jbd2/transaction.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/jbd2/transaction.c b/fs/jbd2/transaction.c index 5cc7d097b2ac..85d84d909f78 100644 --- a/fs/jbd2/transaction.c +++ b/fs/jbd2/transaction.c @@ -920,7 +920,7 @@ static void jbd2_freeze_jh_data(struct journal_head *jh) char *source; struct buffer_head *bh =3D jh2bh(jh); =20 - J_EXPECT_JH(jh, buffer_uptodate(bh), "Possible IO failure.\n"); + J_EXPECT_JH(jh, buffer_uptodate(bh), "Buffer not uptodate!\n"); source =3D kmap_local_folio(bh->b_folio, bh_offset(bh)); /* Fire data frozen trigger just before we copy the data */ jbd2_buffer_frozen_trigger(jh, source, jh->b_triggers); --=20 2.43.0 From nobody Fri Oct 2 01:09:41 2026 Received: from mail-vk1-f182.google.com (mail-vk1-f182.google.com [209.85.221.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3ADC048C406 for ; Thu, 6 Aug 2026 17:00:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.182 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035611; cv=none; b=KEk711m+EudX9uomC7r8x8CBc/P3MWFbD+eosMWvhocw9fRs/AzpfZh4sCly99Hiann7V/TLpgmJod3/PomKkElpcbh0IXFSNtYTf8vPEMFYBU3WAA6N+ZnosbNEwfaCPGrRl3GM1gBmTsKgtZ8AEL8Cpp7bGhrBTDC2x7k4tuM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035611; c=relaxed/simple; bh=92j6zzfTbfyHLTwkDGD6bYfpfzSkLDZ7TK79qat2c7g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=D5o+X1Glz5hvfOodaucg4j8gplQ1KeiX5G8IYpl6RtcCrf42g76ksfVTdW8j6tpref+/JVhGGz1OGrpCSWqCPN5GVmkhAfdqTGwztBUZcBAhvY5NRlrtzJQ01mNb1h1Y8c3V1ab681YI9bYNxT2LODCcA7RUx4oT/YY/TwJIxp0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=VXHWA5pY; arc=none smtp.client-ip=209.85.221.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="VXHWA5pY" Received: by mail-vk1-f182.google.com with SMTP id 71dfb90a1353d-5c2c0e261aeso700398e0c.0 for ; Thu, 06 Aug 2026 10:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786035608; x=1786640408; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Y0IvqThbFa3F9XFl8mEQfcRObacw4VhqXeJ5e5/Q63c=; b=VXHWA5pYllrSyJHP+Y1cW45sd9QyBnAXJFHXXQW3HsvtWFj+dNMk1t5z/PNZv2GDmT nBTs3sjvl4rowBP/1xgGEKnsdNQ8bxw/RrPisX1RGIsyT+BlmaCaI2UGD1RtXFSM/Vah eANb+YT/p99zHQuDGCef2a8qLpO2F3wCIl4QQaQ+1FQY3TkLt+cFPg+zQlyNJvCBvHPV vP9uBEFxZ1j2jmX/5lhIDi7Zlq2+jVeeHUR4G/1GhM9TPxPZN4P5V21YXug8kkc4GiIy oKmZ0ItaiS4P2YT5zc53QlpmMb+igjjNpFcYZ3u53z9QmaJNwgLukVF5+d7858rxPp95 cD0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786035608; x=1786640408; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=Y0IvqThbFa3F9XFl8mEQfcRObacw4VhqXeJ5e5/Q63c=; b=ozEWbkzbrbeEkd/N9Q6N5TA5Es7hIT92fbo7TfiAq2f94YyY1W2qJ6Jyeb7Rua1ZJb tDdLj+147a/cTdZtkw1n+FqOox482seEXHHBXrw9Bf37pX6wjQStL3NZo/mlNCAPy4UO F+vBQTy7Fa1cKzfwxE3PKeojeJwPl09raNSj2OMVGGCHJxk7MLRC3hWLPNr97ABy/5jd t3FlyJpRNRNHrAjjQ63Rs6UGlGfXbqQLPOAAq9jsikGfRHiV088Gykyk2TwPrBYz6hJJ LXM5y7essBnaYCgkzxkFTs9JnSKoAU+fs2ATtixKIbK7LK15LT0o3y8A5lL8lktvFJ+P X/dw== X-Forwarded-Encrypted: i=1; AHgh+Rr8TD69z76Hnn5UejGFCq8taw4/qMyquzRXFAt7PXYMlMbBrKqThby2h250lF98zeenkyM1e99PaBWtBWA=@vger.kernel.org X-Gm-Message-State: AOJu0YzOio7+UP07KBzzdnO28Ottw75ahv6GzZBouEu0YGczydAW/KQz PM9C3yWQpXlb3C4RXcquez/lJgshMYlUDgpigYL+poRycdYTFVCEhjKE X-Gm-Gg: AR+sD13/cNHVYIfLN8G/ylBUGtZMfRL1aaPL/3MRo9PvPb0C4Yfvlw0OBmu9+0TLnu0 k7XZWNWq5WWydcJ8BdA0wxlHe6Jwr5op2K15jXB+BnIdShIr8BnSdFU7fpEjPS3z887teT9wym/ vw+0pH0YS73Y2/w+0wPaunngdwYydMP2kNY1SYh786fBnh3IWaXdRwRKV6j2BFWD5vp1SteV0Cl 7oNSQN0wcwAKFepqfMpxyoBHWfLjHP9tpnhs8S4JVaFOtzcDRPzbzE2HP0QKc2WO0F0GEX6uFBu X5Ofwjbya3/IC3YKVZWUZ13yvRQzqCBznnD078w6CgSn/U5lXSKXaljBCqOV7eu98pfMort8tlh YTFq7MdlzRHtvZ3ls+et4ShavEH4qkA2QjOJ/BuWF9lJiAshxOvcTt4d/rpspTydmXceefb3y00 SKJb1W2VVpwNNYhDIssqdW/UpQy02w9GKkZRVYWlTapT1OpOsNZ0xZAJpdRR9dHVLx2uZRGDlFG uUJHpw= X-Received: by 2002:a05:6122:390a:b0:5a2:5c65:850f with SMTP id 71dfb90a1353d-5c3d91f3c3cmr1985318e0c.10.1786035608151; Thu, 06 Aug 2026 10:00:08 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c3d05c594fsm3706321e0c.8.2026.08.06.10.00.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 10:00:07 -0700 (PDT) From: Chao Shi To: Jan Kara , Christian Brauner , Alexander Viro , Matthew Wilcox , linux-fsdevel@vger.kernel.org Cc: Theodore Ts'o , Andreas Dilger , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , Zhang Yi , Zhang Yi , Bob Copeland , Namjae Jeon , Sungjong Seo , Yuezhang Mo , OGAWA Hirofumi , Mark Fasheh , Joel Becker , Joseph Qi , Andreas Gruenbacher , linux-ext4@vger.kernel.org, ocfs2-devel@lists.linux.dev, gfs2@lists.linux.dev, linux-kernel@vger.kernel.org, Chao Shi , Weidong Zhu Subject: [PATCH v2 19/21] ext4, jbd2: report fast commit write errors with BH_Write_EIO Date: Thu, 6 Aug 2026 12:58:42 -0400 Message-ID: <970d8b9603d4620ab73038f49bc36831e37e00a0.1785951556.git.coshi036@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" ext4_end_buffer_io_sync() is the third completion handler in this series that reports a failed write by clearing BH_Uptodate, and jbd2_fc_wait_bufs() is the only thing that looks at the result. Convert both. Like the jbd2 handler, this one stops touching BH_Uptodate at all. ext4_fc_submit_bh() marks the buffer up to date before submitting, so setting it again on completion said nothing. The local flag and the debug messages are reworded to describe the write rather than the buffer's contents, which the write does not change. They have to move in the same patch. The handler lives in ext4 and the wait in jbd2, but neither is used by anything else: the buffers are ext4's fast commit blocks, submitted by ext4_fc_submit_bh() and waited for by jbd2_fc_wait_bufs(). Converting one without the other silently disables fast commit write error reporting. Acked-by: Weidong Zhu Signed-off-by: Chao Shi Reviewed-by: Jan Kara --- fs/ext4/fast_commit.c | 11 +++++------ fs/jbd2/journal.c | 2 +- 2 files changed, 6 insertions(+), 7 deletions(-) diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c index 8e2259799614..a2028fbd4540 100644 --- a/fs/ext4/fast_commit.c +++ b/fs/ext4/fast_commit.c @@ -203,17 +203,16 @@ static inline void ext4_fc_set_snap_err(int *snap_err= , int err) static void ext4_end_buffer_io_sync(struct bio *bio) { struct buffer_head *bh; - bool uptodate =3D bio_endio_bh(bio, &bh); + bool success =3D bio_endio_bh(bio, &bh); =20 BUFFER_TRACE(bh, ""); - if (uptodate) { - ext4_debug("%s: Block %lld up-to-date", + if (success) { + ext4_debug("%s: Block %lld written", __func__, bh->b_blocknr); - set_buffer_uptodate(bh); } else { - ext4_debug("%s: Block %lld not up-to-date", + ext4_debug("%s: Block %lld write failed", __func__, bh->b_blocknr); - clear_buffer_uptodate(bh); + mark_buffer_write_io_error(bh); } =20 unlock_buffer(bh); diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c index 6e05dc47e20a..72e8ccbf7de4 100644 --- a/fs/jbd2/journal.c +++ b/fs/jbd2/journal.c @@ -886,7 +886,7 @@ int jbd2_fc_wait_bufs(journal_t *journal, int num_blks) * Update j_fc_off so jbd2_fc_release_bufs can release remain * buffer head. */ - if (unlikely(!buffer_uptodate(bh))) { + if (unlikely(buffer_write_io_error(bh))) { journal->j_fc_off =3D i + 1; return -EIO; } --=20 2.43.0 From nobody Fri Oct 2 01:09:41 2026 Received: from mail-vk1-f182.google.com (mail-vk1-f182.google.com [209.85.221.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8719F48CD6D for ; Thu, 6 Aug 2026 17:00:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.182 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035614; cv=none; b=Q7sE6Lx4m+d9k6VMxxvCIyjBqnaJsJnkpQl0TbjUAIXYrXfK5seWu6B05Ck0IZghhg5hDKUY3yxlDJkMsotHBeEbK9gQEBJPHtb9q2F/9qf4LHTv2T3rBG11Y2Ir3df7FnbkJciRyoKtVCzscUsnr0NM2hgdd8SX2yVybA+98J0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035614; c=relaxed/simple; bh=PQ2ah5ZVupMR/HGE9t8COOvVi4Hx2BdC9HNHr4xKmRQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=s/UIRrc6IQzqm8/VL+zQGPVHAAE8opuAaR6EMYfUAWwElv9W4KaC2WHbrUYfFGujpQvTjtPLB3HyRE6XqqsHqYQ7fWAXS0+BNEwBZObSjZfrmGWvSUV6Ohmuc4X5OI5z2ziNH0dZbuA8FXJJnwTGBAFmGYoOfanMaMGkOWQ4JOo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ClOez0iu; arc=none smtp.client-ip=209.85.221.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ClOez0iu" Received: by mail-vk1-f182.google.com with SMTP id 71dfb90a1353d-5c27e38ee18so1234313e0c.1 for ; Thu, 06 Aug 2026 10:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786035610; x=1786640410; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=aY+Eq3Vzt7bW6hh+0BwKtYH0EUlmb7bdAzVAsm/0VMk=; b=ClOez0iufuTQUr/mpy5VSpP51GEZvuHiLydAzYKpFIdMA+iPX31rVu9GYF+buyykIi JFHFR7GHCzFLfdsLVRmoC2gBVt0NOoNW6ovPydzBENEZ7AkWIJQGj+uwqUPYtFiKV4la eA6qrp+UaI6f90h6IOpmiXXTYa/O3CiAbawG/gIObQrwdRdcWY3AvhUrLoxQk4Y6tykz uAPwpNZHJxyvlaBYLQHyH/G0/D5EtNkCij63xSUDkSU8mekZ5ago6oTVIBOq9ROuJ/7t 9oQwW0/j4FetFM/7oQNdQPCWxWq+/LRtlyNvUwtpmlJzA4hH/SMrHje8/YAWVw6+Pf6c zKFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786035610; x=1786640410; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=aY+Eq3Vzt7bW6hh+0BwKtYH0EUlmb7bdAzVAsm/0VMk=; b=hZd26eQoCOTzUH65OOjWxaOzvc1A9ZQ8mKVB3IxH2tVoUeLCfxD/eMna4sJw+pViBs CXrh27MiKnjFKgZ5KmstsesrB4d9nkzrZhmwiEIZdpzHRQQBzeeSsE/TYCCjvfo/hMzw g8R3p3jmGHQOUqsu7XbpbFBeLztiXFgdoPoQMkNy7oq/TEJg8GUSOcNbxn+SMW6AKagi mWsGzjULaQ1Qcl2CWFMYauuZZNX8cxRf4yfq+3mupU4ny/kAdz/cvW97vg+f0zCznwyk C6r6PNSlaoQUpYz6BOGQ7hsmLFK59GhKh1FYdCdHX9FNtsBcud98psAJIXNwTzEkOAwr 91LA== X-Forwarded-Encrypted: i=1; AHgh+RqfdzsBBZD3rUWSmrDav3cXbL1zAa8AEWIevGNX5QoJtU3Qdm4F+V9+QvAg5t83fSzmKZXR0F4M/K1xbpY=@vger.kernel.org X-Gm-Message-State: AOJu0YyzV0c8cZ4nOegG92RW/ZXZ+f+7Z90ZtljsFyTy2IgvbXUwIXcZ 559vV4DYdZWs89z/mk8t+7uSBqzO0jw6mTBgTvDPdbtt4bSTpDIb2d94 X-Gm-Gg: AR+sD13bASho2gaRsldwiyiaQFVY6D4VmoMpjjQBSU+vv5yflbqa3cmHAc7b46KAZWW hxO8jtnNWG1jUWJ83vnXkoTxxqptIwb1vT5lUZcw7x56osSfSEfKum5G+4AjcPmdZ9X8XFr6NXx EXpBKfFafvcYYg02H+Slnmn9vnOkIfimDRVlwutzyTOMKBNgPXbp0R7PNHd+HJGydfmugxo7kWV 2CJSwPk+ZxIG9dsx6i5YdeZhK5WXWfe5QpAgmzf0doeDxEESzF5TJInCHuOhZuTutnq46QckcKL wCO/+i987JfqsPy4YbWjhxXOBKzAsRqgKtNTKejX6YnLO8k/EMqKPHG9lHgJqgJR72SF9goKlOj OJpyeRIwS74UD2CL7jUOMz6CS9jXnw+7XnWwm33mzbMeUs6aLNn63zwSIdXMpryM0J20OBxI1Tw o6v8yf6iGBKk46VnlZ3U6HvQ1R3QCY1fylI0nBo6qYv+lzcMwsl+9XoZOYH0mxv/Q9FvhRy72Uv 1NrWLQ= X-Received: by 2002:a05:6122:d06:b0:5bb:d233:70bd with SMTP id 71dfb90a1353d-5c3d9068e60mr2530050e0c.2.1786035610452; Thu, 06 Aug 2026 10:00:10 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c3d05c594fsm3706321e0c.8.2026.08.06.10.00.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 10:00:09 -0700 (PDT) From: Chao Shi To: Jan Kara , Christian Brauner , Alexander Viro , Matthew Wilcox , linux-fsdevel@vger.kernel.org Cc: Theodore Ts'o , Andreas Dilger , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , Zhang Yi , Zhang Yi , Bob Copeland , Namjae Jeon , Sungjong Seo , Yuezhang Mo , OGAWA Hirofumi , Mark Fasheh , Joel Becker , Joseph Qi , Andreas Gruenbacher , linux-ext4@vger.kernel.org, ocfs2-devel@lists.linux.dev, gfs2@lists.linux.dev, linux-kernel@vger.kernel.org, Chao Shi , Weidong Zhu Subject: [PATCH v2 20/21] buffer: stop touching BH_Uptodate on write completion Date: Thu, 6 Aug 2026 12:58:43 -0400 Message-ID: <61d7d5737f5773f53ee543f375fcde81aa8d28c2.1785951556.git.coshi036@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" A buffer whose write failed still holds exactly the data the filesystem asked to be written. It is the disk that is out of date, not the buffer. Clearing BH_Uptodate says the opposite, and callers act on it: - mark_buffer_dirty() has a WARN_ON_ONCE(!buffer_uptodate(bh)). A filesystem that dirties the buffer again after a failed write - which is the normal way to retry - trips it. That is the warning this series started from. - a buffer that is not up to date gets re-read from disk, which replaces the data the filesystem was trying to write with the stale on-disk copy, silently. - the window between the write completing and the buffer being marked not up to date is visible to anyone holding the folio lock, so the state is not even self consistent while it lasts. BH_Write_EIO already records the failure, and by now every place in the tree that needs to know about it tests that flag instead: the two core helpers in this file, adfs, exfat, ext2, ext4, fat, gfs2, jbd2, ocfs2 and omfs, converted one filesystem at a time in the preceding patches. The private completion handlers in jbd2 and ext4 fast commit were converted along with their waiters. Nothing is left that reads BH_Uptodate to find out whether a write failed. Setting BH_Uptodate on success goes too. A buffer has to be up to date before it can be written - you cannot write out data you do not have - so the only thing that assignment could do is paper over a caller that got that wrong. Write completion now leaves BH_Uptodate alone in both directions. What this changes for readers. A buffer whose write failed stays up to date, so the read paths stop replacing it with the on-disk copy: __bread_gfp() no longer sends it to __bread_slow(), and bh_uptodate_or_lock() reports it as usable. That is the intent. ocfs2 changes the most, because ocfs2_read_blocks() decides whether to go to disk on its own cluster uptodate cache and only tests BH_Uptodate after the wait, so a block whose write failed makes that read return -EIO today and from here it succeeds and hands back the in-memory data. A caller that needs to know the write failed asks BH_Write_EIO. Found by FuzzNvme. Acked-by: Weidong Zhu Signed-off-by: Chao Shi Reviewed-by: Jan Kara --- fs/buffer.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/fs/buffer.c b/fs/buffer.c index aebf74abbc49..425fbfe72ad1 100644 --- a/fs/buffer.c +++ b/fs/buffer.c @@ -202,12 +202,9 @@ void bh_end_write(struct bio *bio) struct buffer_head *bh; bool success =3D bio_endio_bh(bio, &bh); =20 - if (success) { - set_buffer_uptodate(bh); - } else { + if (!success) { buffer_io_error(bh, ", lost sync page write"); mark_buffer_write_io_error(bh); - clear_buffer_uptodate(bh); } unlock_buffer(bh); } @@ -436,12 +433,9 @@ void bh_end_async_write(struct bio *bio) BUG_ON(!buffer_async_write(bh)); =20 folio =3D bh->b_folio; - if (success) { - set_buffer_uptodate(bh); - } else { + if (!success) { buffer_io_error(bh, ", lost async page write"); mark_buffer_write_io_error(bh); - clear_buffer_uptodate(bh); } =20 first =3D folio_buffers(folio); --=20 2.43.0 From nobody Fri Oct 2 01:09:41 2026 Received: from mail-vk1-f180.google.com (mail-vk1-f180.google.com [209.85.221.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CEF144908B2 for ; Thu, 6 Aug 2026 17:00:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.180 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035616; cv=none; b=oDoW1pZ3wJlc1NhmL5MPiQ2/tZ57dzURDpN6NpnTWhkzkCxjNkytBgh/7PFMOxqBSYRyvAB26kzFDAfyR+E5pM8OZF+njgXNfepV8ix8EGJRzrnmckRWTvdMc8DJKoEJfU8fEze+DY+Kn14b9r//GiIJnatQoAMhngVgQ3NEqNE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035616; c=relaxed/simple; bh=K9/W1FO8N8xTnhyFws4RenGjtbgDOPBPnEUZbmmiB0U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IVD4KfQMNLIgR3OiiX5VeGUd964b1gSLzHJnJmUhUaGuQtip7QYojNiqKQkzpypPq/DM0z7DzVxFucx76T3O6iUSkxzxhK/ZQXEj3+bpbGwTiUzQj6W+iHtZushr2O9paL7VWibZzUDKJKK1+AQqFtCcwHZ1tDXJh64lvo57QsU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=DYMymKr9; arc=none smtp.client-ip=209.85.221.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="DYMymKr9" Received: by mail-vk1-f180.google.com with SMTP id 71dfb90a1353d-5bfa6766cf6so1277773e0c.3 for ; Thu, 06 Aug 2026 10:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786035613; x=1786640413; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=dBfFE9yENSRT1Ltqp2iNdGevVOH72zBv0XCWLRoCCcc=; b=DYMymKr9iJ0MfWNFmHTMcDp+vfbmJcVQ4S81aC4XPOGI5fJYig+5tGL9yuQ7IjHb4J 5fjgTj8DJ/MP2ApXWr5CxtfH/jEotJgLkxPkTflbko7TdRb/yUmI1lZlVCGtpN3mG86k GsKAHGU84ajwLE1ch2hnLPfL66yAj44ebPDrkLC3IBGK+BEzh9HiS8kuotGS58UNR6Ff 8f/3fcEDC9jjcRSwGDq3fqLEVNyjKQNdllgRt5DjatQ6RDeoLfb+VS3S0TVmD74Ye+OZ vUW/74/GKVa/mnu6Gv8OV7cbDAWDVC03WSNg98YruRvqahYi/g3Lg6Pbj52sND835+Tp u6MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786035613; x=1786640413; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=dBfFE9yENSRT1Ltqp2iNdGevVOH72zBv0XCWLRoCCcc=; b=ll89SzBj+XHbmq+NbFGeKFfesLnAOEyFmKH+dnPVcJKE0/SJ1Q0emfRJO9frNoqpk5 0c1nLsqjr0EtFWZ46ZINEckvb+mv1o8I4NZxPei4akgLG4IX4+TSiAythbwpr6vz2WOp y6TFfzgtJgSPQitppHFQhBBVFDZeD1f8+YSLBCnLU+dRpqbE++yTLjP2EVHCa9uoPYdM mF1sfAGwj09/SkqlzzHc9TEjFTH16spHGHgOJDX5GwAmwvLpWUwc9fOkMosGjC6z/rmi 3z6lyI+36yQcJI4DI1DNwYlNANs/uhC7dtMQtF5X5QJudtpEMukhPdjsZ601qG0XpzRR n/Sw== X-Forwarded-Encrypted: i=1; AHgh+RqRT4QmdtEH5y49PH05+lEynwN7hzHhff6hBAJ2uuaLM/eo28IkSZ71D1m6wyUzB+q0CdU6iaNUZ+I5z8Y=@vger.kernel.org X-Gm-Message-State: AOJu0YzTsePFfm+EMYSou3xcslbDR/s/kK6FU3Z43FGWSk7Hdx+CU8iD O7kJpJe593XVLdst3tqBUoWVTnkNJ0xa5WEU96WA3BGmienFa9F6ttSr X-Gm-Gg: AR+sD12MLEntTZQF3P1fqkz4hwbZuyzeIkblrU8COOvX5/ClJmaycEcx3Pic8wwk0k5 cjEUVGB/IJ1+i0FSyxE9FMn3h0IvQilxQWYqGT2dRgnRE1WE2zX4iVC4JOkK5Yc6UgC0OKD1gig rwVMhXDOWIGpgk+2oDp0yZkCPHfyKJlv3qmgyby/oFXRBZJdQ1JxetEG3eR3Vttu8RLwJ/YkfXJ ykWJCaiQTaEB7yXXy2n7wyggaJYSofh8pigLmba09F+zg5uOr4gUUR4XXC9f6gyrDxrJ/SIYDqb CWKVYeDpKu+4hzhX7KPdtFcRocZzOk9duPT/1PsF4m7+70SpG8uG7SG6wFbnXkV47GSpfy/UGR3 nN9GUized+yzvgLrRuSstoByVGh1kjT2wl/EsxxLVa/mSMJerNfg8crzRX7+5NP3Sc/4jpCm1Ks RuQ4om/unB57uRTRTP1XMshJv28/aZFqDFdlSfl0ekPR7ggoIN1y/QNgi4UaMK5D3gLCcGCB5Ty //bAD4= X-Received: by 2002:a05:6122:d96:b0:5a4:7e8b:3171 with SMTP id 71dfb90a1353d-5c3d91e6c7amr2524108e0c.11.1786035612662; Thu, 06 Aug 2026 10:00:12 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c3d05c594fsm3706321e0c.8.2026.08.06.10.00.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 10:00:12 -0700 (PDT) From: Chao Shi To: Jan Kara , Christian Brauner , Alexander Viro , Matthew Wilcox , linux-fsdevel@vger.kernel.org Cc: Theodore Ts'o , Andreas Dilger , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , Zhang Yi , Zhang Yi , Bob Copeland , Namjae Jeon , Sungjong Seo , Yuezhang Mo , OGAWA Hirofumi , Mark Fasheh , Joel Becker , Joseph Qi , Andreas Gruenbacher , linux-ext4@vger.kernel.org, ocfs2-devel@lists.linux.dev, gfs2@lists.linux.dev, linux-kernel@vger.kernel.org, Chao Shi , Weidong Zhu Subject: [PATCH v2 21/21] buffer: clear BH_Write_EIO when a write succeeds, not when one starts Date: Thu, 6 Aug 2026 12:58:44 -0400 Message-ID: <1c976fd191aa6e99dbe65d6a1ec63f8706cc0dfa.1785951556.git.coshi036@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" BH_Write_EIO is cleared in __bh_submit(), when a buffer that has been written before is submitted for write again. That is early: it says the error is gone at the moment we start trying to fix it, rather than when we have. It also loses errors. A task whose write fails sets the flag and then goes to look at it; if another task redirties the buffer and resubmits it in between, the submission clears the flag and the first task sees no error at all. Neither of them is doing anything wrong. Clear it on successful write completion instead, in the end io handlers - the same four the rest of this series has been converting, plus gfs2's, which already marked errors this way. Then the flag means what it says: the last write of this buffer that finished, failed. A resubmission no longer hides an error that has not been fixed yet, and one that has been fixed clears the flag when the data reaches the disk. __bh_submit() keeps setting BH_Req, which is what the rest of the tree reads it for. Suggested-by: Jan Kara Acked-by: Weidong Zhu Signed-off-by: Chao Shi Reviewed-by: Jan Kara --- fs/buffer.c | 15 +++++++-------- fs/ext4/fast_commit.c | 1 + fs/gfs2/lops.c | 2 ++ fs/jbd2/commit.c | 4 +++- 4 files changed, 13 insertions(+), 9 deletions(-) diff --git a/fs/buffer.c b/fs/buffer.c index 425fbfe72ad1..68ea0ef8470e 100644 --- a/fs/buffer.c +++ b/fs/buffer.c @@ -202,7 +202,9 @@ void bh_end_write(struct bio *bio) struct buffer_head *bh; bool success =3D bio_endio_bh(bio, &bh); =20 - if (!success) { + if (success) { + clear_buffer_write_io_error(bh); + } else { buffer_io_error(bh, ", lost sync page write"); mark_buffer_write_io_error(bh); } @@ -433,7 +435,9 @@ void bh_end_async_write(struct bio *bio) BUG_ON(!buffer_async_write(bh)); =20 folio =3D bh->b_folio; - if (!success) { + if (success) { + clear_buffer_write_io_error(bh); + } else { buffer_io_error(bh, ", lost async page write"); mark_buffer_write_io_error(bh); } @@ -1114,7 +1118,6 @@ static void __bh_submit(struct buffer_head *bh, blk_o= pf_t opf, enum rw_hint write_hint, struct writeback_control *wbc, bio_end_io_t end_bio) { - const enum req_op op =3D opf & REQ_OP_MASK; struct bio *bio; =20 BUG_ON(!buffer_locked(bh)); @@ -1122,11 +1125,7 @@ static void __bh_submit(struct buffer_head *bh, blk_= opf_t opf, BUG_ON(buffer_delay(bh)); BUG_ON(buffer_unwritten(bh)); =20 - /* - * Only clear out a write error when rewriting - */ - if (test_set_buffer_req(bh) && (op =3D=3D REQ_OP_WRITE)) - clear_buffer_write_io_error(bh); + set_buffer_req(bh); =20 if (buffer_meta(bh)) opf |=3D REQ_META; diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c index a2028fbd4540..95998827ff01 100644 --- a/fs/ext4/fast_commit.c +++ b/fs/ext4/fast_commit.c @@ -209,6 +209,7 @@ static void ext4_end_buffer_io_sync(struct bio *bio) if (success) { ext4_debug("%s: Block %lld written", __func__, bh->b_blocknr); + clear_buffer_write_io_error(bh); } else { ext4_debug("%s: Block %lld write failed", __func__, bh->b_blocknr); diff --git a/fs/gfs2/lops.c b/fs/gfs2/lops.c index 3df6e4b7e8b9..7440e5b72f8a 100644 --- a/fs/gfs2/lops.c +++ b/fs/gfs2/lops.c @@ -179,6 +179,8 @@ static void gfs2_end_log_write_bh(struct gfs2_sbd *sdp,= struct folio *folio, do { if (error) mark_buffer_write_io_error(bh); + else + clear_buffer_write_io_error(bh); unlock_buffer(bh); next =3D bh->b_this_page; size -=3D bh->b_size; diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c index cd7ef783bd36..ebf6ba58ff4d 100644 --- a/fs/jbd2/commit.c +++ b/fs/jbd2/commit.c @@ -36,7 +36,9 @@ static void journal_end_buffer_io_sync(struct bio *bio) struct buffer_head *orig_bh =3D bh->b_private; =20 BUFFER_TRACE(bh, ""); - if (!success) + if (success) + clear_buffer_write_io_error(bh); + else mark_buffer_write_io_error(bh); if (orig_bh) { clear_and_wake_up_bit(BH_Shadow, &orig_bh->b_state); --=20 2.43.0