From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S942183AbcJFPzQ (ORCPT <rfc822;w@1wt.eu>);
        Thu, 6 Oct 2016 11:55:16 -0400
Received: from mx2.suse.de ([195.135.220.15]:59590 "EHLO mx2.suse.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S942032AbcJFPzJ (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 6 Oct 2016 11:55:09 -0400
Date: Thu, 6 Oct 2016 17:55:06 +0200
From: Petr Mladek <pmladek@suse.com>
To: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Jan Kara <jack@suse.cz>, Andrew Morton <akpm@linux-foundation.org>,
        Tejun Heo <tj@kernel.org>, Calvin Owens <calvinowens@fb.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Mel Gorman <mgorman@techsingularity.net>,
        Steven Rostedt <rostedt@goodmis.org>, linux-kernel@vger.kernel.org,
        Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Subject: Re: [RFC][PATCHv2 0/7] printk: use alt_printk to handle printk()
 recursive calls
Message-ID: <20161006155506.GK13369@pathway.suse.cz>
References: <20160930151758.8965-1-sergey.senozhatsky@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160930151758.8965-1-sergey.senozhatsky@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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*

I am not sure. It is possible that I am also confused that
you used prefix rather than a suffix. I was actually forced
to rename many new functions in the kthread worker API (my other
pet project) to start with the name of the subsystem (kthread
in this case).

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.

Thanks for patience with me.

Best Regards,
Petr