All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>, Jan Kara <jack@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Jan Kara <jack@suse.com>, Tejun Heo <tj@kernel.org>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Byungchul Park <byungchul.park@lge.com>,
	vlevenetz@mm-sol.com,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH v10 1/2] printk: Make printk() completely async
Date: Fri, 19 Aug 2016 11:54:55 +0200	[thread overview]
Message-ID: <20160819095455.GR13300@pathway.suse.cz> (raw)
In-Reply-To: <20160819063236.GA584@swordfish>

On Fri 2016-08-19 15:32:36, Sergey Senozhatsky wrote:
> On (08/18/16 12:56), Petr Mladek wrote:
> > The advantage of the printk_func trick is that it is transparent.
> > You do not need to modify any existing functions used by WARN()/BUG()
> > macros.
> 
> good point.
> 
> so something like below, perhaps. I'm less sure about
> deferred BUG()/BUG_ON():
> 
> #define DEFERRED_BUG() do { 		\
> 	printk_deferred_enter();	\
> 	BUG();				\
> 	printk_deferred_exit();		\
> } while (0)				\
> 
> #define DEFERRED_BUG_ON(condition) do { \
> 	printk_deferred_enter();	\
> 	BUG_ON(condition);		\
> 	printk_deferred_exit();		\
> } while (0)
> 
> depending on .config BUG() may never return back -- passing control
> to do_exit(), so printk_deferred_exit() won't be executed. thus we
> probably need to have a per-cpu variable that would indicate that
> we are in deferred_bug. hm... but do we really need deferred BUG()
> in the first place?

Good question. I am not aware of any BUG_ON() that would be called from
wake_up_process() but it is hard to check everything.

A conservative approach would be to force synchronous printk from
BUG_ON().


> Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> 
> ---
> 
>  include/asm-generic/bug.h | 50 +++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/printk.h    |  6 ++++++
>  kernel/printk/internal.h  | 18 +----------------
>  kernel/printk/printk.c    | 42 ++++++++++++++++++++++++++++++++++-----
>  4 files changed, 94 insertions(+), 22 deletions(-)
> 
> diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
> index 6f96247..d72ee1e 100644
> --- a/include/asm-generic/bug.h
> +++ b/include/asm-generic/bug.h
> @@ -60,6 +60,10 @@ struct bug_entry {
>   * significant issues that need prompt attention if they should ever
>   * appear at runtime.  Use the versions with printk format strings
>   * to provide better diagnostics.
> + *
> + * DEFERRED_WARN macros call printk_deferred() to print the messages
> + * and are meant to be used from the contexts where direct printk()
> + * can deadlock the system.
>   */
>  #ifndef __WARN_TAINT
>  extern __printf(3, 4)
> @@ -145,6 +149,52 @@ void __warn(const char *file, int line, void *caller, unsigned taint,
>  	unlikely(__ret_warn_once);				\
>  })
>  
> +#define DEFERRED_WARN_ON(condition) ({				\
> +	int __ret_warn_on = !!(condition);			\
> +	if (unlikely(__ret_warn_on)) {				\
> +		printk_deferred_enter();			\
> +		__WARN();					\
> +		printk_deferred_exit();				\
> +	}							\
> +	unlikely(__ret_warn_on);				\
> +})

This looks reasonable to me.


> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 0d3e026..6e260a0 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
>  
> +void printk_deferred_enter(void)
> +{
> +	preempt_disable();
> +	this_cpu_write(printk_func, vprintk_deferred);
> +}
> +EXPORT_SYMBOL(printk_deferred_enter);
> +
> +void printk_deferred_exit(void)
> +{
> +	this_cpu_write(printk_func, vprintk_default);
> +	preempt_enable();
> +}
> +EXPORT_SYMBOL(printk_deferred_exit);
> +

This is racy with printk_nmi_enter() and printk_nmi_exit().
It need to work both ways. It must keep printk_deferred()
even when DEFERRED_WARN_ON() is called in nmi context.
Also it must keep printk_deferred() when the DEFERRED_WARN_ON()
is interrupted by an nmi.

It think that best solution would be to allow nesting.
What about replacing "printk_func" per-CPU variable
with a per-CPU atomic counter. Then we could just
check the counter in vprintk_emit() to see if it is
deferred or not.

The approach with printk_func() was more generic. We thought
that it might be used even for a transparent early_printk().
But it still might be solved even with the per-CPU atomic
counter. We could fallback to the early_printk when a
global flag is set or so.

Best Regards,
Petr

  reply	other threads:[~2016-08-19  9:55 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-04 16:57 [PATCH v10 0/2] printk: Make printk() completely async Sergey Senozhatsky
2016-04-04 16:57 ` [PATCH v10 1/2] " Sergey Senozhatsky
2016-04-04 22:51   ` Andrew Morton
2016-04-05  5:17     ` Sergey Senozhatsky
2016-04-05  7:39       ` Sergey Senozhatsky
2016-04-06  0:19         ` Sergey Senozhatsky
2016-04-06  8:27     ` Jan Kara
2016-04-07  9:48       ` Sergey Senozhatsky
2016-04-07 12:08         ` Sergey Senozhatsky
2016-04-07 13:15           ` Jan Kara
2016-08-10 21:17       ` Viresh Kumar
2016-08-12  9:44         ` Petr Mladek
2016-08-15 14:26           ` Vladislav Levenetz
2016-08-16  9:04             ` Petr Mladek
2016-08-18  2:27           ` Sergey Senozhatsky
2016-08-18  9:33             ` Petr Mladek
2016-08-18  9:51               ` Sergey Senozhatsky
2016-08-18 10:56                 ` Petr Mladek
2016-08-19  6:32                   ` Sergey Senozhatsky
2016-08-19  9:54                     ` Petr Mladek [this message]
2016-08-19 19:00                       ` Jan Kara
2016-08-20  5:24                         ` Sergey Senozhatsky
2016-08-22  4:15                           ` Sergey Senozhatsky
2016-08-23 12:19                             ` Petr Mladek
2016-08-24  1:33                               ` Sergey Senozhatsky
2016-08-25 21:10                             ` Petr Mladek
2016-08-26  1:56                               ` Sergey Senozhatsky
2016-08-26  8:20                                 ` Sergey Senozhatsky
2016-08-30  9:29                                 ` Petr Mladek
2016-08-31  2:31                                   ` Sergey Senozhatsky
2016-08-31  9:38                                     ` Petr Mladek
2016-08-31 12:52                                       ` Sergey Senozhatsky
2016-09-01  8:58                                         ` Petr Mladek
2016-09-02  7:58                                           ` Sergey Senozhatsky
2016-09-02 15:15                                             ` Petr Mladek
2016-09-06  7:16                                               ` Sergey Senozhatsky
2016-08-23 13:03                           ` Petr Mladek
2016-08-23 13:48                         ` Petr Mladek
2016-04-04 16:57 ` [PATCH v10 2/2] printk: Make wake_up_klogd_work_func() async Sergey Senozhatsky
  -- strict thread matches above, loose matches on Subject: below --
2016-08-23  3:32 [PATCH v10 1/2] printk: Make printk() completely async Andreas Mohr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160819095455.GR13300@pathway.suse.cz \
    --to=pmladek@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=byungchul.park@lge.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jack@suse.com \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=tj@kernel.org \
    --cc=viresh.kumar@linaro.org \
    --cc=vlevenetz@mm-sol.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.