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: <CA+55aFxLdf3brn_wJK7cPiDCLoSg2g-C3Sm0B6zZbcYkCO0hFw@mail.gmail.com>
Date:   Mon, 24 Oct 2016 12:30:28 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Thomas Gleixner <tglx@...utronix.de>
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, Oct 24, 2016 at 12:09 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> On Mon, 24 Oct 2016, Linus Torvalds wrote:
>
> Weird, that should have triggered in raw_spin_lock() already.
>
> Can you bounce me the patch you are currently testing?

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.

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.


> These are the things which are not initialized:
>
> 1) base->spinlock
>
>    That's a non issue for !debug kernels as the lock initializer is 0
>    (unlocked).
>
> 2) base->clk
>
>    That makes the timer queued at some random array bucket.
>
> 3) base->cpu
>
>    That's a non issue as base->cpu is 0 and at this point you are on CPU 0
>    and the stupid NOHZ remote queueing is not yet possible.
>
> The hlist_head is not touched by init_timers() as it's NULL initialized
> already, so we do not scribble over an already queued timer.
>
> So anything you queue _before_ init_timers() will just be queued to some
> random bucket, but it does not explain the wreckage you are seeing.

Here's the old version of the patch that triggered the problem. The
second attachment is the new version that works foe me (and removes a
lot more printk cruft, which is why it's bigger).

              Linus

View attachment "old.diff" of type "text/plain" (7743 bytes)

View attachment "new.diff" of type "text/plain" (19679 bytes)