[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251021123534.GU3419281@noisy.programming.kicks-ass.net>
Date: Tue, 21 Oct 2025 14:35:34 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Juri Lelli <juri.lelli@...hat.com>
Cc: Shrikanth Hegde <sshegde@...ux.ibm.com>,
Thomas Gleixner <tglx@...utronix.de>,
syzbot <syzbot+8b3a2e23253b50098164@...kaller.appspotmail.com>,
anna-maria@...utronix.de, frederic@...nel.org,
linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com,
Juri Lelli <jlelli@...hat.com>
Subject: Re: [syzbot] [kernel?] WARNING in hrtimer_forward (4)
On Tue, Oct 21, 2025 at 02:18:11PM +0200, Juri Lelli wrote:
> On 21/10/25 10:12, Shrikanth Hegde wrote:
> >
> >
> > On 9/11/25 2:45 PM, Juri Lelli wrote:
> > > On 10/09/25 22:07, Thomas Gleixner wrote:
> > > > On Fri, Aug 29 2025 at 19:00, syzbot wrote:
> > > >
> > > > > HEAD commit: b6add54ba618 Merge tag 'pinctrl-v6.17-2' of git://git.kern..
> > > > > git tree: upstream
> > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1130eef0580000
> > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=e1e1566c7726877e
> > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=8b3a2e23253b50098164
> > > > > compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
> > > > >
> > > > > Unfortunately, I don't have any reproducer for this issue yet.
> > > > >
> > > > > Downloadable assets:
> > > > > disk image: https://storage.googleapis.com/syzbot-assets/102656909b6f/disk-b6add54b.raw.xz
> > > > > vmlinux: https://storage.googleapis.com/syzbot-assets/fa30d1d80a47/vmlinux-b6add54b.xz
> > > > > kernel image: https://storage.googleapis.com/syzbot-assets/c25ee8abf30a/bzImage-b6add54b.xz
> > > > >
> > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > > > Reported-by: syzbot+8b3a2e23253b50098164@...kaller.appspotmail.com
> > > > >
> > > > > ------------[ cut here ]------------
> > > > > WARNING: CPU: 1 PID: 1186 at kernel/time/hrtimer.c:1052 hrtimer_forward+0x1d6/0x2b0 kernel/time/hrtimer.c:1052
> > > > > Modules linked in:
> > > > > CPU: 1 UID: 0 PID: 1186 Comm: irq/33-virtio1- Not tainted syzkaller #0 PREEMPT_{RT,(full)}
> > > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025
> > > > > RIP: 0010:hrtimer_forward+0x1d6/0x2b0 kernel/time/hrtimer.c:1052
> > > >
> > > > It compains that the timer is enqueued when it is attempted to be forwarded
> > > >
> > > > > Code: 4c 89 33 48 8b 04 24 eb 07 e8 86 34 12 00 31 c0 48 83 c4 18 5b 41 5c 41 5d 41 5e 41 5f 5d e9 01 d8 4d 09 cc e8 6b 34 12 00 90 <0f> 0b 90 eb df 48 89 e8 4c 09 f8 48 c1 e8 20 74 0a 48 89 e8 31 d2
> > > > > RSP: 0018:ffffc90000a78bd0 EFLAGS: 00010006
> > > > > RAX: ffffffff81ac27e5 RBX: ffff8880b883b508 RCX: ffff888026c19dc0
> > > > > RDX: 0000000000000100 RSI: 0000000000010000 RDI: 0000000000010100
> > > > > RBP: 000000000009d057 R08: 0000000000010000 R09: 0000000000010100
> > > > > R10: dffffc0000000000 R11: ffffffff8167a890 R12: ffff8880b883b520
> > > > > R13: 0000000000184487 R14: 1ffff110171076a4 R15: 0000000000000001
> > > > > FS: 0000000000000000(0000) GS:ffff8881269c2000(0000) knlGS:0000000000000000
> > > > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > > > CR2: 00007f95323cbf98 CR3: 0000000064088000 CR4: 00000000003526f0
> > > > > Call Trace:
> > > > > <IRQ>
> > > > > hrtimer_forward_now include/linux/hrtimer.h:366 [inline]
> > > > > dl_server_timer kernel/sched/deadline.c:1193 [inline]
> > > >
> > > > which is strange as this is with the timer callback itself, so it
> > > > shouldn't be enqueued, unless there is a possiblilty to have:
> > > >
> > > > CPU0 CPU1
> > > > timer_expires()
> > > > callback() ????
> > > > dl_task_timer() rq_lock()
> > > > rq_lock() hrtimer_start()
> > > > rq_unlock()
> > > > hrtimer_forward()
> > > >
> > > > No idea whether that's possible, but that's the only sensible
> > > > explanation.
> > >
> > > So, a dl_server_start() could be your ????, but it should see
> > > dl_server_active and just return if the dl_server callback is running.
> > > Unless a dl_server_stop() somehow interleaved as well and cleared it.
> > >
> >
> > isn't dl_server timer per CPU?
>
> Indeed you have a point. Also dl-server timers handling has changed
> recently with several fixes from Peter.
Can still be a remote wakeup trying to start the timer.
Anyway, yeah, we've changed a bit around here, but we're still not quite
done -- there is that issue from Gabriel.
Also, every time I look at this code I get confused, so perhaps that
needs fixing too.
I'll poke at it some.
Powered by blists - more mailing lists