linux-kernel - Re: [RFC PATCH 00/11] printk: safe printing in NMI context

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: <alpine.LNX.2.00.1406182232390.2303@pobox.suse.cz>
Date:	Wed, 18 Jun 2014 22:36:10 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Michal Hocko <mhocko@...e.cz>, Jan Kara <jack@...e.cz>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Dave Anderson <anderson@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Petr Mladek <pmladek@...e.cz>, Kay Sievers <kay@...y.org>
Subject: Re: [RFC PATCH 00/11] printk: safe printing in NMI context

On Wed, 18 Jun 2014, Paul E. McKenney wrote:

> OK, unconditional non-use of NMIs is even easier.  ;-)
> 
> Something like the following.
> 
> 							Thanx, Paul
> 
> ------------------------------------------------------------------------
> 
> rcu: Don't use NMIs to dump other CPUs' stacks
> 
> Although NMI-based stack dumps are in principle more accurate, they are
> also more likely to trigger deadlocks.  This commit therefore replaces
> all uses of trigger_all_cpu_backtrace() with rcu_dump_cpu_stacks(), so
> that the CPU detecting an RCU CPU stall does the stack dumping.
> 
> Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> 
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index c590e1201c74..777624e1329b 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -932,10 +932,7 @@ static void record_gp_stall_check_time(struct rcu_state *rsp)
>  }
>  
>  /*
> - * Dump stacks of all tasks running on stalled CPUs.  This is a fallback
> - * for architectures that do not implement trigger_all_cpu_backtrace().
> - * The NMI-triggered stack traces are more accurate because they are
> - * printed by the target CPU.
> + * Dump stacks of all tasks running on stalled CPUs.
>   */
>  static void rcu_dump_cpu_stacks(struct rcu_state *rsp)
>  {
> @@ -1013,7 +1010,7 @@ static void print_other_cpu_stall(struct rcu_state *rsp)
>  	       (long)rsp->gpnum, (long)rsp->completed, totqlen);
>  	if (ndetected == 0)
>  		pr_err("INFO: Stall ended before state dump start\n");
> -	else if (!trigger_all_cpu_backtrace())
> +	else
>  		rcu_dump_cpu_stacks(rsp);
>  
>  	/* Complain about tasks blocking the grace period. */
> @@ -1044,8 +1041,7 @@ static void print_cpu_stall(struct rcu_state *rsp)
>  	pr_cont(" (t=%lu jiffies g=%ld c=%ld q=%lu)\n",
>  		jiffies - rsp->gp_start,
>  		(long)rsp->gpnum, (long)rsp->completed, totqlen);
> -	if (!trigger_all_cpu_backtrace())
> -		dump_stack();
> +	rcu_dump_cpu_stacks(rsp);

This is prone to producing not really consistent stacktraces though, 
right? As the target task is still running at the time the stack is being 
walked, it might produce stacktraces that are potentially nonsensial.

How about sending NMI to the target CPU, so that the task is actually 
stopped, but printing its stacktrace from the CPU that detected the stall 
while it's stopped?

That way, there is no printk()-from-NMI, but also the stacktrace is 
guaranteed to be self-consistent.

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/