[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161019093051.GG3102@twins.programming.kicks-ass.net>
Date: Wed, 19 Oct 2016 11:30:51 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Petr Mladek <pmladek@...e.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Jan Kara <jack@...e.cz>, Tejun Heo <tj@...nel.org>,
Calvin Owens <calvinowens@...com>,
Thomas Gleixner <tglx@...utronix.de>,
Mel Gorman <mgorman@...hsingularity.net>,
Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCHv3 0/6] printk: use printk_safe to handle printk()
recursive calls
On Wed, Oct 19, 2016 at 10:53:57AM +0900, Sergey Senozhatsky wrote:
> not to miss out a DEFERRED_WARN patch set...
> //hm, I can't find it online
>
> Subject: [RFC 0/5] printk: Implement WARN_*DEFERRED()
> Message-Id: <1474992135-14777-1-git-send-email-pmladek@...e.com>
That never hit lkml, that msgid does not resolve on marc and I can only
find a few replies in my local lkml archive.
Can't say I like the idea though. Its propagating the printk() failure
up into more APIs instead of actually fixing it.
Esp. for WARN and the like you do not want DEFERRED, because DEFERRED
means you'll likely never actually get to see the problem because we're
dead by the time 'later' happens.
Powered by blists - more mailing lists