[syzbot] [overlayfs?] WARNING in shmem_unlink

[syzbot] [overlayfs?] WARNING in shmem_unlink

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    0cc53520e68b Merge tag 'probes-fixes-v6.17-rc1' of git://g..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14a003a2580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=13f39c6a0380a209
dashboard link: https://syzkaller.appspot.com/bug?extid=ec9fab8b7f0386b98a17
compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1387bc34580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/1f4865acb167/disk-0cc53520.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/14540c5ef981/vmlinux-0cc53520.xz
kernel image: https://storage.googleapis.com/syzbot-assets/35534bfe1c7e/bzImage-0cc53520.xz

Bisection is inconclusive: the first bad commit could be any of:

241062ae5d87 ovl: change ovl_workdir_cleanup() to take dir lock as needed.
a45ee87ded78 ovl: narrow locking in ovl_workdir_cleanup_recurse()
c69566b1d11d ovl: narrow locking on ovl_remove_and_whiteout()

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=130d1dbc580000

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

------------[ cut here ]------------
WARNING: CPU: 1 PID: 9026 at fs/inode.c:417 drop_nlink+0xc5/0x110 fs/inode.c:417
Modules linked in:
CPU: 1 UID: 0 PID: 9026 Comm: syz.4.1430 Tainted: G        W           6.17.0-rc1-syzkaller-00038-g0cc53520e68b #0 PREEMPT_{RT,(full)} 
Tainted: [W]=WARN
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025
RIP: 0010:drop_nlink+0xc5/0x110 fs/inode.c:417
Code: c8 08 00 00 be 08 00 00 00 e8 b7 90 ec ff f0 48 ff 83 c8 08 00 00 5b 41 5c 41 5e 41 5f 5d e9 82 9f c8 08 cc e8 dc 5a 8d ff 90 <0f> 0b 90 eb 81 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 5b ff ff ff
RSP: 0018:ffffc9000f5ef600 EFLAGS: 00010293
RAX: ffffffff82310064 RBX: ffff88803352c420 RCX: ffff88802cfcbb80
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: dffffc0000000000 R11: fffff52001ebdeb5 R12: 1ffff110066a588d
R13: 00000000689e7afa R14: ffff88803352c468 R15: dffffc0000000000
FS:  00007fec6bd366c0(0000) GS:ffff8881269c5000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000555591d73608 CR3: 00000000274f4000 CR4: 00000000003526f0
Call Trace:
 <TASK>
 shmem_unlink+0x1f5/0x2d0 mm/shmem.c:4041
 vfs_unlink+0x39a/0x660 fs/namei.c:4586
 ovl_do_unlink fs/overlayfs/overlayfs.h:218 [inline]
 ovl_cleanup_locked fs/overlayfs/dir.c:36 [inline]
 ovl_cleanup+0x151/0x230 fs/overlayfs/dir.c:56
 ovl_check_rename_whiteout fs/overlayfs/super.c:607 [inline]
 ovl_make_workdir fs/overlayfs/super.c:704 [inline]
 ovl_get_workdir+0xabd/0x17c0 fs/overlayfs/super.c:827
 ovl_fill_super+0x1365/0x35b0 fs/overlayfs/super.c:1406
 vfs_get_super fs/super.c:1325 [inline]
 get_tree_nodev+0xbb/0x150 fs/super.c:1344
 vfs_get_tree+0x8f/0x2b0 fs/super.c:1815
 do_new_mount+0x2a2/0x9e0 fs/namespace.c:3805
 do_mount fs/namespace.c:4133 [inline]
 __do_sys_mount fs/namespace.c:4344 [inline]
 __se_sys_mount+0x317/0x410 fs/namespace.c:4321
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fec6c6cebe9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fec6bd36038 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007fec6c8f5fa0 RCX: 00007fec6c6cebe9
RDX: 0000200000000200 RSI: 0000200000000000 RDI: 0000000000000000
RBP: 00007fec6c751e19 R08: 0000200000000140 R09: 0000000000000000
R10: 00000000000000d4 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fec6c8f6038 R14: 00007fec6c8f5fa0 R15: 00007ffc15eea8d8
 </TASK>


---
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.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection

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] [overlayfs?] WARNING in shmem_unlink

[Amir Goldstein]

Neil,

I will have a look tomorrow.
If you have ideas I am open to hear them.
The repro is mounting overlayfs all over each other in concurrent threads
and one of the rmdir of "work" dir triggers this assertion

Thanks,
Amir.

On Sat, Aug 16, 2025 at 5:08 AM syzbot
<syzbot+ec9fab8b7f0386b98a17@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:    0cc53520e68b Merge tag 'probes-fixes-v6.17-rc1' of git://g..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=14a003a2580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=13f39c6a0380a209
> dashboard link: https://syzkaller.appspot.com/bug?extid=ec9fab8b7f0386b98a17
> compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1387bc34580000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/1f4865acb167/disk-0cc53520.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/14540c5ef981/vmlinux-0cc53520.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/35534bfe1c7e/bzImage-0cc53520.xz
>
> Bisection is inconclusive: the first bad commit could be any of:
>
> 241062ae5d87 ovl: change ovl_workdir_cleanup() to take dir lock as needed.
> a45ee87ded78 ovl: narrow locking in ovl_workdir_cleanup_recurse()
> c69566b1d11d ovl: narrow locking on ovl_remove_and_whiteout()
>
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=130d1dbc580000
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+ec9fab8b7f0386b98a17@syzkaller.appspotmail.com
>
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 9026 at fs/inode.c:417 drop_nlink+0xc5/0x110 fs/inode.c:417
> Modules linked in:
> CPU: 1 UID: 0 PID: 9026 Comm: syz.4.1430 Tainted: G        W           6.17.0-rc1-syzkaller-00038-g0cc53520e68b #0 PREEMPT_{RT,(full)}
> Tainted: [W]=WARN
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025
> RIP: 0010:drop_nlink+0xc5/0x110 fs/inode.c:417
> Code: c8 08 00 00 be 08 00 00 00 e8 b7 90 ec ff f0 48 ff 83 c8 08 00 00 5b 41 5c 41 5e 41 5f 5d e9 82 9f c8 08 cc e8 dc 5a 8d ff 90 <0f> 0b 90 eb 81 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 5b ff ff ff
> RSP: 0018:ffffc9000f5ef600 EFLAGS: 00010293
> RAX: ffffffff82310064 RBX: ffff88803352c420 RCX: ffff88802cfcbb80
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> R10: dffffc0000000000 R11: fffff52001ebdeb5 R12: 1ffff110066a588d
> R13: 00000000689e7afa R14: ffff88803352c468 R15: dffffc0000000000
> FS:  00007fec6bd366c0(0000) GS:ffff8881269c5000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000555591d73608 CR3: 00000000274f4000 CR4: 00000000003526f0
> Call Trace:
>  <TASK>
>  shmem_unlink+0x1f5/0x2d0 mm/shmem.c:4041
>  vfs_unlink+0x39a/0x660 fs/namei.c:4586
>  ovl_do_unlink fs/overlayfs/overlayfs.h:218 [inline]
>  ovl_cleanup_locked fs/overlayfs/dir.c:36 [inline]
>  ovl_cleanup+0x151/0x230 fs/overlayfs/dir.c:56
>  ovl_check_rename_whiteout fs/overlayfs/super.c:607 [inline]
>  ovl_make_workdir fs/overlayfs/super.c:704 [inline]
>  ovl_get_workdir+0xabd/0x17c0 fs/overlayfs/super.c:827
>  ovl_fill_super+0x1365/0x35b0 fs/overlayfs/super.c:1406
>  vfs_get_super fs/super.c:1325 [inline]
>  get_tree_nodev+0xbb/0x150 fs/super.c:1344
>  vfs_get_tree+0x8f/0x2b0 fs/super.c:1815
>  do_new_mount+0x2a2/0x9e0 fs/namespace.c:3805
>  do_mount fs/namespace.c:4133 [inline]
>  __do_sys_mount fs/namespace.c:4344 [inline]
>  __se_sys_mount+0x317/0x410 fs/namespace.c:4321
>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>  do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7fec6c6cebe9
> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007fec6bd36038 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
> RAX: ffffffffffffffda RBX: 00007fec6c8f5fa0 RCX: 00007fec6c6cebe9
> RDX: 0000200000000200 RSI: 0000200000000000 RDI: 0000000000000000
> RBP: 00007fec6c751e19 R08: 0000200000000140 R09: 0000000000000000
> R10: 00000000000000d4 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007fec6c8f6038 R14: 00007fec6c8f5fa0 R15: 00007ffc15eea8d8
>  </TASK>
>
>
> ---
> 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.
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>
> 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] [overlayfs?] WARNING in shmem_unlink

[NeilBrown]

On Mon, 18 Aug 2025, Amir Goldstein wrote:
> Neil,
> 
> I will have a look tomorrow.
> If you have ideas I am open to hear them.
> The repro is mounting overlayfs all over each other in concurrent threads
> and one of the rmdir of "work" dir triggers this assertion

My guess is that by dropping and retaking the lock, we open the
possibility of a race so that by the time vfs_unlink() is called the
dentry has already been unlinked.  In that case it would be unhashed.
So after retaking the lock we need to check d_unhashed() as well as
->d_parent.

So something like
--- a/fs/overlayfs/util.c
+++ b/fs/overlayfs/util.c
@@ -1552,7 +1552,8 @@ void ovl_copyattr(struct inode *inode)
 int ovl_parent_lock(struct dentry *parent, struct dentry *child)
 {
 	inode_lock_nested(parent->d_inode, I_MUTEX_PARENT);
-	if (!child || child->d_parent == parent)
+	if (!child ||
+	    (!d_unhashed(child) && child->d_parent == parent))
 		return 0;
 
 	inode_unlock(parent->d_inode);


NeilBrown


> 
> Thanks,
> Amir.
> 
> On Sat, Aug 16, 2025 at 5:08 AM syzbot
> <syzbot+ec9fab8b7f0386b98a17@syzkaller.appspotmail.com> wrote:
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:    0cc53520e68b Merge tag 'probes-fixes-v6.17-rc1' of git://g..
> > git tree:       upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=14a003a2580000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=13f39c6a0380a209
> > dashboard link: https://syzkaller.appspot.com/bug?extid=ec9fab8b7f0386b98a17
> > compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1387bc34580000
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/1f4865acb167/disk-0cc53520.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/14540c5ef981/vmlinux-0cc53520.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/35534bfe1c7e/bzImage-0cc53520.xz
> >
> > Bisection is inconclusive: the first bad commit could be any of:
> >
> > 241062ae5d87 ovl: change ovl_workdir_cleanup() to take dir lock as needed.
> > a45ee87ded78 ovl: narrow locking in ovl_workdir_cleanup_recurse()
> > c69566b1d11d ovl: narrow locking on ovl_remove_and_whiteout()
> >
> > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=130d1dbc580000
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+ec9fab8b7f0386b98a17@syzkaller.appspotmail.com
> >
> > ------------[ cut here ]------------
> > WARNING: CPU: 1 PID: 9026 at fs/inode.c:417 drop_nlink+0xc5/0x110 fs/inode.c:417
> > Modules linked in:
> > CPU: 1 UID: 0 PID: 9026 Comm: syz.4.1430 Tainted: G        W           6.17.0-rc1-syzkaller-00038-g0cc53520e68b #0 PREEMPT_{RT,(full)}
> > Tainted: [W]=WARN
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025
> > RIP: 0010:drop_nlink+0xc5/0x110 fs/inode.c:417
> > Code: c8 08 00 00 be 08 00 00 00 e8 b7 90 ec ff f0 48 ff 83 c8 08 00 00 5b 41 5c 41 5e 41 5f 5d e9 82 9f c8 08 cc e8 dc 5a 8d ff 90 <0f> 0b 90 eb 81 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 5b ff ff ff
> > RSP: 0018:ffffc9000f5ef600 EFLAGS: 00010293
> > RAX: ffffffff82310064 RBX: ffff88803352c420 RCX: ffff88802cfcbb80
> > RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> > RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> > R10: dffffc0000000000 R11: fffff52001ebdeb5 R12: 1ffff110066a588d
> > R13: 00000000689e7afa R14: ffff88803352c468 R15: dffffc0000000000
> > FS:  00007fec6bd366c0(0000) GS:ffff8881269c5000(0000) knlGS:0000000000000000
> > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 0000555591d73608 CR3: 00000000274f4000 CR4: 00000000003526f0
> > Call Trace:
> >  <TASK>
> >  shmem_unlink+0x1f5/0x2d0 mm/shmem.c:4041
> >  vfs_unlink+0x39a/0x660 fs/namei.c:4586
> >  ovl_do_unlink fs/overlayfs/overlayfs.h:218 [inline]
> >  ovl_cleanup_locked fs/overlayfs/dir.c:36 [inline]
> >  ovl_cleanup+0x151/0x230 fs/overlayfs/dir.c:56
> >  ovl_check_rename_whiteout fs/overlayfs/super.c:607 [inline]
> >  ovl_make_workdir fs/overlayfs/super.c:704 [inline]
> >  ovl_get_workdir+0xabd/0x17c0 fs/overlayfs/super.c:827
> >  ovl_fill_super+0x1365/0x35b0 fs/overlayfs/super.c:1406
> >  vfs_get_super fs/super.c:1325 [inline]
> >  get_tree_nodev+0xbb/0x150 fs/super.c:1344
> >  vfs_get_tree+0x8f/0x2b0 fs/super.c:1815
> >  do_new_mount+0x2a2/0x9e0 fs/namespace.c:3805
> >  do_mount fs/namespace.c:4133 [inline]
> >  __do_sys_mount fs/namespace.c:4344 [inline]
> >  __se_sys_mount+0x317/0x410 fs/namespace.c:4321
> >  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> >  do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
> >  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> > RIP: 0033:0x7fec6c6cebe9
> > Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48
> > RSP: 002b:00007fec6bd36038 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
> > RAX: ffffffffffffffda RBX: 00007fec6c8f5fa0 RCX: 00007fec6c6cebe9
> > RDX: 0000200000000200 RSI: 0000200000000000 RDI: 0000000000000000
> > RBP: 00007fec6c751e19 R08: 0000200000000140 R09: 0000000000000000
> > R10: 00000000000000d4 R11: 0000000000000246 R12: 0000000000000000
> > R13: 00007fec6c8f6038 R14: 00007fec6c8f5fa0 R15: 00007ffc15eea8d8
> >  </TASK>
> >
> >
> > ---
> > 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.
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> >
> > 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] [overlayfs?] WARNING in shmem_unlink

[Hillf Danton]

On Mon, 18 Aug 2025 10:33:52 +1000 NeilBrown wrote:
> On Mon, 18 Aug 2025, Amir Goldstein wrote:
> > Neil,
> >
> > I will have a look tomorrow.
> > If you have ideas I am open to hear them.
> > The repro is mounting overlayfs all over each other in concurrent threads
> > and one of the rmdir of "work" dir triggers this assertion
> 
> My guess is that by dropping and retaking the lock, we open the
> possibility of a race so that by the time vfs_unlink() is called the
> dentry has already been unlinked.  In that case it would be unhashed.
> So after retaking the lock we need to check d_unhashed() as well as
> ->d_parent.
> 
> So something like

#syz test upstream master

--- a/fs/overlayfs/util.c
+++ b/fs/overlayfs/util.c
@@ -1552,7 +1552,8 @@ void ovl_copyattr(struct inode *inode)
 int ovl_parent_lock(struct dentry *parent, struct dentry *child)
 {
 	inode_lock_nested(parent->d_inode, I_MUTEX_PARENT);
-	if (!child || child->d_parent == parent)
+	if (!child ||
+	    (!d_unhashed(child) && child->d_parent == parent))
 		return 0;
 
 	inode_unlock(parent->d_inode);
--

Re: [syzbot] [overlayfs?] WARNING in shmem_unlink

[syzbot]

Hello,

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

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

Tested on:

commit:         c17b750b Linux 6.17-rc2
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15e1eba2580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=e9f694461848a008
dashboard link: https://syzkaller.appspot.com/bug?extid=ec9fab8b7f0386b98a17
compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
patch:          https://syzkaller.appspot.com/x/patch.diff?x=1413a442580000

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

Re: [syzbot] [overlayfs?] WARNING in shmem_unlink

[Amir Goldstein]

On Mon, Aug 18, 2025 at 2:34 AM NeilBrown <neil@brown.name> wrote:
>
> On Mon, 18 Aug 2025, Amir Goldstein wrote:
> > Neil,
> >
> > I will have a look tomorrow.
> > If you have ideas I am open to hear them.
> > The repro is mounting overlayfs all over each other in concurrent threads
> > and one of the rmdir of "work" dir triggers this assertion
>
> My guess is that by dropping and retaking the lock, we open the
> possibility of a race so that by the time vfs_unlink() is called the
> dentry has already been unlinked.  In that case it would be unhashed.
> So after retaking the lock we need to check d_unhashed() as well as
> ->d_parent.
>
> So something like
> --- a/fs/overlayfs/util.c
> +++ b/fs/overlayfs/util.c
> @@ -1552,7 +1552,8 @@ void ovl_copyattr(struct inode *inode)
>  int ovl_parent_lock(struct dentry *parent, struct dentry *child)
>  {
>         inode_lock_nested(parent->d_inode, I_MUTEX_PARENT);
> -       if (!child || child->d_parent == parent)
> +       if (!child ||
> +           (!d_unhashed(child) && child->d_parent == parent))
>                 return 0;
>
>         inode_unlock(parent->d_inode);
>
>
> NeilBrown
>

Nice!
I pushed this commit to ovl-fixes:

commit c56976d86e11afcd6b23633395a7f2e6e920e42d (HEAD -> ovl-fixes)
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Mon Aug 18 11:23:55 2025 +0200

    ovl: fix possible double unlink

    commit 9d23967b18c6 ("ovl: simplify an error path in
    ovl_copy_up_workdir()") introduced the helper ovl_cleanup_unlocked(),
    which is later used in several following patches to re-acquire the parent
    inode lock and unlink a dentry that was earlier found using lookup.
    This helper was eventually renamed to ovl_cleanup().

    The helper ovl_parent_lock() is used to re-acquire the parent inode lock.
    After acquiring the parent inode lock, the helper verifies that the
    dentry has not since been moved to another parent, but it failed to
    verify that the dentry wasn't unlinked from the parent.

    This means that now every call to ovl_cleanup() could potentially
    race with another thread, unlinking the dentry to be cleaned up
    underneath overlayfs and trigger a vfs assertion.

    Reported-by: syzbot+ec9fab8b7f0386b98a17@syzkaller.appspotmail.com
    Tested-by: syzbot+ec9fab8b7f0386b98a17@syzkaller.appspotmail.com
    Fixes: 9d23967b18c6 ("ovl: simplify an error path in ovl_copy_up_workdir()")
    Suggested-by: NeilBrown <neil@brown.name>
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>

Neil,

Please review my commit message.
If you want me to assign you ownership please sign off on this commit message.

Thanks,
Amir.

Re: [syzbot] [overlayfs?] WARNING in shmem_unlink

[NeilBrown]

On Mon, 18 Aug 2025, Amir Goldstein wrote:
> On Mon, Aug 18, 2025 at 2:34 AM NeilBrown <neil@brown.name> wrote:
> >
> > On Mon, 18 Aug 2025, Amir Goldstein wrote:
> > > Neil,
> > >
> > > I will have a look tomorrow.
> > > If you have ideas I am open to hear them.
> > > The repro is mounting overlayfs all over each other in concurrent threads
> > > and one of the rmdir of "work" dir triggers this assertion
> >
> > My guess is that by dropping and retaking the lock, we open the
> > possibility of a race so that by the time vfs_unlink() is called the
> > dentry has already been unlinked.  In that case it would be unhashed.
> > So after retaking the lock we need to check d_unhashed() as well as
> > ->d_parent.
> >
> > So something like
> > --- a/fs/overlayfs/util.c
> > +++ b/fs/overlayfs/util.c
> > @@ -1552,7 +1552,8 @@ void ovl_copyattr(struct inode *inode)
> >  int ovl_parent_lock(struct dentry *parent, struct dentry *child)
> >  {
> >         inode_lock_nested(parent->d_inode, I_MUTEX_PARENT);
> > -       if (!child || child->d_parent == parent)
> > +       if (!child ||
> > +           (!d_unhashed(child) && child->d_parent == parent))
> >                 return 0;
> >
> >         inode_unlock(parent->d_inode);
> >
> >
> > NeilBrown
> >
> 
> Nice!
> I pushed this commit to ovl-fixes:
> 
> commit c56976d86e11afcd6b23633395a7f2e6e920e42d (HEAD -> ovl-fixes)
> Author: Amir Goldstein <amir73il@gmail.com>
> Date:   Mon Aug 18 11:23:55 2025 +0200
> 
>     ovl: fix possible double unlink
> 
>     commit 9d23967b18c6 ("ovl: simplify an error path in
>     ovl_copy_up_workdir()") introduced the helper ovl_cleanup_unlocked(),
>     which is later used in several following patches to re-acquire the parent
>     inode lock and unlink a dentry that was earlier found using lookup.
>     This helper was eventually renamed to ovl_cleanup().
> 
>     The helper ovl_parent_lock() is used to re-acquire the parent inode lock.
>     After acquiring the parent inode lock, the helper verifies that the
>     dentry has not since been moved to another parent, but it failed to
>     verify that the dentry wasn't unlinked from the parent.
> 
>     This means that now every call to ovl_cleanup() could potentially
>     race with another thread, unlinking the dentry to be cleaned up
>     underneath overlayfs and trigger a vfs assertion.
> 
>     Reported-by: syzbot+ec9fab8b7f0386b98a17@syzkaller.appspotmail.com
>     Tested-by: syzbot+ec9fab8b7f0386b98a17@syzkaller.appspotmail.com
>     Fixes: 9d23967b18c6 ("ovl: simplify an error path in ovl_copy_up_workdir()")
>     Suggested-by: NeilBrown <neil@brown.name>
>     Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> 
> Neil,
> 
> Please review my commit message.
> If you want me to assign you ownership please sign off on this commit message.

Looks good to me.  No changes needed.

NeilBrown


> 
> Thanks,
> Amir.
> 

Re: [syzbot] [overlayfs?] WARNING in shmem_unlink

[Amir Goldstein]

On Mon, Aug 18, 2025 at 11:35 PM NeilBrown <neil@brown.name> wrote:
>
> On Mon, 18 Aug 2025, Amir Goldstein wrote:
> > On Mon, Aug 18, 2025 at 2:34 AM NeilBrown <neil@brown.name> wrote:
> > >
> > > On Mon, 18 Aug 2025, Amir Goldstein wrote:
> > > > Neil,
> > > >
> > > > I will have a look tomorrow.
> > > > If you have ideas I am open to hear them.
> > > > The repro is mounting overlayfs all over each other in concurrent threads
> > > > and one of the rmdir of "work" dir triggers this assertion
> > >
> > > My guess is that by dropping and retaking the lock, we open the
> > > possibility of a race so that by the time vfs_unlink() is called the
> > > dentry has already been unlinked.  In that case it would be unhashed.
> > > So after retaking the lock we need to check d_unhashed() as well as
> > > ->d_parent.
> > >
> > > So something like
> > > --- a/fs/overlayfs/util.c
> > > +++ b/fs/overlayfs/util.c
> > > @@ -1552,7 +1552,8 @@ void ovl_copyattr(struct inode *inode)
> > >  int ovl_parent_lock(struct dentry *parent, struct dentry *child)
> > >  {
> > >         inode_lock_nested(parent->d_inode, I_MUTEX_PARENT);
> > > -       if (!child || child->d_parent == parent)
> > > +       if (!child ||
> > > +           (!d_unhashed(child) && child->d_parent == parent))
> > >                 return 0;
> > >
> > >         inode_unlock(parent->d_inode);
> > >
> > >
> > > NeilBrown
> > >
> >
> > Nice!
> > I pushed this commit to ovl-fixes:
> >
> > commit c56976d86e11afcd6b23633395a7f2e6e920e42d (HEAD -> ovl-fixes)
> > Author: Amir Goldstein <amir73il@gmail.com>
> > Date:   Mon Aug 18 11:23:55 2025 +0200
> >
> >     ovl: fix possible double unlink
> >
> >     commit 9d23967b18c6 ("ovl: simplify an error path in
> >     ovl_copy_up_workdir()") introduced the helper ovl_cleanup_unlocked(),
> >     which is later used in several following patches to re-acquire the parent
> >     inode lock and unlink a dentry that was earlier found using lookup.
> >     This helper was eventually renamed to ovl_cleanup().
> >
> >     The helper ovl_parent_lock() is used to re-acquire the parent inode lock.
> >     After acquiring the parent inode lock, the helper verifies that the
> >     dentry has not since been moved to another parent, but it failed to
> >     verify that the dentry wasn't unlinked from the parent.
> >
> >     This means that now every call to ovl_cleanup() could potentially
> >     race with another thread, unlinking the dentry to be cleaned up
> >     underneath overlayfs and trigger a vfs assertion.
> >
> >     Reported-by: syzbot+ec9fab8b7f0386b98a17@syzkaller.appspotmail.com
> >     Tested-by: syzbot+ec9fab8b7f0386b98a17@syzkaller.appspotmail.com
> >     Fixes: 9d23967b18c6 ("ovl: simplify an error path in ovl_copy_up_workdir()")
> >     Suggested-by: NeilBrown <neil@brown.name>
> >     Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> >
> > Neil,
> >
> > Please review my commit message.
> > If you want me to assign you ownership please sign off on this commit message.
>
> Looks good to me.  No changes needed.

We are having some problems with this fix colliding with a new ovl feature [1].

Let's try to test this revised fix:

#syz test: https://github.com/amir73il/linux ovl_casefold

Thanks,
Amir.

[1] https://lore.kernel.org/linux-unionfs/CAOQ4uxj551a7cvjpcYEyTLtsEXw9OxHtTc-VSm170J5pWtwoUQ@mail.gmail.com/

Re: [syzbot] [overlayfs?] WARNING in shmem_unlink

[syzbot]

Hello,

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

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

Tested on:

commit:         5dfcd103 ovl: adapt ovl_parent_lock() to casefolded di..
git tree:       https://github.com/amir73il/linux ovl_casefold
console output: https://syzkaller.appspot.com/x/log.txt?x=1040fc62580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=e1e1566c7726877e
dashboard link: https://syzkaller.appspot.com/bug?extid=ec9fab8b7f0386b98a17
compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7

Note: no patches were applied.
Note: testing is done by a robot and is best-effort only.