[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 8 Oct 2016 03:56:33 +0900
From: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To: Petr Mladek <pmladek@...e.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Jan Kara <jack@...e.cz>,
Andrew Morton <akpm@...ux-foundation.org>,
Tejun Heo <tj@...nel.org>, Calvin Owens <calvinowens@...com>,
Thomas Gleixner <tglx@...utronix.de>,
Mel Gorman <mgorman@...hsingularity.net>,
Steven Rostedt <rostedt@...dmis.org>,
linux-kernel@...r.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Subject: Re: [RFC][PATCHv2 0/7] printk: use alt_printk to handle printk()
recursive calls
On (10/06/16 17:55), Petr Mladek wrote:
> On Sat 2016-10-01 00:17:51, Sergey Senozhatsky wrote:
> > Hello,
> >
> > RFC
> >
> > This patch set extends a lock-less NMI per-cpu buffers idea to
> > handle recursive printk() calls. The basic mechanism is pretty much the
> > same -- at the beginning of a deadlock-prone section we switch to lock-less
> > printk callback, and return back to a default printk implementation at the
> > end; the messages are getting flushed to a logbuf buffer from a safer
> > context.
>
> OK, I think again that this patch set makes sense. It looks good after
> all my doubts ;-)
>
> Just I would like you to consider using some more meaningful name
> instead of the "alt" prefix. I wonder how the following prefix
> would look like:
>
> printk_safe*
> printk_safe_nmi*
sure. I want to rename it. not entirely sure that printk_safe_enter()
is the best option here, but I can't think of anything better.
> prefix rather than a suffix.
good point. will change to 'suffix'.
> Also "alt_printk_ctx" per-CPU variable describes a global
> printk state. I think that the alt_ prefix is not needed
> and "printk_context" would be better readable.
yep, will do. thanks.
-ss
Powered by blists - more mailing lists