From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Jan Kara <jack@suse.cz>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Petr Mladek <pmladek@suse.cz>, KY Sri nivasan <kys@microsoft.com>,
Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/7] printk: Hand over printing to console if printing too long
Date: Wed, 23 Dec 2015 12:57:32 +0900 [thread overview]
Message-ID: <20151223035732.GC2008@swordfish> (raw)
In-Reply-To: <20151223033724.GB2008@swordfish>
On (12/23/15 12:37), Sergey Senozhatsky wrote:
> Date: Wed, 23 Dec 2015 12:37:24 +0900
> From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
> To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
> Cc: Jan Kara <jack@suse.cz>, Sergey Senozhatsky
> <sergey.senozhatsky@gmail.com>, Andrew Morton <akpm@linux-foundation.org>,
> Petr Mladek <pmladek@suse.cz>, KY Sri nivasan <kys@microsoft.com>, Steven
> Rostedt <rostedt@goodmis.org>, linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/7] printk: Hand over printing to console if printing
> too long
> User-Agent: Mutt/1.5.24 (2015-08-30)
>
> On (12/23/15 10:54), Sergey Senozhatsky wrote:
> > On (12/22/15 14:47), Jan Kara wrote:
> > [..]
> > > @@ -1803,10 +1869,24 @@ asmlinkage int vprintk_emit(int facility, int level,
> > > logbuf_cpu = UINT_MAX;
> > > raw_spin_unlock(&logbuf_lock);
> > > lockdep_on();
> > > + /*
> > > + * By default we print message to console asynchronously so that kernel
> > > + * doesn't get stalled due to slow serial console. That can lead to
> > > + * softlockups, lost interrupts, or userspace timing out under heavy
> > > + * printing load.
> > > + *
> > > + * However we resort to synchronous printing of messages during early
> > > + * boot, when oops is in progress, or when synchronous printing was
> > > + * explicitely requested by kernel parameter.
> > > + */
> > > + if (keventd_up() && !oops_in_progress && !sync_print) {
> > > + __this_cpu_or(printk_pending, PRINTK_PENDING_OUTPUT);
> > > + irq_work_queue(this_cpu_ptr(&wake_up_klogd_work));
> > > + } else
> > > + sync_print = true;
>
> oops, didn't have enough coffee... missed that `else sync_print = true' :(
>
ah, never mind my previous email... it's a local variable, so the very next printk()
happening right after bust_spinlocks(0) will irq_work_queue(). I'd prefer CPUs to
print stacks rather than burn cpu cycles in `while (1) cpu_relax()' loop.
so
else {
printk_sync = true;
sync_print = true; /* and remove this local variable entirely may be*/
}
> > can we replace this oops_in_progress check with something more reliable?
> >
> > CPU0 CPU1 - CPUN
> > panic()
> > local_irq_disable() executing foo() with irqs disabled,
> > console_verbose() or processing an extremely long irq handler.
> > bust_spinlocks()
> > oops_in_progress++
or we huge enough number of CPUs, `deep' stack
traces, slow serial and CPU doing dump_stack()
under raw_spin_lock(&stop_lock), so it can take
longer than 1 second to print the stacks and
thus panic CPU will set oops_in_progress back
to 0.
> > smp_send_stop()
> >
> > bust_spinlocks()
> > oops_in_progress-- ok, IPI arrives
> > dump_stack()/printk()/etc from IPI_CPU_STOP
> > "while (1) cpu_relax()" with irq/fiq disabled/halt/etc.
> >
> > smp_send_stop() wrapped in `oops_in_progress++/oops_in_progress--' is arch specific,
> > and some platforms don't do any IPI-delivered (e.g. via num_online_cpus()) checks at
> > all. Some do. For example, arm/arm64:
> >
> > void smp_send_stop(void)
> > ...
> > /* Wait up to one second for other CPUs to stop */
> > timeout = USEC_PER_SEC;
> > while (num_online_cpus() > 1 && timeout--)
> > udelay(1);
> >
> > if (num_online_cpus() > 1)
> > pr_warn("SMP: failed to stop secondary CPUs\n");
> > ...
> >
> >
> > so there are non-zero chances that IPI will arrive to CPU after 'oops_in_progress--',
> > and thus dump_stack()/etc. happening on that/those cpu/cpus will be lost.
> >
> >
> > bust_spinlocks(0) does
> > ...
> > if (--oops_in_progress == 0)
> > wake_up_klogd();
> > ...
> >
> > but local cpu has irqs disabled and `panic_timeout' can be zero.
> >
> > How about setting 'sync_print' to 'true' in...
> > bust_spinlocks() /* only set to true */
> > or
> > console_verbose() /* um... may be... */
> > or
> > having a separate one-liner for that
> >
> > void console_panic_mode(void)
> > {
> > sync_print = true;
printk_sync = true;
> > }
> >
> > and call it early in panic(), before we send out IPI_STOP.
-ss
next prev parent reply other threads:[~2015-12-23 3:56 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-10 14:52 [PATCH 1/7] printk: Hand over printing to console if printing too long Sergey Senozhatsky
2015-12-10 15:24 ` Sergey Senozhatsky
2015-12-11 4:27 ` Sergey Senozhatsky
2015-12-11 6:29 ` Sergey Senozhatsky
2015-12-22 13:47 ` Jan Kara
2015-12-22 14:48 ` Sergey Senozhatsky
2015-12-23 1:54 ` Sergey Senozhatsky
2015-12-23 3:37 ` Sergey Senozhatsky
2015-12-23 3:57 ` Sergey Senozhatsky [this message]
2015-12-23 4:15 ` Sergey Senozhatsky
2016-01-05 14:37 ` Jan Kara
2016-01-06 1:41 ` Sergey Senozhatsky
2016-01-06 6:48 ` Sergey Senozhatsky
2016-01-06 12:25 ` Jan Kara
2016-01-11 13:25 ` Sergey Senozhatsky
2015-12-31 2:44 ` Sergey Senozhatsky
2015-12-31 3:13 ` Sergey Senozhatsky
2015-12-31 4:58 ` Sergey Senozhatsky
2016-01-05 14:48 ` Jan Kara
2016-01-06 3:38 ` Sergey Senozhatsky
2016-01-06 8:36 ` Sergey Senozhatsky
2016-01-06 10:21 ` Jan Kara
2016-01-06 11:10 ` Sergey Senozhatsky
2016-01-11 12:54 ` Petr Mladek
2016-01-12 14:00 ` Jan Kara
-- strict thread matches above, loose matches on Subject: below --
2015-10-26 4:52 [PATCH 0/6 v2] printk: Softlockup avoidance Jan Kara
2015-10-26 4:52 ` [PATCH 1/7] printk: Hand over printing to console if printing too long Jan Kara
2016-03-01 17:22 ` Denys Vlasenko
2016-03-02 9:30 ` Jan Kara
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=20151223035732.GC2008@swordfish \
--to=sergey.senozhatsky.work@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=jack@suse.cz \
--cc=kys@microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.cz \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).