From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f176.google.com (mail-yw1-f176.google.com [209.85.128.176]) (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 DF8473D6CD7 for ; Sat, 1 Aug 2026 22:01:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785621701; cv=none; b=VYrp/Dbo9wOdn2mb2OJSR0NBzlWLoIiaFn4DKScPhsRv9j5ZY9Dle4Rhk94rTczUpugHj08/N3GG0vgTSpy/SJAgVI9588Q/6USleYvgt5G3gqx5V2LE+g1OA36GgxryUYD03dx/ly4KIxQ3VG5pN77lcmeDlpOHaaiRFlIclBk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785621701; c=relaxed/simple; bh=EXr243hgt49VO+NVV7qJVCHwNBqwGmV0A3daLRpsT44=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=n2h5z3K2U46vbz9YrC5lBsm3ckcWpXSs3wtOF+nV+dyU9t442TC7um20XGjfBjiWE4Mm1YTCdAEoGpL5UYTfIh0b2O2Q20mo9NSPT3mqhRBFhRRwVBjgKzS4YMuSywnmRjBgPXxcBU0rrvvd7ovsrgb3YGrjRf6xVQFNyqYEl00= 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=FF28+Kuh; arc=none smtp.client-ip=209.85.128.176 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="FF28+Kuh" Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-81dfdbd86d1so22032047b3.1 for ; Sat, 01 Aug 2026 15:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785621697; x=1786226497; 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=/eXvH9gfEzZ90R61WLxV17LvM97s4H8IYIhHdEQdhoQ=; b=FF28+KuhquhcwhUW1t3r3FnKppUtVxgbS1fAVBc40GkGsogkWB6f4tX2bJuPO7swj1 IBzsiWFMWtzYZvFGGE6IRe4WenwQnTr5AJ4fwrmKsTYgsj+tk/ndiNbOHj4pxTk2fong BzAiqRNqRaye0mpxyrRet+Xk2epn8o/uuqiver6FOMP/hzX21gdTUpq+qoXlMQcEE7wk MCD8I4HlrXQ5zqMKeoBxOlG21ndWHObySTDUTtgqKt4FpCvszBYDYCksD3pA1xSdVvKi XRQj9r1AypKIq3HIJgqFjYDOgEg/c1xEoOVeDENtrVyPo6YKV4t6L//7XlR9iSTgO9e2 EHTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785621697; x=1786226497; 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=/eXvH9gfEzZ90R61WLxV17LvM97s4H8IYIhHdEQdhoQ=; b=hggpY/3sDtOiWtJslSDww7n1oXs7UizJi+zjrPfUxPk6O+RFEb+uZaLxzBL8RbggJa amnhtUShldFd7WxeUFZz50d2b7UYzH0/D+S8kMtQ1WwFbjWV1uMmoCGyYWBaisHMU986 kbq1GJWyHe6Z8PH+Q3RxnUpeza8+MpFa1hPdz/9uDLfalgG93nLtV7fYlmhzMt+iff/9 8ryAM95+tBAH7fDALLYmI/B3xQfyMwhaGPItZRkSupkRZjupPbCwYYHxrZmrRTcyYjRa bO+ouht70bWXN4WJz5SaPnNe6EZsh/68SPg10LgBUYiie033NPR5NPo5flZ35UI0ArFF mYrQ== X-Forwarded-Encrypted: i=1; AHgh+RpGYHeSg7FvkADJ4/r6w23YRUZ4VkfgijNN5/xbaeyVbtzGi5xojLroZz+Sz4QzygPRF77eOjiT1DaX3Co=@vger.kernel.org X-Gm-Message-State: AOJu0Yx8DsXjTqxSuhWtuETnDyYoqeOBXKvwSle25GP2OMS29He//GTG E9LiKIZ+qoOM4Up9irZCCTv1ZEzyEb8kneWz/uWVHBMMKTNB0kL9+Au1 X-Gm-Gg: AR+sD11Yjb4cYoi9OLl0n3zHDYAi2l3f8abQW/nkZ4fegrunVyFrSYrraV3r22uLgHT +6r/AQn5bUnkaexx7r/kn1VOFZkafD/GC6jqHS0NrD8bd8c2+PWIA7a4O3DZ99jgbS24omcVzJw pPm+UD4fftgdh3NP+uGIgPDcpK8mgDRzjok2bcsMfh0zjrthqATwIr52zxX6nJErZDguLMA6wDa XYkEjt9CgFnA3Kpa3tPpcAd+bb0eRwhbHcGWmlGlAuJbm0GNqIwHfSAWAFlishwGGqY/02rPVHw 4nOwjk11cJhQuANJTpg9uClQIxyypatb30MQmdRa7RRoTL1YGlm7mlOMhAIdDZ+Eskw1SMVO+Bf aR4ks1vqcWlX+psoxhQRzBhzcdTvthcoJNIgzkvEljB1HI1QZH/6YWmKNA0FkxfJBjkDdvO1alC 3n6aeobfHM96uDhzUvThvZsXoYzKMCA39zckafBaLP1ip28m1gRT3weGNUKYPhe4NGY9eDRGamP ccdd2nsfCTY/jiLRQ== X-Received: by 2002:a05:690c:6601:b0:81e:c7e5:df5d with SMTP id 00721157ae682-81fd4b51de3mr65716127b3.17.1785621697195; Sat, 01 Aug 2026 15:01:37 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 00721157ae682-81fcd0d6fbbsm29903767b3.25.2026.08.01.15.01.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 01 Aug 2026 15:01:36 -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 , 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-karma-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, Chao Shi Subject: [PATCH 19/19] buffer: stop clearing BH_Uptodate when a write fails Date: Sat, 1 Aug 2026 18:01:03 -0400 Message-ID: <3aa278c3b75de2bca8a94ec0c0e40922b1170881.1785621505.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: 8bit 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, so the clears can go. Found by FuzzNvme. Signed-off-by: Chao Shi --- fs/buffer.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/buffer.c b/fs/buffer.c index ac978d9090c2..0002f0736398 100644 --- a/fs/buffer.c +++ b/fs/buffer.c @@ -207,7 +207,6 @@ void bh_end_write(struct bio *bio) } else { buffer_io_error(bh, ", lost sync page write"); mark_buffer_write_io_error(bh); - clear_buffer_uptodate(bh); } unlock_buffer(bh); } @@ -441,7 +440,6 @@ void bh_end_async_write(struct bio *bio) } else { buffer_io_error(bh, ", lost async page write"); mark_buffer_write_io_error(bh); - clear_buffer_uptodate(bh); } first = folio_buffers(folio); -- 2.43.0