[syzbot] [gfs2?] WARNING in filename_mkdirat

[syzbot] [gfs2?] WARNING in filename_mkdirat

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    0f2acd3148e0 Merge tag 'm68knommu-for-v7.0' of git://git.k..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15331c02580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=ac00553de86d6bf0
dashboard link: https://syzkaller.appspot.com/bug?extid=0ea5108a1f5fb4fcc2d8
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=146b295a580000

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-0f2acd31.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/b7d134e71e9c/vmlinux-0f2acd31.xz
kernel image: https://storage.googleapis.com/syzbot-assets/b18643058ceb/bzImage-0f2acd31.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/bbfed09077d3/mount_1.gz
  fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=106b295a580000)

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

------------[ cut here ]------------
DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)): count = 0x0, magic = 0xffff88804a18c9b8, owner = 0x0, curr 0xffff888000ec2480, list empty
WARNING: kernel/locking/rwsem.c:1381 at __up_write kernel/locking/rwsem.c:1380 [inline], CPU#0: syz.0.53/5774
WARNING: kernel/locking/rwsem.c:1381 at up_write+0x2d6/0x410 kernel/locking/rwsem.c:1643, CPU#0: syz.0.53/5774
Modules linked in:
CPU: 0 UID: 0 PID: 5774 Comm: syz.0.53 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:__up_write kernel/locking/rwsem.c:1380 [inline]
RIP: 0010:up_write+0x388/0x410 kernel/locking/rwsem.c:1643
Code: cc 8b 49 c7 c2 c0 eb cc 8b 4c 0f 44 d0 48 8b 7c 24 08 48 c7 c6 20 ee cc 8b 48 8b 14 24 4c 89 f1 4d 89 e0 4c 8b 4c 24 10 41 52 <67> 48 0f b9 3a 48 83 c4 08 e8 ea 60 0a 03 e9 67 fd ff ff 48 c7 c1
RSP: 0000:ffffc90006407d80 EFLAGS: 00010246
RAX: ffffffff8bcceba0 RBX: ffff88804a18c9b8 RCX: ffff88804a18c9b8
RDX: 0000000000000000 RSI: ffffffff8bccee20 RDI: ffffffff9014bf50
RBP: ffff88804a18ca10 R08: 0000000000000000 R09: ffff888000ec2480
R10: ffffffff8bcceba0 R11: ffffed1009431939 R12: 0000000000000000
R13: dffffc0000000000 R14: ffff88804a18c9b8 R15: 1ffff11009431938
FS:  00007f9e11bfe6c0(0000) GS:ffff88808ca62000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000c000d54e20 CR3: 0000000041f2c000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 inode_unlock include/linux/fs.h:1038 [inline]
 end_dirop fs/namei.c:2947 [inline]
 end_creating include/linux/namei.h:126 [inline]
 end_creating_path fs/namei.c:4962 [inline]
 filename_mkdirat+0x305/0x510 fs/namei.c:5271
 __do_sys_mkdirat fs/namei.c:5287 [inline]
 __se_sys_mkdirat+0x35/0x150 fs/namei.c:5284
 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:0x7f9e10d9bf79
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 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:00007f9e11bfe028 EFLAGS: 00000246 ORIG_RAX: 0000000000000102
RAX: ffffffffffffffda RBX: 00007f9e11016090 RCX: 00007f9e10d9bf79
RDX: 00000000000001c0 RSI: 0000200000000140 RDI: ffffffffffffff9c
RBP: 00007f9e10e327e0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f9e11016128 R14: 00007f9e11016090 R15: 00007ffffd54f8b8
 </TASK>
----------------
Code disassembly (best guess), 2 bytes skipped:
   0:	49 c7 c2 c0 eb cc 8b 	mov    $0xffffffff8bccebc0,%r10
   7:	4c 0f 44 d0          	cmove  %rax,%r10
   b:	48 8b 7c 24 08       	mov    0x8(%rsp),%rdi
  10:	48 c7 c6 20 ee cc 8b 	mov    $0xffffffff8bccee20,%rsi
  17:	48 8b 14 24          	mov    (%rsp),%rdx
  1b:	4c 89 f1             	mov    %r14,%rcx
  1e:	4d 89 e0             	mov    %r12,%r8
  21:	4c 8b 4c 24 10       	mov    0x10(%rsp),%r9
  26:	41 52                	push   %r10
* 28:	67 48 0f b9 3a       	ud1    (%edx),%rdi <-- trapping instruction
  2d:	48 83 c4 08          	add    $0x8,%rsp
  31:	e8 ea 60 0a 03       	call   0x30a6120
  36:	e9 67 fd ff ff       	jmp    0xfffffda2
  3b:	48                   	rex.W
  3c:	c7                   	.byte 0xc7
  3d:	c1                   	.byte 0xc1


---
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 syzkaller@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

Re: [syzbot] [gfs2?] WARNING in filename_mkdirat

[Christian Brauner]

On Mon, Feb 16, 2026 at 04:30:27PM -0800, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    0f2acd3148e0 Merge tag 'm68knommu-for-v7.0' of git://git.k..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15331c02580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=ac00553de86d6bf0
> dashboard link: https://syzkaller.appspot.com/bug?extid=0ea5108a1f5fb4fcc2d8
> 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=146b295a580000
> 
> Downloadable assets:
> disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-0f2acd31.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/b7d134e71e9c/vmlinux-0f2acd31.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/b18643058ceb/bzImage-0f2acd31.xz
> mounted in repro: https://storage.googleapis.com/syzbot-assets/bbfed09077d3/mount_1.gz
>   fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=106b295a580000)
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+0ea5108a1f5fb4fcc2d8@syzkaller.appspotmail.com

Neil, is this something you have time to look into?

> 
> ------------[ cut here ]------------
> DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)): count = 0x0, magic = 0xffff88804a18c9b8, owner = 0x0, curr 0xffff888000ec2480, list empty
> WARNING: kernel/locking/rwsem.c:1381 at __up_write kernel/locking/rwsem.c:1380 [inline], CPU#0: syz.0.53/5774
> WARNING: kernel/locking/rwsem.c:1381 at up_write+0x2d6/0x410 kernel/locking/rwsem.c:1643, CPU#0: syz.0.53/5774
> Modules linked in:
> CPU: 0 UID: 0 PID: 5774 Comm: syz.0.53 Not tainted syzkaller #0 PREEMPT(full) 
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> RIP: 0010:__up_write kernel/locking/rwsem.c:1380 [inline]
> RIP: 0010:up_write+0x388/0x410 kernel/locking/rwsem.c:1643
> Code: cc 8b 49 c7 c2 c0 eb cc 8b 4c 0f 44 d0 48 8b 7c 24 08 48 c7 c6 20 ee cc 8b 48 8b 14 24 4c 89 f1 4d 89 e0 4c 8b 4c 24 10 41 52 <67> 48 0f b9 3a 48 83 c4 08 e8 ea 60 0a 03 e9 67 fd ff ff 48 c7 c1
> RSP: 0000:ffffc90006407d80 EFLAGS: 00010246
> RAX: ffffffff8bcceba0 RBX: ffff88804a18c9b8 RCX: ffff88804a18c9b8
> RDX: 0000000000000000 RSI: ffffffff8bccee20 RDI: ffffffff9014bf50
> RBP: ffff88804a18ca10 R08: 0000000000000000 R09: ffff888000ec2480
> R10: ffffffff8bcceba0 R11: ffffed1009431939 R12: 0000000000000000
> R13: dffffc0000000000 R14: ffff88804a18c9b8 R15: 1ffff11009431938
> FS:  00007f9e11bfe6c0(0000) GS:ffff88808ca62000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000000c000d54e20 CR3: 0000000041f2c000 CR4: 0000000000352ef0
> Call Trace:
>  <TASK>
>  inode_unlock include/linux/fs.h:1038 [inline]
>  end_dirop fs/namei.c:2947 [inline]
>  end_creating include/linux/namei.h:126 [inline]
>  end_creating_path fs/namei.c:4962 [inline]
>  filename_mkdirat+0x305/0x510 fs/namei.c:5271
>  __do_sys_mkdirat fs/namei.c:5287 [inline]
>  __se_sys_mkdirat+0x35/0x150 fs/namei.c:5284
>  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:0x7f9e10d9bf79
> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 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:00007f9e11bfe028 EFLAGS: 00000246 ORIG_RAX: 0000000000000102
> RAX: ffffffffffffffda RBX: 00007f9e11016090 RCX: 00007f9e10d9bf79
> RDX: 00000000000001c0 RSI: 0000200000000140 RDI: ffffffffffffff9c
> RBP: 00007f9e10e327e0 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007f9e11016128 R14: 00007f9e11016090 R15: 00007ffffd54f8b8
>  </TASK>
> ----------------
> Code disassembly (best guess), 2 bytes skipped:
>    0:	49 c7 c2 c0 eb cc 8b 	mov    $0xffffffff8bccebc0,%r10
>    7:	4c 0f 44 d0          	cmove  %rax,%r10
>    b:	48 8b 7c 24 08       	mov    0x8(%rsp),%rdi
>   10:	48 c7 c6 20 ee cc 8b 	mov    $0xffffffff8bccee20,%rsi
>   17:	48 8b 14 24          	mov    (%rsp),%rdx
>   1b:	4c 89 f1             	mov    %r14,%rcx
>   1e:	4d 89 e0             	mov    %r12,%r8
>   21:	4c 8b 4c 24 10       	mov    0x10(%rsp),%r9
>   26:	41 52                	push   %r10
> * 28:	67 48 0f b9 3a       	ud1    (%edx),%rdi <-- trapping instruction
>   2d:	48 83 c4 08          	add    $0x8,%rsp
>   31:	e8 ea 60 0a 03       	call   0x30a6120
>   36:	e9 67 fd ff ff       	jmp    0xfffffda2
>   3b:	48                   	rex.W
>   3c:	c7                   	.byte 0xc7
>   3d:	c1                   	.byte 0xc1
> 
> 
> ---
> 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 syzkaller@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

Re: [syzbot] [gfs2?] WARNING in filename_mkdirat

[NeilBrown]

On Tue, 17 Feb 2026, Christian Brauner wrote:
> On Mon, Feb 16, 2026 at 04:30:27PM -0800, syzbot wrote:
> > Hello,
> > 
> > syzbot found the following issue on:
> > 
> > HEAD commit:    0f2acd3148e0 Merge tag 'm68knommu-for-v7.0' of git://git.k..
> > git tree:       upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=15331c02580000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=ac00553de86d6bf0
> > dashboard link: https://syzkaller.appspot.com/bug?extid=0ea5108a1f5fb4fcc2d8
> > 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=146b295a580000
> > 
> > Downloadable assets:
> > disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-0f2acd31.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/b7d134e71e9c/vmlinux-0f2acd31.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/b18643058ceb/bzImage-0f2acd31.xz
> > mounted in repro: https://storage.googleapis.com/syzbot-assets/bbfed09077d3/mount_1.gz
> >   fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=106b295a580000)
> > 
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+0ea5108a1f5fb4fcc2d8@syzkaller.appspotmail.com
> 
> Neil, is this something you have time to look into?

The reproducer appears to mount a gfs2 filesystem and mkdir 3
directories:
  ./file1
  ./file1/file4
  ./file1/file4/file7

and somewhere in there it crashes because vfs_mkdir() returns a
non-error dentry for which ->d_parent->d_inode is not locked and
end_creating_path() tries to up_write().

Presumably either ->d_parent has changed or the inode was unlocked?

gfs2_mkdir() never returns a dentry, so it must be returning NULL.

It's weird - but that is no surprise.

I'll try building a kernel myself and see if the reproducer still fires.
if so some printk tracing my reveal something.

NeilBrown


> 
> > 
> > ------------[ cut here ]------------
> > DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)): count = 0x0, magic = 0xffff88804a18c9b8, owner = 0x0, curr 0xffff888000ec2480, list empty
> > WARNING: kernel/locking/rwsem.c:1381 at __up_write kernel/locking/rwsem.c:1380 [inline], CPU#0: syz.0.53/5774
> > WARNING: kernel/locking/rwsem.c:1381 at up_write+0x2d6/0x410 kernel/locking/rwsem.c:1643, CPU#0: syz.0.53/5774
> > Modules linked in:
> > CPU: 0 UID: 0 PID: 5774 Comm: syz.0.53 Not tainted syzkaller #0 PREEMPT(full) 
> > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> > RIP: 0010:__up_write kernel/locking/rwsem.c:1380 [inline]
> > RIP: 0010:up_write+0x388/0x410 kernel/locking/rwsem.c:1643
> > Code: cc 8b 49 c7 c2 c0 eb cc 8b 4c 0f 44 d0 48 8b 7c 24 08 48 c7 c6 20 ee cc 8b 48 8b 14 24 4c 89 f1 4d 89 e0 4c 8b 4c 24 10 41 52 <67> 48 0f b9 3a 48 83 c4 08 e8 ea 60 0a 03 e9 67 fd ff ff 48 c7 c1
> > RSP: 0000:ffffc90006407d80 EFLAGS: 00010246
> > RAX: ffffffff8bcceba0 RBX: ffff88804a18c9b8 RCX: ffff88804a18c9b8
> > RDX: 0000000000000000 RSI: ffffffff8bccee20 RDI: ffffffff9014bf50
> > RBP: ffff88804a18ca10 R08: 0000000000000000 R09: ffff888000ec2480
> > R10: ffffffff8bcceba0 R11: ffffed1009431939 R12: 0000000000000000
> > R13: dffffc0000000000 R14: ffff88804a18c9b8 R15: 1ffff11009431938
> > FS:  00007f9e11bfe6c0(0000) GS:ffff88808ca62000(0000) knlGS:0000000000000000
> > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 000000c000d54e20 CR3: 0000000041f2c000 CR4: 0000000000352ef0
> > Call Trace:
> >  <TASK>
> >  inode_unlock include/linux/fs.h:1038 [inline]
> >  end_dirop fs/namei.c:2947 [inline]
> >  end_creating include/linux/namei.h:126 [inline]
> >  end_creating_path fs/namei.c:4962 [inline]
> >  filename_mkdirat+0x305/0x510 fs/namei.c:5271
> >  __do_sys_mkdirat fs/namei.c:5287 [inline]
> >  __se_sys_mkdirat+0x35/0x150 fs/namei.c:5284
> >  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:0x7f9e10d9bf79
> > Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 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:00007f9e11bfe028 EFLAGS: 00000246 ORIG_RAX: 0000000000000102
> > RAX: ffffffffffffffda RBX: 00007f9e11016090 RCX: 00007f9e10d9bf79
> > RDX: 00000000000001c0 RSI: 0000200000000140 RDI: ffffffffffffff9c
> > RBP: 00007f9e10e327e0 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> > R13: 00007f9e11016128 R14: 00007f9e11016090 R15: 00007ffffd54f8b8
> >  </TASK>
> > ----------------
> > Code disassembly (best guess), 2 bytes skipped:
> >    0:	49 c7 c2 c0 eb cc 8b 	mov    $0xffffffff8bccebc0,%r10
> >    7:	4c 0f 44 d0          	cmove  %rax,%r10
> >    b:	48 8b 7c 24 08       	mov    0x8(%rsp),%rdi
> >   10:	48 c7 c6 20 ee cc 8b 	mov    $0xffffffff8bccee20,%rsi
> >   17:	48 8b 14 24          	mov    (%rsp),%rdx
> >   1b:	4c 89 f1             	mov    %r14,%rcx
> >   1e:	4d 89 e0             	mov    %r12,%r8
> >   21:	4c 8b 4c 24 10       	mov    0x10(%rsp),%r9
> >   26:	41 52                	push   %r10
> > * 28:	67 48 0f b9 3a       	ud1    (%edx),%rdi <-- trapping instruction
> >   2d:	48 83 c4 08          	add    $0x8,%rsp
> >   31:	e8 ea 60 0a 03       	call   0x30a6120
> >   36:	e9 67 fd ff ff       	jmp    0xfffffda2
> >   3b:	48                   	rex.W
> >   3c:	c7                   	.byte 0xc7
> >   3d:	c1                   	.byte 0xc1
> > 
> > 
> > ---
> > 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 syzkaller@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
> 

Re: [syzbot] [gfs2?] WARNING in filename_mkdirat

[NeilBrown]

On Tue, 17 Feb 2026, NeilBrown wrote:
> On Tue, 17 Feb 2026, Christian Brauner wrote:
> > On Mon, Feb 16, 2026 at 04:30:27PM -0800, syzbot wrote:
> > > Hello,
> > > 
> > > syzbot found the following issue on:
> > > 
> > > HEAD commit:    0f2acd3148e0 Merge tag 'm68knommu-for-v7.0' of git://git.k..
> > > git tree:       upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=15331c02580000
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=ac00553de86d6bf0
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=0ea5108a1f5fb4fcc2d8
> > > 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=146b295a580000
> > > 
> > > Downloadable assets:
> > > disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-0f2acd31.raw.xz
> > > vmlinux: https://storage.googleapis.com/syzbot-assets/b7d134e71e9c/vmlinux-0f2acd31.xz
> > > kernel image: https://storage.googleapis.com/syzbot-assets/b18643058ceb/bzImage-0f2acd31.xz
> > > mounted in repro: https://storage.googleapis.com/syzbot-assets/bbfed09077d3/mount_1.gz
> > >   fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=106b295a580000)
> > > 
> > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > Reported-by: syzbot+0ea5108a1f5fb4fcc2d8@syzkaller.appspotmail.com
> > 
> > Neil, is this something you have time to look into?
> 
> The reproducer appears to mount a gfs2 filesystem and mkdir 3
> directories:
>   ./file1
>   ./file1/file4
>   ./file1/file4/file7
> 
> and somewhere in there it crashes because vfs_mkdir() returns a
> non-error dentry for which ->d_parent->d_inode is not locked and
> end_creating_path() tries to up_write().
> 
> Presumably either ->d_parent has changed or the inode was unlocked?
> 
> gfs2_mkdir() never returns a dentry, so it must be returning NULL.
> 
> It's weird - but that is no surprise.
> 
> I'll try building a kernel myself and see if the reproducer still fires.
> if so some printk tracing my reveal something.

Unfortunately that didn't work out.
Using the provided vmlinux and root image and repro, and a syzkaller I
compiled from current git, I cannot trigger the crash.

I'll have another look at the code but I don't hold out a lot of hope.

NeilBrown

Re: [syzbot] [gfs2?] WARNING in filename_mkdirat

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit:    956b9cbd7f15 Merge tag 'kbuild-fixes-7.0-1' of git://git.k..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14c81ffa580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=65722f41f7edc17e
dashboard link: https://syzkaller.appspot.com/bug?extid=0ea5108a1f5fb4fcc2d8
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=1622495a580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1600e95a580000

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-956b9cbd.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/f0b3757a15ed/vmlinux-956b9cbd.xz
kernel image: https://storage.googleapis.com/syzbot-assets/c564e8613b4e/bzImage-956b9cbd.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/2e0152c5e6ec/mount_1.gz
  fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=141eb15a580000)

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

------------[ cut here ]------------
DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)): count = 0x0, magic = 0xffff88804665f818, owner = 0x0, curr 0xffff888035922480, list empty
WARNING: kernel/locking/rwsem.c:1381 at __up_write kernel/locking/rwsem.c:1380 [inline], CPU#0: syz.0.30/5574
WARNING: kernel/locking/rwsem.c:1381 at up_write+0x2d6/0x410 kernel/locking/rwsem.c:1643, CPU#0: syz.0.30/5574
Modules linked in:
CPU: 0 UID: 0 PID: 5574 Comm: syz.0.30 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:__up_write kernel/locking/rwsem.c:1380 [inline]
RIP: 0010:up_write+0x388/0x410 kernel/locking/rwsem.c:1643
Code: cc 8b 49 c7 c2 80 eb cc 8b 4c 0f 44 d0 48 8b 7c 24 08 48 c7 c6 e0 ed cc 8b 48 8b 14 24 4c 89 f1 4d 89 e0 4c 8b 4c 24 10 41 52 <67> 48 0f b9 3a 48 83 c4 08 e8 0a 0c 0b 03 e9 67 fd ff ff 48 c7 c1
RSP: 0018:ffffc90006407d80 EFLAGS: 00010246
RAX: ffffffff8bcceb60 RBX: ffff88804665f818 RCX: ffff88804665f818
RDX: 0000000000000000 RSI: ffffffff8bccede0 RDI: ffffffff9014e210
RBP: ffff88804665f870 R08: 0000000000000000 R09: ffff888035922480
R10: ffffffff8bcceb60 R11: ffffed1008ccbf05 R12: 0000000000000000
R13: dffffc0000000000 R14: ffff88804665f818 R15: 1ffff11008ccbf04
FS:  00007fe0f01196c0(0000) GS:ffff88808ca5b000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe0f0118ff8 CR3: 000000004158f000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 inode_unlock include/linux/fs.h:1038 [inline]
 end_dirop fs/namei.c:2947 [inline]
 end_creating include/linux/namei.h:126 [inline]
 end_creating_path fs/namei.c:4962 [inline]
 filename_mkdirat+0x305/0x510 fs/namei.c:5271
 __do_sys_mkdir fs/namei.c:5293 [inline]
 __se_sys_mkdir+0x34/0x150 fs/namei.c:5290
 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:0x7fe0ef19c629
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 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:00007fe0f0119028 EFLAGS: 00000246 ORIG_RAX: 0000000000000053
RAX: ffffffffffffffda RBX: 00007fe0ef416090 RCX: 00007fe0ef19c629
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000200000000040
RBP: 00007fe0ef232b39 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fe0ef416128 R14: 00007fe0ef416090 R15: 00007ffff03e4318
 </TASK>
----------------
Code disassembly (best guess), 2 bytes skipped:
   0:	49 c7 c2 80 eb cc 8b 	mov    $0xffffffff8bcceb80,%r10
   7:	4c 0f 44 d0          	cmove  %rax,%r10
   b:	48 8b 7c 24 08       	mov    0x8(%rsp),%rdi
  10:	48 c7 c6 e0 ed cc 8b 	mov    $0xffffffff8bccede0,%rsi
  17:	48 8b 14 24          	mov    (%rsp),%rdx
  1b:	4c 89 f1             	mov    %r14,%rcx
  1e:	4d 89 e0             	mov    %r12,%r8
  21:	4c 8b 4c 24 10       	mov    0x10(%rsp),%r9
  26:	41 52                	push   %r10
* 28:	67 48 0f b9 3a       	ud1    (%edx),%rdi <-- trapping instruction
  2d:	48 83 c4 08          	add    $0x8,%rsp
  31:	e8 0a 0c 0b 03       	call   0x30b0c40
  36:	e9 67 fd ff ff       	jmp    0xfffffda2
  3b:	48                   	rex.W
  3c:	c7                   	.byte 0xc7
  3d:	c1                   	.byte 0xc1


---
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.

Re: [syzbot] [gfs2?] WARNING in filename_mkdirat

[Christian Brauner]

On Wed, Feb 18, 2026 at 09:18:53AM +1100, NeilBrown wrote:
> On Tue, 17 Feb 2026, NeilBrown wrote:
> > On Tue, 17 Feb 2026, Christian Brauner wrote:
> > > On Mon, Feb 16, 2026 at 04:30:27PM -0800, syzbot wrote:
> > > > Hello,
> > > > 
> > > > syzbot found the following issue on:
> > > > 
> > > > HEAD commit:    0f2acd3148e0 Merge tag 'm68knommu-for-v7.0' of git://git.k..
> > > > git tree:       upstream
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=15331c02580000
> > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=ac00553de86d6bf0
> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=0ea5108a1f5fb4fcc2d8
> > > > 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=146b295a580000
> > > > 
> > > > Downloadable assets:
> > > > disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-0f2acd31.raw.xz
> > > > vmlinux: https://storage.googleapis.com/syzbot-assets/b7d134e71e9c/vmlinux-0f2acd31.xz
> > > > kernel image: https://storage.googleapis.com/syzbot-assets/b18643058ceb/bzImage-0f2acd31.xz
> > > > mounted in repro: https://storage.googleapis.com/syzbot-assets/bbfed09077d3/mount_1.gz
> > > >   fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=106b295a580000)
> > > > 
> > > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > > Reported-by: syzbot+0ea5108a1f5fb4fcc2d8@syzkaller.appspotmail.com
> > > 
> > > Neil, is this something you have time to look into?
> > 
> > The reproducer appears to mount a gfs2 filesystem and mkdir 3
> > directories:
> >   ./file1
> >   ./file1/file4
> >   ./file1/file4/file7
> > 
> > and somewhere in there it crashes because vfs_mkdir() returns a
> > non-error dentry for which ->d_parent->d_inode is not locked and
> > end_creating_path() tries to up_write().
> > 
> > Presumably either ->d_parent has changed or the inode was unlocked?
> > 
> > gfs2_mkdir() never returns a dentry, so it must be returning NULL.
> > 
> > It's weird - but that is no surprise.
> > 
> > I'll try building a kernel myself and see if the reproducer still fires.
> > if so some printk tracing my reveal something.
> 
> Unfortunately that didn't work out.
> Using the provided vmlinux and root image and repro, and a syzkaller I
> compiled from current git, I cannot trigger the crash.
> 
> I'll have another look at the code but I don't hold out a lot of hope.

There's at least a proper C repro now.

Re: [syzbot] [gfs2?] WARNING in filename_mkdirat

[NeilBrown]

[gfs2 maintainer an list added  - Hi Andreas!]

On Thu, 19 Feb 2026, Christian Brauner wrote:
> On Wed, Feb 18, 2026 at 09:18:53AM +1100, NeilBrown wrote:
> > On Tue, 17 Feb 2026, NeilBrown wrote:
> > > On Tue, 17 Feb 2026, Christian Brauner wrote:
> > > > On Mon, Feb 16, 2026 at 04:30:27PM -0800, syzbot wrote:
> > > > > Hello,
> > > > > 
> > > > > syzbot found the following issue on:
> > > > > 
> > > > > HEAD commit:    0f2acd3148e0 Merge tag 'm68knommu-for-v7.0' of git://git.k..
> > > > > git tree:       upstream
> > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=15331c02580000
> > > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=ac00553de86d6bf0
> > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=0ea5108a1f5fb4fcc2d8
> > > > > 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=146b295a580000
> > > > > 
> > > > > Downloadable assets:
> > > > > disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-0f2acd31.raw.xz
> > > > > vmlinux: https://storage.googleapis.com/syzbot-assets/b7d134e71e9c/vmlinux-0f2acd31.xz
> > > > > kernel image: https://storage.googleapis.com/syzbot-assets/b18643058ceb/bzImage-0f2acd31.xz
> > > > > mounted in repro: https://storage.googleapis.com/syzbot-assets/bbfed09077d3/mount_1.gz
> > > > >   fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=106b295a580000)
> > > > > 
> > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > > > Reported-by: syzbot+0ea5108a1f5fb4fcc2d8@syzkaller.appspotmail.com
> > > > 
> > > > Neil, is this something you have time to look into?
> > > 
> > > The reproducer appears to mount a gfs2 filesystem and mkdir 3
> > > directories:
> > >   ./file1
> > >   ./file1/file4
> > >   ./file1/file4/file7
> > > 
> > > and somewhere in there it crashes because vfs_mkdir() returns a
> > > non-error dentry for which ->d_parent->d_inode is not locked and
> > > end_creating_path() tries to up_write().
> > > 
> > > Presumably either ->d_parent has changed or the inode was unlocked?
> > > 
> > > gfs2_mkdir() never returns a dentry, so it must be returning NULL.
> > > 
> > > It's weird - but that is no surprise.
> > > 
> > > I'll try building a kernel myself and see if the reproducer still fires.
> > > if so some printk tracing my reveal something.
> > 
> > Unfortunately that didn't work out.
> > Using the provided vmlinux and root image and repro, and a syzkaller I
> > compiled from current git, I cannot trigger the crash.
> > 
> > I'll have another look at the code but I don't hold out a lot of hope.
> 
> There's at least a proper C repro now.
> 

Yes - and with the new C repro I can trigger the bug.

The problem is in gfs2.  gfs2_create_inode() calls d_instantiate()
before unlock_new_inode().  This is bad.  d_instantiate_new() should be
used, which makes sure the two things happen in the correct order.

Key to understanding the problem is knowing that unlock_new_inode()
calls lockdep_annotate_inode_mutex_key() which (potentially) calls 
  init_rwsem(&inode->i_rwsem);

So if anyone has locked the inode before unlock_new_inode() is called,
the lock is lost when i_rwsem is reinitialised.

The reproducer calls mkdir("a") and mkdir("a/b") concurrently from
separate threads.  The second mkdir() often fails (I assume) because "a"
cannot be found.  But if that second mkdir() runs just after gfs2 has
called d_instantiate(), then the lookup of "a" will succeed and so the
inode will be locked ready for mkdir..  Then the mkdir("a") completes
calling unlock_new_inode() which reinitialised i_rwsem.  When
mkdir("a/b") comes to lock the parent, it finds that it isn't locked any
more.

There is non-trivial code between the d_instantiate() call and the
unlock_new_inode() call which I do not understand.  So I will not
propose a patch.  I don't know if that code should be after
d_instantiate_new(), or before it.

So I'll leave that to Andreas.

Thanks,
NeilBrown

Re: [syzbot] [gfs2?] WARNING in filename_mkdirat

[Andreas Gruenbacher]

On Thu, Feb 19, 2026 at 10:45 PM NeilBrown <neilb@ownmail.net> wrote:
> On Thu, 19 Feb 2026, Christian Brauner wrote:
> > On Wed, Feb 18, 2026 at 09:18:53AM +1100, NeilBrown wrote:
> > > On Tue, 17 Feb 2026, NeilBrown wrote:
> > > > On Tue, 17 Feb 2026, Christian Brauner wrote:
> > > > > On Mon, Feb 16, 2026 at 04:30:27PM -0800, syzbot wrote:
> > > > > > Hello,
> > > > > >
> > > > > > syzbot found the following issue on:
> > > > > >
> > > > > > HEAD commit:    0f2acd3148e0 Merge tag 'm68knommu-for-v7.0' of git://git.k..
> > > > > > git tree:       upstream
> > > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=15331c02580000
> > > > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=ac00553de86d6bf0
> > > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=0ea5108a1f5fb4fcc2d8
> > > > > > 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=146b295a580000
> > > > > >
> > > > > > Downloadable assets:
> > > > > > disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-0f2acd31.raw.xz
> > > > > > vmlinux: https://storage.googleapis.com/syzbot-assets/b7d134e71e9c/vmlinux-0f2acd31.xz
> > > > > > kernel image: https://storage.googleapis.com/syzbot-assets/b18643058ceb/bzImage-0f2acd31.xz
> > > > > > mounted in repro: https://storage.googleapis.com/syzbot-assets/bbfed09077d3/mount_1.gz
> > > > > >   fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=106b295a580000)
> > > > > >
> > > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > > > > Reported-by: syzbot+0ea5108a1f5fb4fcc2d8@syzkaller.appspotmail.com
> > > > >
> > > > > Neil, is this something you have time to look into?
> > > >
> > > > The reproducer appears to mount a gfs2 filesystem and mkdir 3
> > > > directories:
> > > >   ./file1
> > > >   ./file1/file4
> > > >   ./file1/file4/file7
> > > >
> > > > and somewhere in there it crashes because vfs_mkdir() returns a
> > > > non-error dentry for which ->d_parent->d_inode is not locked and
> > > > end_creating_path() tries to up_write().
> > > >
> > > > Presumably either ->d_parent has changed or the inode was unlocked?
> > > >
> > > > gfs2_mkdir() never returns a dentry, so it must be returning NULL.
> > > >
> > > > It's weird - but that is no surprise.
> > > >
> > > > I'll try building a kernel myself and see if the reproducer still fires.
> > > > if so some printk tracing my reveal something.
> > >
> > > Unfortunately that didn't work out.
> > > Using the provided vmlinux and root image and repro, and a syzkaller I
> > > compiled from current git, I cannot trigger the crash.
> > >
> > > I'll have another look at the code but I don't hold out a lot of hope.
> >
> > There's at least a proper C repro now.
> >
>
> Yes - and with the new C repro I can trigger the bug.
>
> The problem is in gfs2.  gfs2_create_inode() calls d_instantiate()
> before unlock_new_inode().  This is bad.  d_instantiate_new() should be
> used, which makes sure the two things happen in the correct order.
>
> Key to understanding the problem is knowing that unlock_new_inode()
> calls lockdep_annotate_inode_mutex_key() which (potentially) calls
>   init_rwsem(&inode->i_rwsem);
>
> So if anyone has locked the inode before unlock_new_inode() is called,
> the lock is lost when i_rwsem is reinitialised.
>
> The reproducer calls mkdir("a") and mkdir("a/b") concurrently from
> separate threads.  The second mkdir() often fails (I assume) because "a"
> cannot be found.  But if that second mkdir() runs just after gfs2 has
> called d_instantiate(), then the lookup of "a" will succeed and so the
> inode will be locked ready for mkdir..  Then the mkdir("a") completes
> calling unlock_new_inode() which reinitialised i_rwsem.  When
> mkdir("a/b") comes to lock the parent, it finds that it isn't locked any
> more.
>
> There is non-trivial code between the d_instantiate() call and the
> unlock_new_inode() call which I do not understand.  So I will not
> propose a patch.  I don't know if that code should be after
> d_instantiate_new(), or before it.
>
> So I'll leave that to Andreas.

Thanks a lot, Neil, I've added a fix to for-next.

Andreas