linux-kernel - Re: [GIT pull] printk updates for 4.15

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:   Thu, 16 Nov 2017 08:12:23 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
cc:     Mark Salyzyn <salyzyn@...roid.com>, Petr Mladek <pmladek@...e.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Prarit Bhargava <prarit@...hat.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        John Stultz <john.stultz@...aro.org>
Subject: Re: [GIT pull] printk updates for 4.15

On Wed, 15 Nov 2017, Linus Torvalds wrote:
> On Wed, Nov 15, 2017 at 4:37 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> >
> > This broke stuff because the historic behaviour was to not advance on
> > resume and the change caused massive timer expiries right after resume
> > which confused the hell out of things, because timers fired immediately
> > which were not expected to fire as they were implicitely relying on suspend
> > not affecting clock monotonic.
> 
> Ahh, now that you mention it, I remember that. Things coming to a
> complete halt because every single X event timer and network timer all
> firing at resume.
> 
> If the timer wheel thing doesn't happen any more, I'd still be willing
> to try it out, but you're right, it might be much worse than I
> thought.

The timer wheel part is easy to cure, we actually tried that back then by
advancing clock monotonic, but not jiffies. That made at least most of the
kernel side issues go away, but the user space wreckage persisted and we
saw now way to fix that w/o violating the no user space visible regression
rule.

It might be better now, so yes might can try and see what happens. The
android folks surely an run a quick coverage test on their side, but we'd
need to get some serious feedback from desktop and enterprise people as
well.

The first thing we need to look at before even going there is stuff like
NTP which needs the coupling of MONOTONIC and MONOTONIC_RAW preserved. I
need to make sure that this does not break in the first place.

I hope that I can find a few spare cycles to whip up a POC patch which does
not make stuff fall apart immediately.

Thanks,

	tglx