From: "Darrick J. Wong" <djwong@kernel.org>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
Christian Brauner <brauner@kernel.org>,
linux-fsdevel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [BUG] regression from 974c5e6139db "xfs: flag as supporting FOP_DONTCACHE" (double free on page?)
Date: Wed, 28 May 2025 18:56:37 -0700 [thread overview]
Message-ID: <20250529015637.GA8286@frogsfrogsfrogs> (raw)
In-Reply-To: <20250525083209.GS2023217@ZenIV>
On Sun, May 25, 2025 at 09:32:09AM +0100, Al Viro wrote:
> generic/127 with xfstests built on debian-testing (trixie) ends up with
> assorted memory corruption; trace below is with CONFIG_DEBUG_PAGEALLOC and
> CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT and it looks like a double free
> somewhere in iomap. Unfortunately, commit in question is just making
> xfs use the infrastructure built in earlier series - not that useful
> for isolating the breakage.
>
> [ 22.001529] run fstests generic/127 at 2025-05-25 04:13:23
> [ 35.498573] BUG: Bad page state in process kworker/2:1 pfn:112ce9
> [ 35.499260] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x3e 9
> [ 35.499764] flags: 0x800000000000000e(referenced|uptodate|writeback|zone=2)
> [ 35.500302] raw: 800000000000000e dead000000000100 dead000000000122 000000000
> [ 35.500786] raw: 000000000000003e 0000000000000000 00000000ffffffff 000000000
> [ 35.501248] page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
> [ 35.501624] Modules linked in: xfs autofs4 fuse nfsd auth_rpcgss nfs_acl nfs0
> [ 35.503209] CPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 Not tainted 6.14.0-rc1+ 7
> [ 35.503211] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.164
> [ 35.503212] Workqueue: xfs-conv/sdb1 xfs_end_io [xfs]
> [ 35.503279] Call Trace:
> [ 35.503281] <TASK>
> [ 35.503282] dump_stack_lvl+0x4f/0x60
> [ 35.503296] bad_page+0x6f/0x100
> [ 35.503300] free_frozen_pages+0x303/0x550
> [ 35.503301] iomap_finish_ioend+0xf6/0x380
> [ 35.503304] iomap_finish_ioends+0x83/0xc0
> [ 35.503305] xfs_end_ioend+0x64/0x140 [xfs]
> [ 35.503342] xfs_end_io+0x93/0xc0 [xfs]
> [ 35.503378] process_one_work+0x153/0x390
> [ 35.503382] worker_thread+0x2ab/0x3b0
>
> It's 4:30am here, so I'm going to leave attempts to actually debug that
> thing until tomorrow; I do have a kvm where it's reliably reproduced
> within a few minutes, so if anyone comes up with patches, I'll be able
> to test them.
>
> Breakage is still present in the current mainline ;-/
Hey Al,
Welll this certainly looks like the same report I made a month ago.
I'll go run 6.15 final (with the #define RWF_DONTCACHE 0) overnight to
confirm if that makes my problem go away. If these are one and the same
bug, then thank you for finding a better reproducer! :)
https://lore.kernel.org/linux-fsdevel/20250416180837.GN25675@frogsfrogsfrogs/
--D
next prev parent reply other threads:[~2025-05-29 1:56 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-25 8:32 [BUG] regression from 974c5e6139db "xfs: flag as supporting FOP_DONTCACHE" (double free on page?) Al Viro
2025-05-25 18:02 ` Al Viro
2025-05-25 18:06 ` Al Viro
2025-05-25 19:12 ` Vlastimil Babka
2025-05-25 20:32 ` Linus Torvalds
2025-05-25 20:48 ` Matthew Wilcox
2025-05-25 20:54 ` Linus Torvalds
2025-05-25 21:49 ` Al Viro
2025-05-25 22:05 ` Linus Torvalds
2025-05-26 13:05 ` Jens Axboe
2025-05-26 15:06 ` Jens Axboe
2025-05-26 15:31 ` Vlastimil Babka
2025-05-26 15:58 ` Jens Axboe
2025-05-26 17:38 ` Jens Axboe
2025-05-26 23:56 ` Al Viro
2025-05-27 0:58 ` Jens Axboe
2025-05-27 1:24 ` Al Viro
2025-05-27 1:29 ` Jens Axboe
2025-05-27 0:51 ` Trond Myklebust
2025-05-27 0:56 ` Jens Axboe
2025-05-29 1:56 ` Darrick J. Wong [this message]
2025-05-31 1:10 ` Darrick J. Wong
2025-05-31 21:00 ` Jens Axboe
2025-06-02 9:04 ` Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250529015637.GA8286@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.