linux-kernel - Re: sched: serial port lockdep warning when offlining CPUs

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: <20170928120722.ir5tcclsg336ou2n@hirez.programming.kicks-ass.net>
Date:   Thu, 28 Sep 2017 14:07:22 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     "Levin, Alexander (Sasha Levin)" <alexander.levin@...izon.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Sasha Levin <levinsasha928@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...e.hu>,
        "linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>,
        "pmladek@...e.com" <pmladek@...e.com>,
        "sergey.senozhatsky@...il.com" <sergey.senozhatsky@...il.com>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>
Subject: Re: sched: serial port lockdep warning when offlining CPUs

On Thu, Sep 28, 2017 at 02:05:32PM +0200, Peter Zijlstra wrote:
> (please linewrap normal text at 72 chars)
> 
> On Thu, Sep 28, 2017 at 11:45:30AM +0000, Levin, Alexander (Sasha Levin) wrote:
> > Okay, that seems to have delt with the callbacks supressed issue.
> > 
> > I also seem to be hitting it as a result of the scheduler triggering a
> > WARN, where print_stack_trace(), for example, just uses printk().
> > 
> > Now I'm not sure what's your approach here, do we keep converting
> > printk to printk_deferred one by one until we whacked every mole?
> 
> Nah.. WARN's _should_ not trigger. If they do we fix that.
> 
> Getting a lockdep splat after a WARN is something I can live with.
> 
> And you really don't want that deferred nonsense for WARNs, because that
> means you'll risk not over getting the output.

Note that I'm not likely to care too much either way, because I'm simply
not using any of that printk() nonsense ;-)


I'll repost my patches now; otherwise I'll forget again anyway.