linux-kernel - Re: clockevents_program_event WARN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 3 May 2013 00:49:20 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Yinghai Lu <yinghai@...nel.org>
cc:	Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: clockevents_program_event WARN_ON preventing boot.

On Thu, 2 May 2013, Yinghai Lu wrote:
> On Thu, May 2, 2013 at 2:19 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> > Can you please apply the following debug patch and provide the output?
> >
> > diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
> > index c6d6400..b4d9622 100644
> > --- a/kernel/time/clockevents.c
> > +++ b/kernel/time/clockevents.c
> > @@ -207,6 +207,8 @@ int clockevents_program_event(struct clock_event_device *dev, ktime_t expires,
> >
> >         if (unlikely(expires.tv64 < 0)) {
> >                 WARN_ON_ONCE(1);
> > +               printk_once(KERN_INFO "expires %llx, dev->next %llx\n",
> > +                           expires.tv64, dev->next_event.tv64);

> [    3.454628] expires 80000000003d08ff, dev->next 7fffffffffffffff

So dev->next_event == KTIME_MAX. That means that the device has been
shut down, at least I can't see any other reason at that point - we
are not in highres/nohz mode yet. And it still got an interrupt served
for whatever reason. What's even more confusing is that in
tick_handle_periodic() we check for:

        if (dev->mode != CLOCK_EVT_MODE_ONESHOT)
                return;

So if the device is shutdown for real the mode would be
CLOCK_EVT_MODE_SHUTDOWN and we'd never reach that code.

Shut down at that point only happens in context of the broadcast
crap. Your crash:

[   10.272017] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000048
[   10.289803] IP: [<ffffffff810e3c46>] tick_do_broadcast+0x86/0xa0

points to the broadcast stuff as well. 0x48 is the offset of the
broadcast function. So your machine died at:

                td->evtdev->broadcast(mask);

That means, that the cpu was set in the broadcast mask, but the per
cpu event device was not yet registered !?!

That does not make any sense, as we explicitely prevent the broadcast
activation for cpus which have no per cpu tick device registered yet.

I'm fundamentally confused and Daves observation about slub debug does
not make it less confusing.

It'd be nice if you could add some more instrumentation or bisect the
issue.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/