linux-kernel - Re: linux.git: printk() problem

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+55aFwNU_ggMjguqFNHpY6r4UmsLuu3-rXKoNRi8umRNCRJQw@mail.gmail.com>
Date:   Mon, 24 Oct 2016 10:54:30 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Cc:     Joe Perches <joe@...ches.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Petr Mladek <pmladek@...e.cz>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Subject: Re: linux.git: printk() problem

On Mon, Oct 24, 2016 at 7:08 AM, Sergey Senozhatsky
<sergey.senozhatsky@...il.com> wrote:
>
> is mod_timer() safe enough to rely on/call from
>         panic()->console_flush_on_panic()->console_unlock() ?

I don't think that's a big issue: the whole "panic()" siotuation is
very much about best effort.

> shouldn't deferred_cont_flush() be called every time we jump
> to `again' label in console_unlock()?

actually, I think we should just do it at the end.

And your "spinlock bad magic" reports says to me that we should
actually delay it even more, and just do it in klogd, to avoid the
whole issue with "printk() is used very _very_ early during boot".

Because if klogd isn't even running yet, then we clearly don't care
about timely flushing to the logs.

So here's a new version - TOTALLY UNTESTED! - that removes even more
redundant code (all the "test previous record flags" crud - it is not
sensible to think that the previous record was what a continuation was
all about, since the whole reason the continuation didn't get merged
was that something else happened in between).

Note the "totally untested" part. It compiles for me. But it may do
unspeakably stupid things. Caveat applior.

             Linus