[Bug 203947] [xfstests generic/475]: general protection fault: 0000 [#1] RIP: 0010:xfs_setfilesize_ioend+0xb1/0x220 [xfs]

[bugzilla-daemon@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=203947

Darrick J. Wong (djwong+kernel@djwong.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djwong+kernel@djwong.org

--- Comment #2 from Darrick J. Wong (djwong+kernel@djwong.org) ---
Hmm... so we're clearly in a situation where we have ioend A -> ioend B and
we're trying to merge A and B.  A has a setfilesize transaction and B does not,
but current code assumes that if A has one then B must have one and that it
must cancel B's.  Then we crash trying to cancel the transaction that B doesn't
have.

How do we end up in this situation?  I can't trigger it on my systems, but I
guess this sounds plausible:

1. Dirty pages 0, 1, and 2 of an empty file.

2. Writeback gets scheduled for pages 0 and 2, creating ioends A and C.  Both
ioends describe writes past the on-disk isize so we allocate transactions.

3. ioend C completes immediately, sets the ondisk isize to (3 * PAGESIZE).

4. Writeback gets scheduled for page 1, creating ioend B.  ioend B describes a
write within the on-disk isize so we do not allocate setfilesize transaction.

5. ioend A and B complete and are sorted into the per-inode ioend completion
list.  xfs_ioend_try_merge looks at ioend A, sees that ioend A has a
setfilesize transaction and that there's an ioend B that can be merged with A.

6. _try_merge tries to call xfs_setfilesize_ioend(ioend B, -1) to cancel ioend
B's transaction, but as we saw in (4), ioend B has no transaction and crashes.

I wonder how hard it will be to write a regression test for this, since it
requires fairly tight timing?

Coincidentally, Christoph just posted "xfs: allow merging ioends over append
boundaries" which I think fixes this problem.  Zorro, can you apply it and
retry?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.