On 26/01/07 02:52AM, Christian Heusel wrote:
On 26/01/06 05:10PM, Leo Martins wrote:
On Tue, 06 Jan 2026 22:01:58 +0000 "Gideon Farrell" <gideon@solnickfarrell.co.uk> wrote:
Hi there,
I recently experienced a type of crash I haven't seen before on this system which seems to originate in __btrfs_release_delayed_node on Kernel 6.18.2-arch2-1.
Hey, thanks for the report. This looks very similar to a different report that has been fixed in 6.19-rc5. Report: https://lore.kernel.org/oe-lkp/202511262228.6dda231e-lkp@intel.com/
I think this is the issue we have been seeing on the Arch Linux infrastructure aswell, see this issue for reference:
https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/788#note_3854...
This has caused us to downgrade the kernel on all hosts in our infrastructure due to the crashes caused by this.
Fix: https://lore.kernel.org/linux-btrfs/7c89417ac3352ce3cb0a6373a1746155c1e2754d...
Please let me know if this fixes your issue.
So far we have not found a good lab-setting to reproduce the issue outside of the production machines workloads (but we have also not looked into the issue a lot).
Do you have a good reproducer already that we could use to verify the fix?
Also the fix is not yet even scheduled for inclusion in the stable trees, since it is still not in linus tree right?
Sorry, I messed up here! I got fooled by the output of `git log --grep` and therefore missed the commit! As pointed out by heftig on gitlab the commit already is present in 6.18.3 which I'll try to roll out to our systems shortly! :)
Here's the stack trace:
```
Are these the first refcount_t: warnings in your dmesg? I would expect an earlier warning that looks like refcount_t: addition on 0; use-after-free.
This is what our stacktrace looks like:
[...]
Cheers, Chris