[syzbot] [gfs2?] WARNING in gfs2_fill_super

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 09c0f7f1bcdb Add linux-next specific files for 20260323
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=142ade02580000
kernel config: https://syzkaller.appspot.com/x/.config?x=c0c30527ccbcb0f2
dashboard link: https://syzkaller.appspot.com/bug?extid=b441db1854c360b83221
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=145e16da580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16b33b52580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/c320a7a1bc69/disk-09c0f7f1.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/4a5b231960d2/vmlinux-09c0f7f1.xz
kernel image: https://storage.googleapis.com/syzbot-assets/8e2b84b9674d/bzImage-09c0f7f1.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/a4941369e2d2/mount_0.gz
fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=170daa06580000)

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+b441db...@syzkaller.appspotmail.com

loop4: detected capacity change from 0 to 32768
------------[ cut here ]------------
kmem_cache of name 'gfs2-bufdata/syz:syz' already exists
WARNING: mm/slab_common.c:112 at kmem_cache_sanity_check mm/slab_common.c:111 [inline], CPU#1: syz.4.21/6090
WARNING: mm/slab_common.c:112 at __kmem_cache_create_args+0xac/0x440 mm/slab_common.c:352, CPU#1: syz.4.21/6090
Modules linked in:
CPU: 1 UID: 0 PID: 6090 Comm: syz.4.21 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026
RIP: 0010:kmem_cache_sanity_check mm/slab_common.c:111 [inline]
RIP: 0010:__kmem_cache_create_args+0xaf/0x440 mm/slab_common.c:352
Code: 86 8e 4d 8b 24 24 49 81 fc 18 68 86 8e 74 20 49 8b 7c 24 f8 48 89 de e8 3f 5c 9c 09 85 c0 75 e2 48 8d 3d 54 70 06 0e 48 89 de <67> 48 0f b9 3a 48 89 df be 20 00 00 00 e8 df 5d 9c 09 48 85 c0 0f
RSP: 0018:ffffc900025f7948 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88807ac1dac0 RCX: 0000000000000005
RDX: 000000007ac1da04 RSI: ffff88807ac1dac0 RDI: ffffffff9016e0b0
RBP: 0000000000000000 R08: ffffffff901246f7 R09: 1ffffffff20248de
R10: dffffc0000000000 R11: fffffbfff20248df R12: ffff8881442f37e0
R13: ffff88807caa0000 R14: 0000000000000050 R15: ffffc900025f7a60
FS: 000055555c597500(0000) GS:ffff888125548000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fefd604b544 CR3: 0000000035aa2000 CR4: 00000000003526f0
Call Trace:
<TASK>
__kmem_cache_create include/linux/slab.h:390 [inline]
gfs2_fill_super+0x13a4/0x21d0 fs/gfs2/ops_fstype.c:1202
get_tree_bdev_flags+0x431/0x4f0 fs/super.c:1694
gfs2_get_tree+0x51/0x1e0 fs/gfs2/ops_fstype.c:1342
vfs_get_tree+0x92/0x2a0 fs/super.c:1754
fc_mount fs/namespace.c:1193 [inline]
do_new_mount_fc fs/namespace.c:3764 [inline]
do_new_mount+0x341/0xd30 fs/namespace.c:3840
do_mount fs/namespace.c:4173 [inline]
__do_sys_mount fs/namespace.c:4372 [inline]
__se_sys_mount+0x31d/0x420 fs/namespace.c:4349
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fefd5f9da0a
Code: 48 c7 c2 e8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fff558aaf78 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007fff558ab000 RCX: 00007fefd5f9da0a
RDX: 00002000000124c0 RSI: 0000200000012500 RDI: 00007fff558aafc0
RBP: 00002000000124c0 R08: 00007fff558ab000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000200000012500
R13: 00007fff558aafc0 R14: 00000000000125c7 R15: 0000200000000180
</TASK>
----------------
Code disassembly (best guess):
0: 86 8e 4d 8b 24 24 xchg %cl,0x24248b4d(%rsi)
6: 49 81 fc 18 68 86 8e cmp $0xffffffff8e866818,%r12
d: 74 20 je 0x2f
f: 49 8b 7c 24 f8 mov -0x8(%r12),%rdi
14: 48 89 de mov %rbx,%rsi
17: e8 3f 5c 9c 09 call 0x99c5c5b
1c: 85 c0 test %eax,%eax
1e: 75 e2 jne 0x2
20: 48 8d 3d 54 70 06 0e lea 0xe067054(%rip),%rdi # 0xe06707b
27: 48 89 de mov %rbx,%rsi
* 2a: 67 48 0f b9 3a ud1 (%edx),%rdi <-- trapping instruction
2f: 48 89 df mov %rbx,%rdi
32: be 20 00 00 00 mov $0x20,%esi
37: e8 df 5d 9c 09 call 0x99c5e1b
3c: 48 85 c0 test %rax,%rax
3f: 0f .byte 0xf


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-...@vger.kernel.org, syzkall...@googlegroups.com.

***

Subject: [PATCH] gfs2: fix missing kmem_cache_destroy() of sd_bufdata in gfs2_kill_sb()
Author: karti...@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master


gfs2_fill_super() creates a per-superblock slab cache for gfs2_bufdata
objects with a name derived from the filesystem name:

sdp->sd_bufdata = kmem_cache_create("gfs2-bufdata/<fsname>", ...);

However, gfs2_kill_sb() does not call kmem_cache_destroy() on this
cache during unmount. This means the cache persists after the filesystem
is unmounted, and a subsequent mount attempt will try to create a cache
with the same name, triggering a warning in kmem_cache_sanity_check():

kmem_cache of name 'gfs2-bufdata/syz:syz' already exists
WARNING: mm/slab_common.c:112

The error path in gfs2_fill_super() already handles this correctly via
the fail_bufdata label. Add the missing kmem_cache_destroy() call to
gfs2_kill_sb() to fix the leak on the normal unmount path.

Reported-by: syzbot+b441db...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=b441db1854c360b83221
Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>
---
fs/gfs2/ops_fstype.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/gfs2/ops_fstype.c b/fs/gfs2/ops_fstype.c
index b44adb40635d..38e4a9dc96bc 100644
--- a/fs/gfs2/ops_fstype.c
+++ b/fs/gfs2/ops_fstype.c
@@ -1803,7 +1803,7 @@ static void gfs2_kill_sb(struct super_block *sb)
set_bit(SDF_KILL, &sdp->sd_flags);
gfs2_flush_delete_work(sdp);
destroy_workqueue(sdp->sd_delete_wq);
-
+ kmem_cache_destroy(sdp->sd_bufdata);
kill_block_super(sb);
}

--
2.43.0

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
KASAN: slab-use-after-free Read in gfs2_put_super

==================================================================
BUG: KASAN: slab-use-after-free in gfs2_put_super+0x83f/0x890 fs/gfs2/super.c:642
Read of size 1 at addr ffff888144ab83c0 by task syz-executor/6382

CPU: 1 UID: 0 PID: 6382 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026

Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_address_description+0x55/0x1e0 mm/kasan/report.c:378
print_report+0x58/0x70 mm/kasan/report.c:482
kasan_report+0x117/0x150 mm/kasan/report.c:595
__kasan_check_byte+0x2a/0x40 mm/kasan/common.c:574
kasan_check_byte include/linux/kasan.h:402 [inline]
kmem_cache_destroy+0x21/0x170 mm/slab_common.c:531
gfs2_put_super+0x83f/0x890 fs/gfs2/super.c:642
generic_shutdown_super+0x13d/0x2d0 fs/super.c:646
kill_block_super+0x44/0x90 fs/super.c:1725
deactivate_locked_super+0xbc/0x130 fs/super.c:476
cleanup_mnt+0x437/0x4d0 fs/namespace.c:1312
task_work_run+0x1d9/0x270 kernel/task_work.c:233
resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
__exit_to_user_mode_loop kernel/entry/common.c:67 [inline]
exit_to_user_mode_loop+0xed/0x480 kernel/entry/common.c:98
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:238 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:269 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:325 [inline]
do_syscall_64+0x32d/0xf80 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f52def9d9d7
Code: a2 c7 05 1c fd 24 00 00 00 00 00 eb 96 e8 e1 12 00 00 90 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 01 c3 48 c7 c2 e8 ff ff ff f7 d8 64 89 02 b8
RSP: 002b:00007fff0f5bdd58 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
RAX: 0000000000000000 RBX: 00007f52df032050 RCX: 00007f52def9d9d7
RDX: 0000000000000000 RSI: 0000000000000009 RDI: 00007fff0f5bde10
RBP: 00007fff0f5bde10 R08: 00007fff0f5bee10 R09: 00000000ffffffff
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff0f5beea0
R13: 00007f52df032050 R14: 000000000001fbd6 R15: 00007fff0f5beee0
</TASK>

Allocated by task 6561:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
unpoison_slab_object mm/kasan/common.c:340 [inline]
__kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366
kasan_slab_alloc include/linux/kasan.h:253 [inline]
slab_post_alloc_hook mm/slub.c:4569 [inline]
slab_alloc_node mm/slub.c:4898 [inline]
kmem_cache_alloc_noprof+0x2bc/0x650 mm/slub.c:4905
create_cache mm/slab_common.c:249 [inline]
__kmem_cache_create_args+0x2eb/0x440 mm/slab_common.c:380

__kmem_cache_create include/linux/slab.h:390 [inline]
gfs2_fill_super+0x13a4/0x21d0 fs/gfs2/ops_fstype.c:1202
get_tree_bdev_flags+0x431/0x4f0 fs/super.c:1694
gfs2_get_tree+0x51/0x1e0 fs/gfs2/ops_fstype.c:1342
vfs_get_tree+0x92/0x2a0 fs/super.c:1754
fc_mount fs/namespace.c:1193 [inline]
do_new_mount_fc fs/namespace.c:3764 [inline]
do_new_mount+0x341/0xd30 fs/namespace.c:3840
do_mount fs/namespace.c:4173 [inline]
__do_sys_mount fs/namespace.c:4372 [inline]
__se_sys_mount+0x31d/0x420 fs/namespace.c:4349
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 6382:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2689 [inline]
slab_free mm/slub.c:6242 [inline]
kmem_cache_free+0x182/0x650 mm/slub.c:6369
kobject_cleanup lib/kobject.c:689 [inline]
kobject_release lib/kobject.c:720 [inline]
kref_put include/linux/kref.h:65 [inline]
kobject_put+0x228/0x560 lib/kobject.c:737
gfs2_kill_sb+0x435/0x450 fs/gfs2/ops_fstype.c:1806
deactivate_locked_super+0xbc/0x130 fs/super.c:476
cleanup_mnt+0x437/0x4d0 fs/namespace.c:1312
task_work_run+0x1d9/0x270 kernel/task_work.c:233
resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
__exit_to_user_mode_loop kernel/entry/common.c:67 [inline]
exit_to_user_mode_loop+0xed/0x480 kernel/entry/common.c:98
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:238 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:269 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:325 [inline]
do_syscall_64+0x32d/0xf80 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f

The buggy address belongs to the object at ffff888144ab83c0
which belongs to the cache kmem_cache of size 232
The buggy address is located 0 bytes inside of
freed 232-byte region [ffff888144ab83c0, ffff888144ab84a8)

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888144ab8640 pfn:0x144ab8
flags: 0x57ff00000000200(workingset|node=1|zone=2|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 057ff00000000200 ffff88813fea7000 ffffea000512ae50 ffff888140400108
raw: ffff888144ab8640 00000008000c0005 00000000f5000000 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x52cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP), pid 1, tgid 1 (swapper/0), ts 24382700756, free_ts 6084051605
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x231/0x280 mm/page_alloc.c:1859
prep_new_page mm/page_alloc.c:1867 [inline]
get_page_from_freelist+0x2418/0x24b0 mm/page_alloc.c:3926
__alloc_frozen_pages_noprof+0x233/0x3d0 mm/page_alloc.c:5213
alloc_pages_mpol+0x235/0x490 mm/mempolicy.c:2484
alloc_slab_page mm/slub.c:3276 [inline]
allocate_slab+0x83/0x660 mm/slub.c:3467
new_slab mm/slub.c:3525 [inline]
___slab_alloc+0x154/0x6c0 mm/slub.c:4444
__slab_alloc_node mm/slub.c:4510 [inline]
slab_alloc_node mm/slub.c:4886 [inline]
kmem_cache_alloc_noprof+0x12d/0x650 mm/slub.c:4905
create_cache mm/slab_common.c:249 [inline]
__kmem_cache_create_args+0x2eb/0x440 mm/slab_common.c:380
__kmem_cache_create include/linux/slab.h:390 [inline]
btrfs_prelim_ref_init+0xad/0x110 fs/btrfs/backref.c:200
init_btrfs_fs+0x6d/0x1f0 fs/btrfs/super.c:2701
do_one_initcall+0x250/0x870 init/main.c:1384
do_initcall_level+0x104/0x190 init/main.c:1446
do_initcalls+0x59/0xa0 init/main.c:1462
kernel_init_freeable+0x2a6/0x3e0 init/main.c:1694
kernel_init+0x1d/0x1d0 init/main.c:1584
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
page last free pid 1 tgid 1 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1403 [inline]
__free_frozen_pages+0xbc7/0xd30 mm/page_alloc.c:2944
vfree+0x1d1/0x2f0 mm/vmalloc.c:3472
free_partitions block/partitions/core.c:114 [inline]
check_partition block/partitions/core.c:173 [inline]
blk_add_partitions block/partitions/core.c:590 [inline]
bdev_disk_changed+0x923/0x1770 block/partitions/core.c:694
blkdev_get_whole+0x380/0x510 block/bdev.c:764
bdev_open+0x31e/0xd30 block/bdev.c:973
bdev_file_open_by_dev+0x1be/0x240 block/bdev.c:1075
disk_scan_partitions+0x1c1/0x2c0 block/genhd.c:387
add_disk_final block/genhd.c:416 [inline]
add_disk_fwnode+0x321/0x480 block/genhd.c:610
add_disk include/linux/blkdev.h:793 [inline]
brd_alloc+0x5b9/0x7c0 drivers/block/brd.c:340
brd_init+0xc1/0x120 drivers/block/brd.c:420
do_one_initcall+0x250/0x870 init/main.c:1384
do_initcall_level+0x104/0x190 init/main.c:1446
do_initcalls+0x59/0xa0 init/main.c:1462
kernel_init_freeable+0x2a6/0x3e0 init/main.c:1694
kernel_init+0x1d/0x1d0 init/main.c:1584
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158

Memory state around the buggy address:
ffff888144ab8280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff888144ab8300: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc
>ffff888144ab8380: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
^
ffff888144ab8400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888144ab8480: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc
==================================================================


Tested on:

commit: 85964cdc Add linux-next specific files for 20260324
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=146faa06580000
kernel config: https://syzkaller.appspot.com/x/.config?x=84ab18c6f45b39c

dashboard link: https://syzkaller.appspot.com/bug?extid=b441db1854c360b83221
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8

patch: https://syzkaller.appspot.com/x/patch.diff?x=123a4b52580000

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-...@vger.kernel.org, syzkall...@googlegroups.com.

***

Subject: [PATCH] gfs2: fix duplicate kmem_cache name on concurrent mounts

Author: karti...@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master

When gfs2_fill_super() creates the per-filesystem bufdata cache, it
uses sd_fsname as part of the cache name:

sdp->sd_bufdata = kmem_cache_create("gfs2-bufdata/<fsname>", ...);

At this point sd_fsname is set from sd_table_name (e.g. "syz:syz"),
which is the same for all concurrent mounts of the same device.
The unique suffix (.s for spectator, .N for journal ID) is only
added to sd_fsname AFTER wait_on_journal() completes, since the
journal ID is assigned by the locking subsystem during mount.

With multiple concurrent mounts of the same device (as triggered by
syzkaller with procs:5), multiple calls to gfs2_fill_super() all try
to create a cache named "gfs2-bufdata/syz:syz" before any of them
reaches the point where sd_fsname becomes unique, triggering:

kmem_cache of name 'gfs2-bufdata/syz:syz' already exists
WARNING: mm/slab_common.c:112

Fix this by moving the bufdata cache creation to after
wait_on_journal() completes and sd_fsname has been updated with its
unique suffix. Also move the fail_bufdata cleanup label accordingly
in the error unwind path.

Reported-by: syzbot+b441db...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=b441db1854c360b83221

Fixes: 767e4de3ffce ("gfs2: per-filesystem bufdata cache")

Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>
---

fs/gfs2/ops_fstype.c | 21 ++++++++++-----------
1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/fs/gfs2/ops_fstype.c b/fs/gfs2/ops_fstype.c
index b44adb40635d..7f8e04c11494 100644
--- a/fs/gfs2/ops_fstype.c
+++ b/fs/gfs2/ops_fstype.c
@@ -1198,17 +1198,9 @@ static int gfs2_fill_super(struct super_block *sb, struct fs_context *fc)
if (!sdp->sd_delete_wq)
goto fail_glock_wq;

- char *bufdata_name = kasprintf(GFP_KERNEL, "gfs2-bufdata/%s", sdp->sd_fsname);
- sdp->sd_bufdata = kmem_cache_create(bufdata_name,
- sizeof(struct gfs2_bufdata),
- 0, 0, NULL);
- kfree(bufdata_name);
- if (!sdp->sd_bufdata)
- goto fail_delete_wq;
-
error = gfs2_sys_fs_add(sdp);
if (error)
- goto fail_bufdata;
+ goto fail_delete_wq;

gfs2_create_debugfs_file(sdp);

@@ -1255,6 +1247,14 @@ static int gfs2_fill_super(struct super_block *sb, struct fs_context *fc)
snprintf(sdp->sd_fsname, sizeof(sdp->sd_fsname), "%s.%u",
sdp->sd_table_name, sdp->sd_lockstruct.ls_jid);

+ char *bufdata_name = kasprintf(GFP_KERNEL, "gfs2-bufdata/%s", sdp->sd_fsname);
+ sdp->sd_bufdata = kmem_cache_create(bufdata_name,
+ sizeof(struct gfs2_bufdata),
+ 0, 0, NULL);
+ kfree(bufdata_name);
+ if (!sdp->sd_bufdata)
+ goto fail_sb;
+
error = init_inodes(sdp, DO);
if (error)
goto fail_sb;
@@ -1304,6 +1304,7 @@ static int gfs2_fill_super(struct super_block *sb, struct fs_context *fc)
if (sb->s_root)
dput(sb->s_root);
sb->s_root = NULL;
+ kmem_cache_destroy(sdp->sd_bufdata);
fail_locking:
init_locking(sdp, &mount_gh, UNDO);
fail_lm:
@@ -1313,8 +1314,6 @@ static int gfs2_fill_super(struct super_block *sb, struct fs_context *fc)
fail_debug:
gfs2_delete_debugfs_file(sdp);
gfs2_sys_fs_del(sdp);
-fail_bufdata:
- kmem_cache_destroy(sdp->sd_bufdata);
fail_delete_wq:
destroy_workqueue(sdp->sd_delete_wq);
fail_glock_wq:
--
2.43.0

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+b441db...@syzkaller.appspotmail.com
Tested-by: syzbot+b441db...@syzkaller.appspotmail.com

Tested on:

commit: 85964cdc Add linux-next specific files for 20260324
git tree: linux-next

console output: https://syzkaller.appspot.com/x/log.txt?x=17e86a06580000

kernel config: https://syzkaller.appspot.com/x/.config?x=84ab18c6f45b39c
dashboard link: https://syzkaller.appspot.com/bug?extid=b441db1854c360b83221
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8

patch: https://syzkaller.appspot.com/x/patch.diff?x=1529de02580000

Note: testing is done by a robot and is best-effort only.