Christoph Hellwig <[email protected]> 于2025年11月24日周一 14:22写道： > > On Sat, Nov 22, 2025 at 02:38:59PM +0800, Stephen Zhang wrote: > > ======code analysis====== > > In kernel version 4.19, XFS handles extent I/O using the ioend structure, > > Linux 4.19 is more than four years old, and both the block I/O code > and the XFS/iomap code changed a lot since then. > > > changes the logic. Since there are still many code paths that use > > bio_chain, I am including these cleanups with the fix. This provides a > > reason > > to CC all related communities. That way, developers who are monitoring > > this can help identify similar problems if someone asks for help in the > > future, > > if that is the right analysis and fix. > > As many pointed out something in the analysis doesn't end up. How do > you even managed to call bio_chain_endio as almost no one should be > calling it. Are you using bcache? Are the others callers in the > obsolete kernel you are using? Are they calling it without calling > bio_endio first (which the bcache case does, and which is buggy). >
No, they are not using bcache. This problem is now believed to be related to the following commit: ------------- commit 9f9bc034b84958523689347ee2bdd9c660008e5e Author: Brian Foster <[email protected]> Date: Fri Feb 1 09:14:22 2019 -0800 xfs: update fork seq counter on data fork changes diff --git a/fs/xfs/libxfs/xfs_iext_tree.c b/fs/xfs/libxfs/xfs_iext_tree.c index 771dd072015d..bc690f2409fa 100644 --- a/fs/xfs/libxfs/xfs_iext_tree.c +++ b/fs/xfs/libxfs/xfs_iext_tree.c @@ -614,16 +614,15 @@ xfs_iext_realloc_root( } static inline void xfs_iext_inc_seq(struct xfs_ifork *ifp, int state) { - if (state & BMAP_COWFORK) - WRITE_ONCE(ifp->if_seq, READ_ONCE(ifp->if_seq) + 1); + WRITE_ONCE(ifp->if_seq, READ_ONCE(ifp->if_seq) + 1); } ---------- Link: https://lore.kernel.org/linux-xfs/[email protected]/ --------- Without this commit, a race condition can occur between the EOF trim worker, sequential buffer writes, and writeback. This race causes writeback to use a stale iomap, which leads to I/O being sent to sectors that have already been trimmed. If there are no further objections or other insights regarding this issue, I will proceed with creating a v2 of this series. Thanks, shida
