All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Petr Mladek <pmladek@suse.com>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Vince Weaver <vincent.weaver@maine.edu>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	"dvyukov@google.com" <dvyukov@google.com>
Subject: Re: perf: fuzzer BUG: KASAN: stack-out-of-bounds in __unwind_start
Date: Tue, 29 Nov 2016 12:32:59 -0800	[thread overview]
Message-ID: <20161129203259.GA28037@linux.vnet.ibm.com> (raw)
In-Reply-To: <20161129200711.GF3924@linux.vnet.ibm.com>

On Tue, Nov 29, 2016 at 12:07:11PM -0800, Paul E. McKenney wrote:
> On Tue, Nov 29, 2016 at 08:52:04PM +0100, Peter Zijlstra wrote:
> > On Tue, Nov 29, 2016 at 11:39:35AM -0800, Paul E. McKenney wrote:
> > > On Tue, Nov 29, 2016 at 06:10:38PM +0100, Peter Zijlstra wrote:
> > 
> > > > It mostly works, most of the time, and that seems to be what Linus
> > > > wants, since its really the best we can have given the constraints. But
> > > > for debugging, when you have a UART, it totally blows.
> > > 
> > > UART???  They still make those things???  ;-)
> > 
> > Yes, most computer like devices actually have them, trouble is, most
> > consumer devices don't have the pins exposed. Luckily most server class
> > hardware still does.
> > 
> > And they're absolutely _awesome_ for debugging; getting data out is a
> > matter of trivial MMIO poll loops. Rock solid stuff.
> 
> They very clearly need to bring the baud rate into the current millenium,
> many tens of Mbaud at the -very- least.

On a more practical note...

Currently, cond_resched_rcu_qs() is not permitted to be invoked until
after the scheduler has started.  However, it appears that there is some
kernel code that can loop for quite some time at runtime, but which also
executes during early boot.  So it would be good to make it so that
cond_resched_rcu_qs() could be called at boot.

One approach would be to check rcu_scheduler_active, but this isn't
defined in normal Tiny RCU builds.  I can expand Tiny RCU, or I can
kludge the non-CONFIG_DEBUG_LOCK_ALLOC value of rcu_scheduler_active
to false (with this latter being the current state).  But it occurred
to me that I could also condition on !is_idle_task(), given that idle
tasks shouldn't ever be invoking the scheduler anyway.

So is the following a sensible approach, or should I look elsewhere?

	#define cond_resched_rcu_qs() \
	do { \
		if (!is_idle_task(current) && !cond_resched()) \
			rcu_note_voluntary_context_switch(current); \
	} while (0)

							Thanx, Paul

  reply	other threads:[~2016-11-29 20:33 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-24 17:33 perf: fuzzer BUG: KASAN: stack-out-of-bounds in __unwind_start Vince Weaver
2016-11-28 21:54 ` Josh Poimboeuf
2016-11-29  0:40   ` Paul E. McKenney
2016-11-29  5:52     ` Josh Poimboeuf
2016-11-29  9:16       ` Peter Zijlstra
2016-11-29 14:07         ` Paul E. McKenney
2016-11-29 15:09           ` Josh Poimboeuf
2016-11-29 16:12             ` Petr Mladek
2016-11-29 18:01               ` Paul E. McKenney
2016-11-29 16:51             ` Paul E. McKenney
2016-11-29 17:17               ` Josh Poimboeuf
2016-11-29 17:36                 ` Paul E. McKenney
2016-11-30  9:29                   ` Petr Mladek
2016-11-29 10:28       ` Paul E. McKenney
2016-11-29 12:43       ` Peter Zijlstra
2016-11-29 15:10         ` Paul E. McKenney
2016-11-29 16:29           ` Petr Mladek
2016-11-29 17:10             ` Peter Zijlstra
2016-11-29 19:39               ` Paul E. McKenney
2016-11-29 19:52                 ` Peter Zijlstra
2016-11-29 20:07                   ` Paul E. McKenney
2016-11-29 20:32                     ` Paul E. McKenney [this message]
2016-11-30 19:13                       ` Josh Poimboeuf
2016-11-30 19:49                         ` Paul E. McKenney
2016-12-01  5:52                         ` Peter Zijlstra
2016-12-01 12:33                           ` Paul E. McKenney
2016-12-01 16:41                             ` Peter Zijlstra
2016-12-01 17:00                               ` Paul E. McKenney
2016-11-30 10:01               ` Petr Mladek
2016-11-30 11:06                 ` Peter Zijlstra

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=20161129203259.GA28037@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=acme@kernel.org \
    --cc=dvyukov@google.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=vincent.weaver@maine.edu \
    /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.