[PATCH] xfs: fix slab-use-after-free in xrep_newbt_free()

[PATCH] xfs: fix slab-use-after-free in xrep_newbt_free()

[vienna-0FFH]

syzbot reported a slab-use-after-free read in xfs_defer_item_unpause()
while online repair was rebuilding a bmap btree:

  BUG: KASAN: slab-use-after-free in xfs_defer_item_unpause+0x116/0x250
  Read of size 4 at addr ffff8880132c127c by task syz.0.0/5327
  Call Trace:
   xfs_defer_item_unpause
   xrep_newbt_free+0x3fe/0x5f0
   xrep_bmap_build_new_fork+0x5a9/0x740
   xrep_bmap
   xrep_attempt
   xfs_scrub_metadata

The buggy address belongs to the object at ffff8880132c1240,
which belongs to the cache xfs_defer_pending of size 64.

xrep_newbt_add_blocks() attaches a paused EFI to the repair transaction
for each space reservation so that the blocks are reclaimed if the
system goes down before the new btree is committed.  If a later
xrep_defer_finish() fails (e.g. metadata I/O errors while staging the
new btree), xfs_defer_finish_noroll() shuts the filesystem down and
xfs_defer_cancel_list() frees all pending deferred work items, which
includes the paused EFIs referenced by resv->autoreap.

The repair then unwinds through xrep_newbt_cancel() -> xrep_newbt_free().
That function notices the shutdown and jumps to the junkit label, which
calls xfs_alloc_commit_autoreap() for each leftover reservation.  That
unpauses the deferred item through the stale pointer, causing the
use-after-free.  The report confirms this: the object was allocated by
xfs_alloc_schedule_autoreap() from xrep_newbt_add_blocks(), and freed
by xfs_defer_cancel_list() from the failing xrep_defer_finish().

Beyond the use-after-free, unpausing the deferred item is pointless
once the filesystem has been shut down: the remaining deferred work
will be cancelled when the repair transaction is torn down, and any
EFI that was committed to the log before the failure is replayed by
log recovery on the next mount.

Fix this by only unpausing the autoreap when the filesystem is not shut
down.

Fixes: 6bb9ea8ecd2c ("xfs: log EFIs for all btree blocks being used to stage a btree")
Reported-by: syzbot+e7f24354da9f7915bc54@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=e7f24354da9f7915bc54
Cc: stable@vger.kernel.org
Signed-off-by: vienna-0FFH <viennaoffh@gmail.com>
---
 fs/xfs/scrub/newbt.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/fs/xfs/scrub/newbt.c b/fs/xfs/scrub/newbt.c
index 584076b..83558fd 100644
--- a/fs/xfs/scrub/newbt.c
+++ b/fs/xfs/scrub/newbt.c
@@ -516,10 +516,15 @@ junkit:
 	/*
 	 * If we still have reservations attached to @newbt, cleanup must have
 	 * failed and the filesystem is about to go down.  Clean up the incore
-	 * reservations and try to commit to freeing the space we used.
+	 * reservations.  If the filesystem is already shut down, leave the
+	 * autoreaps alone: a failed deferred finish has freed the pending
+	 * work items they point to, and nothing will ever finish deferred
+	 * work on a dead filesystem.  Any EFI that made it to the log is
+	 * replayed by log recovery.
 	 */
 	list_for_each_entry_safe(resv, n, &xnr->resv_list, list) {
-		xfs_alloc_commit_autoreap(sc->tp, &resv->autoreap);
+		if (!xfs_is_shutdown(sc->mp))
+			xfs_alloc_commit_autoreap(sc->tp, &resv->autoreap);
 		list_del(&resv->list);
 		xfs_perag_put(resv->pag);
 		kfree(resv);
-- 
2.43.0

Re: [PATCH] xfs: fix slab-use-after-free in xrep_newbt_free()

[Carlos Maiolino]

On Fri, Oct 16, 2026 at 04:55:36PM +0800, vienna-0FFH wrote:
> syzbot reported a slab-use-after-free read in xfs_defer_item_unpause()
> while online repair was rebuilding a bmap btree:
> 
>   BUG: KASAN: slab-use-after-free in xfs_defer_item_unpause+0x116/0x250
>   Read of size 4 at addr ffff8880132c127c by task syz.0.0/5327
>   Call Trace:
>    xfs_defer_item_unpause
>    xrep_newbt_free+0x3fe/0x5f0
>    xrep_bmap_build_new_fork+0x5a9/0x740
>    xrep_bmap
>    xrep_attempt
>    xfs_scrub_metadata
> 
> The buggy address belongs to the object at ffff8880132c1240,
> which belongs to the cache xfs_defer_pending of size 64.
> 
> xrep_newbt_add_blocks() attaches a paused EFI to the repair transaction
> for each space reservation so that the blocks are reclaimed if the
> system goes down before the new btree is committed.  If a later
> xrep_defer_finish() fails (e.g. metadata I/O errors while staging the
> new btree), xfs_defer_finish_noroll() shuts the filesystem down and
> xfs_defer_cancel_list() frees all pending deferred work items, which
> includes the paused EFIs referenced by resv->autoreap.
> 
> The repair then unwinds through xrep_newbt_cancel() -> xrep_newbt_free().
> That function notices the shutdown and jumps to the junkit label, which
> calls xfs_alloc_commit_autoreap() for each leftover reservation.  That
> unpauses the deferred item through the stale pointer, causing the
> use-after-free.  The report confirms this: the object was allocated by
> xfs_alloc_schedule_autoreap() from xrep_newbt_add_blocks(), and freed
> by xfs_defer_cancel_list() from the failing xrep_defer_finish().
> 
> Beyond the use-after-free, unpausing the deferred item is pointless
> once the filesystem has been shut down: the remaining deferred work
> will be cancelled when the repair transaction is torn down, and any
> EFI that was committed to the log before the failure is replayed by
> log recovery on the next mount.
> 
> Fix this by only unpausing the autoreap when the filesystem is not shut
> down.
> 
> Fixes: 6bb9ea8ecd2c ("xfs: log EFIs for all btree blocks being used to stage a btree")
> Reported-by: syzbot+e7f24354da9f7915bc54@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=e7f24354da9f7915bc54
> Cc: stable@vger.kernel.org
> Signed-off-by: vienna-0FFH <viennaoffh@gmail.com>

From Documentation/process/submitting-patches.rst:

"using a known identity (sorry, no anonymous contributions.)"

> ---
>  fs/xfs/scrub/newbt.c | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/xfs/scrub/newbt.c b/fs/xfs/scrub/newbt.c
> index 584076b..83558fd 100644
> --- a/fs/xfs/scrub/newbt.c
> +++ b/fs/xfs/scrub/newbt.c
> @@ -516,10 +516,15 @@ junkit:
>  	/*
>  	 * If we still have reservations attached to @newbt, cleanup must have
>  	 * failed and the filesystem is about to go down.  Clean up the incore
> -	 * reservations and try to commit to freeing the space we used.
> +	 * reservations.  If the filesystem is already shut down, leave the
> +	 * autoreaps alone: a failed deferred finish has freed the pending
> +	 * work items they point to, and nothing will ever finish deferred
> +	 * work on a dead filesystem.  Any EFI that made it to the log is
> +	 * replayed by log recovery.
>  	 */
>  	list_for_each_entry_safe(resv, n, &xnr->resv_list, list) {
> -		xfs_alloc_commit_autoreap(sc->tp, &resv->autoreap);
> +		if (!xfs_is_shutdown(sc->mp))
> +			xfs_alloc_commit_autoreap(sc->tp, &resv->autoreap);
>  		list_del(&resv->list);
>  		xfs_perag_put(resv->pag);
>  		kfree(resv);
> -- 
> 2.43.0
> 
> 

Re: [PATCH] xfs: fix slab-use-after-free in xrep_newbt_free()

[Zheng Shuhao]

Hi Carlos,

Thank you for the pointer, and my apologies for the confusion. This is
my first patch submission to the Linux kernel, and I was not aware of the
known-identity requirement for patch authorship and Signed-off-by.
Understood now; I will use my real name for all future submissions:

    Zheng Shuhao <viennaoffh@gmail.com>

(vienna-0FFH was my GitHub handle only.)

For reference, this is the testing I did on the patch before posting:

 * Built the patched tree with KASAN + XFS_DEBUG enabled; checkpatch.pl
   --strict reports 0 errors and 0 warnings.
 * Reproduced the use-after-free deterministically in QEMU on an
   unpatched kernel; the KASAN splat matches the syzbot report exactly
   (xfs_defer_item_unpause <- xrep_newbt_free <- xrep_bmap_build_new_fork,
   and the xfs_defer_pending object is freed by xfs_defer_finish_noroll).
 * With the patch applied, the same trigger produces no KASAN report: the
   scrub ioctl just returns -EIO and the shutdown path unwinds cleanly.
 * Regression runs on the patched kernel: all metadata scrub types,
   invalid scrub inputs (bad flags/generation/agno/type), and forced bmap
   btree rebuilds from 5 up to 1500 extents (covering both extents- and
   btree-format forks), with read-back verification of the files. No
   regressions; normal scrub/repair paths still succeed.

I can share the reproducer and test scripts if that is useful.

Would you prefer that I resend this as v2 with the correct
From:/Signed-off-by: lines, or can you fix up the authorship when
applying? Either way works for me.

Thanks,
Zheng Shuhao

Re: [PATCH] xfs: fix slab-use-after-free in xrep_newbt_free()

[Darrick J. Wong]

On Fri, Oct 16, 2026 at 04:55:36PM +0800, vienna-0FFH wrote:
> syzbot reported a slab-use-after-free read in xfs_defer_item_unpause()
> while online repair was rebuilding a bmap btree:
> 
>   BUG: KASAN: slab-use-after-free in xfs_defer_item_unpause+0x116/0x250
>   Read of size 4 at addr ffff8880132c127c by task syz.0.0/5327
>   Call Trace:
>    xfs_defer_item_unpause
>    xrep_newbt_free+0x3fe/0x5f0
>    xrep_bmap_build_new_fork+0x5a9/0x740
>    xrep_bmap
>    xrep_attempt
>    xfs_scrub_metadata
> 
> The buggy address belongs to the object at ffff8880132c1240,
> which belongs to the cache xfs_defer_pending of size 64.
> 
> xrep_newbt_add_blocks() attaches a paused EFI to the repair transaction
> for each space reservation so that the blocks are reclaimed if the
> system goes down before the new btree is committed.  If a later
> xrep_defer_finish() fails (e.g. metadata I/O errors while staging the
> new btree), xfs_defer_finish_noroll() shuts the filesystem down and
> xfs_defer_cancel_list() frees all pending deferred work items, which
> includes the paused EFIs referenced by resv->autoreap.
> 
> The repair then unwinds through xrep_newbt_cancel() -> xrep_newbt_free().
> That function notices the shutdown and jumps to the junkit label, which
> calls xfs_alloc_commit_autoreap() for each leftover reservation.  That
> unpauses the deferred item through the stale pointer, causing the
> use-after-free.  The report confirms this: the object was allocated by
> xfs_alloc_schedule_autoreap() from xrep_newbt_add_blocks(), and freed
> by xfs_defer_cancel_list() from the failing xrep_defer_finish().
> 
> Beyond the use-after-free, unpausing the deferred item is pointless
> once the filesystem has been shut down: the remaining deferred work
> will be cancelled when the repair transaction is torn down, and any
> EFI that was committed to the log before the failure is replayed by
> log recovery on the next mount.
> 
> Fix this by only unpausing the autoreap when the filesystem is not shut
> down.
> 
> Fixes: 6bb9ea8ecd2c ("xfs: log EFIs for all btree blocks being used to stage a btree")
> Reported-by: syzbot+e7f24354da9f7915bc54@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=e7f24354da9f7915bc54
> Cc: stable@vger.kernel.org
> Signed-off-by: vienna-0FFH <viennaoffh@gmail.com>
> ---
>  fs/xfs/scrub/newbt.c | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/xfs/scrub/newbt.c b/fs/xfs/scrub/newbt.c
> index 584076b..83558fd 100644
> --- a/fs/xfs/scrub/newbt.c
> +++ b/fs/xfs/scrub/newbt.c
> @@ -516,10 +516,15 @@ junkit:
>  	/*
>  	 * If we still have reservations attached to @newbt, cleanup must have
>  	 * failed and the filesystem is about to go down.  Clean up the incore
> -	 * reservations and try to commit to freeing the space we used.
> +	 * reservations.  If the filesystem is already shut down, leave the
> +	 * autoreaps alone: a failed deferred finish has freed the pending
> +	 * work items they point to, and nothing will ever finish deferred
> +	 * work on a dead filesystem.  Any EFI that made it to the log is
> +	 * replayed by log recovery.
>  	 */
>  	list_for_each_entry_safe(resv, n, &xnr->resv_list, list) {
> -		xfs_alloc_commit_autoreap(sc->tp, &resv->autoreap);
> +		if (!xfs_is_shutdown(sc->mp))

What if some other thread initiates the shutdown?

--D

> +			xfs_alloc_commit_autoreap(sc->tp, &resv->autoreap);
>  		list_del(&resv->list);
>  		xfs_perag_put(resv->pag);
>  		kfree(resv);
> -- 
> 2.43.0
> 
> 

Re: [PATCH] xfs: fix slab-use-after-free in xrep_newbt_free()

[Zheng Shuhao]

Hi Darrick,

Thanks. Re: "What if some other thread initiates the shutdown?"

That is what I tested. The paused autoreap dfps are freed by the failed
xrep_defer_finish() in the repair thread, no matter which thread sets the
shutdown. xfs_defer_finish_noroll()'s out_shutdown path forces the
shutdown before xfs_defer_cancel_list(), which frees every
xfs_defer_pending on the scrub transaction, including the paused autoreap
EFIs. resv->autoreap.dfp is dangling by the time junkit runs.

If the shutdown is already set before repair starts, the dfps may still be
alive, but unpausing them is a no-op: deferred work cannot progress on a
dead log, and scrub teardown cancels the transaction and frees the dfps.
Any EFI that reached the log is replayed at mount, which is exactly the
intended autoreap behavior for a repair that never committed its new
btree.

The guard cannot miss the dangling case, because the cancel that frees the
dfps happens after the shutdown is forced.

Testing: helper threads issue XFS_IOC_GOINGDOWN (LOGFLUSH and NOLOGFLUSH)
after the xfs_defer_item_pause trace event -- 1 to 8 threads, 0-100 ms
delays -- while the main thread force-rebuilds a bmap btree. Unpatched:
KASAN UAF every time in xrep_newbt_free() -> xfs_defer_item_unpause().
Patched: no splats, scrub returns -EIO; after remount the log replays,
free block count is unchanged, data reads back intact, xfs_repair -n is
clean. Healthy forced rebuilds still do the normal pause/unpause.

Thanks,
Zheng Shuhao

Re: [PATCH] xfs: fix slab-use-after-free in xrep_newbt_free()

[Carlos Maiolino]

On Fri, Oct 16, 2026 at 10:16:18PM +0800, Zheng Shuhao wrote:
> Hi Carlos,
> 
> Thank you for the pointer, and my apologies for the confusion. This is
> my first patch submission to the Linux kernel, and I was not aware of the

Please keep the context when replying and respond to messages "inline".
Giving this is your first patch, I'd suggest skimming through the guidelines
in the kernel documentation.

> known-identity requirement for patch authorship and Signed-off-by.
> Understood now; I will use my real name for all future submissions:
> 
>     Zheng Shuhao <viennaoffh@gmail.com>
> 
> (vienna-0FFH was my GitHub handle only.)
> 
> For reference, this is the testing I did on the patch before posting:
> 
>  * Built the patched tree with KASAN + XFS_DEBUG enabled; checkpatch.pl
>    --strict reports 0 errors and 0 warnings.

Good.

>  * Reproduced the use-after-free deterministically in QEMU on an
>    unpatched kernel; the KASAN splat matches the syzbot report exactly
>    (xfs_defer_item_unpause <- xrep_newbt_free <- xrep_bmap_build_new_fork,
>    and the xfs_defer_pending object is freed by xfs_defer_finish_noroll).
>  * With the patch applied, the same trigger produces no KASAN report: the
>    scrub ioctl just returns -EIO and the shutdown path unwinds cleanly.
>  * Regression runs on the patched kernel: all metadata scrub types,
>    invalid scrub inputs (bad flags/generation/agno/type), and forced bmap
>    btree rebuilds from 5 up to 1500 extents (covering both extents- and
>    btree-format forks), with read-back verification of the files. No
>    regressions; normal scrub/repair paths still succeed.
> 
> I can share the reproducer and test scripts if that is useful.

Yes, sharing the reproducer (and potentially hooking it up into
xfstests) is a good thing, specially giving the syzbot doesn't seem
to have a reproducer for it yet.

I'm also interested if you actually passed your patch through xfstests
before submitting it. There is no good fixing a bug if you create a
handful of others. Specialy agains scrub, online_repair (and maybe
fsstress_scrub) groups.

> 
> Would you prefer that I resend this as v2 with the correct
> From:/Signed-off-by: lines, or can you fix up the authorship when
> applying? Either way works for me.

You'll need to send a V2. But wait until your patch gets reviewed, you
don't need to send it right now.


> 
> Thanks,
> Zheng Shuhao
> 

Re: [PATCH] xfs: fix slab-use-after-free in xrep_newbt_free()

[Zheng Shuhao]

Hi Carlos,

I have to admit I was not sure how to reply to your last message, or
whether I should reply at all. You said to wait until the patch gets
reviewed before sending a V2, so I did not want to push or send noise to
the list. On the other hand, it has now been a few weeks without any
further review or comment, and staying silent did not seem right either.
So I am sending this short status note; if you would rather I simply
wait, please say so and I will do that.

I also wanted to close the two items you asked about earlier, since I
promised them and then went quiet.

> Yes, sharing the reproducer (and potentially hooking it up into
> xfstests) is a good thing, specially giving the syzbot doesn't seem
> to have a reproducer for it yet.

The reproducer is a standalone harness, not a syzkaller program. It
mounts a scratch XFS with rmapbt and reflink, starts an online repair
that rebuilds a btree-format inode fork, and then issues
XFS_IOC_GOINGDOWN (LOGFLUSH and NOLOGFLUSH) from 1 to 8 helper threads
at 0-100 ms after the xfs_defer_item_pause tracepoint.

On the unpatched kernel this produces the reported KASAN
slab-use-after-free in xrep_newbt_free() -> xfs_defer_item_unpause()
on every run. With the patch applied, the scrub ioctl returns -EIO, the
shutdown path unwinds, the log replays on remount, the free block count
is unchanged, file data reads back intact, and xfs_repair -n is clean.
Healthy forced rebuilds still take the normal pause/unpause path.

I can send the harness and logs, but I did not want to attach a large
tarball to the list without asking first.

> I'm also interested if you actually passed your patch through xfstests
> before submitting it. There is no good fixing a bug if you create a
> handful of others. Specialy agains scrub, online_repair (and maybe
> fsstress_scrub) groups.

I ran the patched kernel against the scrub and online-repair fuzzer
cases, plus fsstress_scrub. To be precise about the coverage:

 - Completed with a real verdict: xfs/351, 353, 355, 357, 359, 361,
   363, 365, 367, 369, 371, 373, 375, 377, 379, 381, 383, 385, 399,
   401, 403, 405, 411, 413, 415, 417, 426, 428, 430, 497, 730, 733,
   736, 786.
 - xfs/387, 389, 391, 393, 395, 397 were started but hit my per-test
   timeout before reaching a verdict. They are long directory/xattr
   walks; I am not counting them as passes.

No KASAN report was produced by the patched kernel. The failures I did
see are all reproducible on the unpatched baseline as well, so they are
pre-existing and not introduced by this patch:

 - xfs_btree.c:1814 in xfs_btree_decrement (xfs/361, and also xfs/373)
 - xfs_buf.c:389 stale-buffer assertion (xfs/363, 365, 367)
 - xfs_log_cil.c:546 empty-transaction assertion (xfs/369)
 - xfs_attr_leaf.c:168 attribute-leaf assertion (xfs/401)
 - null-ptr-deref in xfs_btree_simple_query_range, reached from
   xrep_dinode_count_rtgroup_rmaps (xfs/375, 377, 379, 385, 399, 413,
   415, 417). This one reproduces identically on the baseline kernel.

> You'll need to send a V2. But wait until your patch gets reviewed, you
> don't need to send it right now.

Understood. I am holding the V2 until there is review feedback. When I
send it, it will use the correct identity:

    From: Zheng Shuhao <viennaoffh@gmail.com>
    Signed-off-by: Zheng Shuhao <viennaoffh@gmail.com>

Is there anything you would like changed in the patch itself, or any
additional data you want before I send the V2? If it is more useful, I
can also send the reproducer and the per-test logs now, separately from
the patch.

Thanks,
Zheng Shuhao

Re: [PATCH] xfs: fix slab-use-after-free in xrep_newbt_free()

[Carlos Maiolino]

On Thu, Nov 05, 2026 at 08:45:52PM +0800, Zheng Shuhao wrote:
> Hi Carlos,
> 
> I have to admit I was not sure how to reply to your last message, or
> whether I should reply at all. You said to wait until the patch gets
> reviewed before sending a V2, so I did not want to push or send noise to
> the list. On the other hand, it has now been a few weeks without any
> further review or comment, and staying silent did not seem right either.

It's fine to ask for status once in a while, don't worry about it.
Common sense applies here of course. I.e. don't ask ever other day about
status :)

> So I am sending this short status note; if you would rather I simply
> wait, please say so and I will do that.
> 
> I also wanted to close the two items you asked about earlier, since I
> promised them and then went quiet.
> 
> > Yes, sharing the reproducer (and potentially hooking it up into
> > xfstests) is a good thing, specially giving the syzbot doesn't seem
> > to have a reproducer for it yet.
> 
> The reproducer is a standalone harness, not a syzkaller program. It
> mounts a scratch XFS with rmapbt and reflink, starts an online repair
> that rebuilds a btree-format inode fork, and then issues
> XFS_IOC_GOINGDOWN (LOGFLUSH and NOLOGFLUSH) from 1 to 8 helper threads
> at 0-100 ms after the xfs_defer_item_pause tracepoint.

Ok, this sounds as a good candidate for a xfstests case.

> 
> On the unpatched kernel this produces the reported KASAN
> slab-use-after-free in xrep_newbt_free() -> xfs_defer_item_unpause()
> on every run. With the patch applied, the scrub ioctl returns -EIO, the
> shutdown path unwinds, the log replays on remount, the free block count
> is unchanged, file data reads back intact, and xfs_repair -n is clean.
> Healthy forced rebuilds still take the normal pause/unpause path.
> 
> I can send the harness and logs, but I did not want to attach a large
> tarball to the list without asking first.

you don't usually need to send the logs. If you have the reproducer,
just attach it to the message in text/plain with instructions how to
run. So we can try locally.

> 
> > I'm also interested if you actually passed your patch through xfstests
> > before submitting it. There is no good fixing a bug if you create a
> > handful of others. Specialy agains scrub, online_repair (and maybe
> > fsstress_scrub) groups.
> 
> I ran the patched kernel against the scrub and online-repair fuzzer
> cases, plus fsstress_scrub. To be precise about the coverage:
> 
>  - Completed with a real verdict: xfs/351, 353, 355, 357, 359, 361,
>    363, 365, 367, 369, 371, 373, 375, 377, 379, 381, 383, 385, 399,
>    401, 403, 405, 411, 413, 415, 417, 426, 428, 430, 497, 730, 733,
>    736, 786.
>  - xfs/387, 389, 391, 393, 395, 397 were started but hit my per-test
>    timeout before reaching a verdict. They are long directory/xattr
>    walks; I am not counting them as passes.

This is a good start, but as I'm suggesting everybody sending patches,
please ensure at least it passes -g auto group in xfstests. Not sure
what specific timeout you're talking about, but you can even run it
locally on your machine, for example with virtme-ng.

> 
> No KASAN report was produced by the patched kernel. The failures I did
> see are all reproducible on the unpatched baseline as well, so they are
> pre-existing and not introduced by this patch:
> 
>  - xfs_btree.c:1814 in xfs_btree_decrement (xfs/361, and also xfs/373)
>  - xfs_buf.c:389 stale-buffer assertion (xfs/363, 365, 367)
>  - xfs_log_cil.c:546 empty-transaction assertion (xfs/369)
>  - xfs_attr_leaf.c:168 attribute-leaf assertion (xfs/401)
>  - null-ptr-deref in xfs_btree_simple_query_range, reached from
>    xrep_dinode_count_rtgroup_rmaps (xfs/375, 377, 379, 385, 399, 413,
>    415, 417). This one reproduces identically on the baseline kernel.
> 
> > You'll need to send a V2. But wait until your patch gets reviewed, you
> > don't need to send it right now.
> 
> Understood. I am holding the V2 until there is review feedback. When I
> send it, it will use the correct identity:
> 
>     From: Zheng Shuhao <viennaoffh@gmail.com>
>     Signed-off-by: Zheng Shuhao <viennaoffh@gmail.com>
> 
> Is there anything you would like changed in the patch itself, or any
> additional data you want before I send the V2? If it is more useful, I
> can also send the reproducer and the per-test logs now, separately from
> the patch.

Ok, please send a V2 then, and we'll continue from there