linux-kernel - Re: [GIT pull] timer updates for 4.9

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]

Message-ID: <alpine.DEB.2.20.1610242324250.4815@nanos>
Date:   Mon, 24 Oct 2016 23:36:10 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
cc:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Ingo Molnar <mingo@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [GIT pull] timer updates for 4.9

On Mon, 24 Oct 2016, Linus Torvalds wrote:
> The one I'm *currently* testing seems to work for me, but that's
> because I moved the timer into klogd and that just avoids the issue.
> 
> But I'll attach my old patch just for your testing pleasure.

Of course it does not trigger... I probably need to test it on a desktop
machine to get all the goodies of that gnome shell ignoring signals.

> The fact that it actually mostly worked - and then had some very odd
> behavior much later on - makes me wonder if we might have other users
> that could have timers that get started early, and nobody notices
> because most of the time it doesn't cause any real issues.

I added a bunch of timers before init_timers(). There is no fallout aside
of the timers being queued into a random bucket and the spinlock bad magic
bug, which actually happens at spin_lock and not at unlock as I assumed.

While queueing timers before init_timers() is not correct, I think that the
early queueing is a red herring. We should really try to isolate the root
cause of this wreckage.

Can you retest that old patch with my combo patch applied and see if it
still triggers? If yes, which I expect, debugobjects might give us the hint
what to look for.

Thanks,

	tglx