Re: [syzbot] [xfs?] WARNING in mod_delayed_work_on (2)

[Dave Chinner <david@fromorbit.com>]

On Tue, Nov 12, 2024 at 07:56:21PM -0800, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    f1dce1f09380 Merge tag 'slab-for-6.12-rc7' of git://git.ke..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=143eaea7980000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=347f0ef7656eeb41
> dashboard link: https://syzkaller.appspot.com/bug?extid=3c653ce382d9a9b6fbc3
> compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> 
> Unfortunately, I don't have any reproducer for this issue yet.
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/290169b0e6d0/disk-f1dce1f0.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/e26fb82ee406/vmlinux-f1dce1f0.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/d26ba056ed6b/bzImage-f1dce1f0.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+3c653ce382d9a9b6fbc3@syzkaller.appspotmail.com
> 
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 8571 at kernel/workqueue.c:2498 __queue_delayed_work+0x212/0x250 kernel/workqueue.c:2498
> Modules linked in:
> CPU: 0 UID: 0 PID: 8571 Comm: syz-executor Not tainted 6.12.0-rc6-syzkaller-00192-gf1dce1f09380 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024
> RIP: 0010:__queue_delayed_work+0x212/0x250 kernel/workqueue.c:2498

WARN_ON_ONCE(!list_empty(&work->entry));

> Code: 0f 0b 90 e9 39 fe ff ff e8 8b 9f 37 00 90 0f 0b 90 e9 65 fe ff ff e8 7d 9f 37 00 90 0f 0b 90 e9 81 fe ff ff e8 6f 9f 37 00 90 <0f> 0b 90 e9 9f fe ff ff e8 61 9f 37 00 48 89 df 44 89 f6 eb ac 89
> RSP: 0018:ffffc90002d5fac8 EFLAGS: 00010093
> RAX: ffffffff815d3a91 RBX: ffffe8ffffc43440 RCX: ffff888028098000
> RDX: 0000000000000000 RSI: ffff88805a2f1800 RDI: 0000000000000000
> RBP: ffffe8ffffc43448 R08: ffffffff815d3c06 R09: 0000000000000000
> R10: ffffc90002d5fb40 R11: fffff520005abf69 R12: 0000000000000001
> R13: dffffc0000000000 R14: 0000000000000000 R15: ffff88805a2f1800
> FS:  000055556c4f5500(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fdcb605fe07 CR3: 000000005d732000 CR4: 00000000003526f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>  <TASK>
>  mod_delayed_work_on+0x153/0x370 kernel/workqueue.c:2588
>  xfs_inodegc_queue fs/xfs/xfs_icache.c:2158 [inline]
>  xfs_inode_mark_reclaimable+0x7a6/0xf60 fs/xfs/xfs_icache.c:2194
>  destroy_inode fs/inode.c:315 [inline]
>  evict+0x7b5/0x9b0 fs/inode.c:756
>  do_unlinkat+0x512/0x830 fs/namei.c:4540

AFAICT there is nothing wrong with the way XFS is using
mod_delayed_work_on() here - the internal work entry state that the
workqueue infrastructure manages appears to be in an incorrect
state.

This is not obviously an XFS issue.

-Dave.

-- 
Dave Chinner
david@fromorbit.com