Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1741492 > unrolled thread

[PATCH 0/3] printk: Add force_early_printk boot param

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/3] printk: Add force_early_printk boot param Peter Zijlstra <peterz@infradead.org> - 2017-09-28 14:30 +0200
    [PATCH 3/3] early_printk: Add simple serialization to early_vprintk() Peter Zijlstra <peterz@infradead.org> - 2017-09-28 14:30 +0200
    Re: [PATCH 0/3] printk: Add force_early_printk boot param Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2017-09-28 18:10 +0200
      Re: [PATCH 0/3] printk: Add force_early_printk boot param Peter Zijlstra <peterz@infradead.org> - 2017-09-28 18:20 +0200

#1741492 — [PATCH 0/3] printk: Add force_early_printk boot param

Most all printk() bits are terminally broken because they rely on the scheduler
and blocking locks to function, making them unsuitable for debugging the
scheduler and NMI context things.

Luckily many early_printk implementations are relatively sane and don't rely on
anything much at all; the x86 early_serial_console for example is pure
bit-banging without anything.

So provide means to always use these and avoid the whole printk mess.

[toc] | [next] | [standalone]

#1741493 — [PATCH 3/3] early_printk: Add simple serialization to early_vprintk()

In order to avoid multiple CPUs banging on the serial port at the same
time, add simple serialization. This explicitly deals with nested
contexts (like IRQs etc.).

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 kernel/printk/printk.c |   35 ++++++++++++++++++++++++++++++++++-
 1 file changed, 34 insertions(+), 1 deletion(-)

--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -378,14 +378,47 @@ static int __init force_early_printk_set
 }
 early_param("force_early_printk", force_early_printk_setup);
 
+static int early_printk_cpu = -1;
+
 static int early_vprintk(const char *fmt, va_list args)
 {
+	int n, cpu, old;
 	char buf[512];
-	int n;
+
+	cpu = get_cpu();
+	/*
+	 * Test-and-Set inter-cpu spinlock with recursion.
+	 */
+	for (;;) {
+		/*
+		 * c-cas to avoid the exclusive bouncing on spin.
+		 * Depends on the memory barrier implied by cmpxchg
+		 * for ACQUIRE semantics.
+		 */
+		old = READ_ONCE(early_printk_cpu);
+		if (old == -1) {
+			old = cmpxchg(&early_printk_cpu, -1, cpu);
+			if (old == -1)
+				break;
+		}
+		/*
+		 * Allow recursion for interrupts and the like.
+		 */
+		if (old == cpu)
+			break;
+
+		cpu_relax();
+	}
 
 	n = vscnprintf(buf, sizeof(buf), fmt, args);
 	early_console->write(early_console, buf, n);
 
+	/*
+	 * Unlock -- in case @old == @cpu, this is a no-op.
+	 */
+	smp_store_release(&early_printk_cpu, old);
+	put_cpu();
+
 	return n;
 }
 

[toc] | [prev] | [next] | [standalone]

#1741675

On (09/28/17 14:18), Peter Zijlstra wrote:
> Most all printk() bits are terminally broken because they rely on the scheduler
> and blocking locks to function, making them unsuitable for debugging the
> scheduler and NMI context things.

hold on... wait a second... the scheduler is not lockless yet? darn...

ok, I think having something like that in printk.c wouldn't hurt. Petr
was going to take a look, IIRC.

but what's up with that scheduler thing I keep hearing about, must be
something new, can I disable it in kconfig? it seems to be conflicting
with CONFIG_PRINTK.

	-ss

[toc] | [prev] | [next] | [standalone]

#1741687

On Fri, Sep 29, 2017 at 01:02:30AM +0900, Sergey Senozhatsky wrote:
> but what's up with that scheduler thing I keep hearing about, must be
> something new, can I disable it in kconfig? it seems to be conflicting
> with CONFIG_PRINTK.

Its not new, its been there for a very long time :-)

The problem is that the scheduler has WARN()s in, those tend to tickle
printk(). Printk() on its own has this console semaphore that tends to
want to schedule. Console drivers have things like wakeups, which tend
to not work when you're already holding scheduler locks etc..

Its one big giant mess.. Since you removed that lockdep_off() from
printk() lockdep now sees and complains, which again hits printk(),
recursion FTW!

Similarly, since there's a metric ton of locks all over printk() and
console driver code, printk() doesn't work well from NMI context. And
the taken approach to buffering and then printing later has issues if
there is no later.

Both problems are solved by using early_printk which has lockless
drivers (x86 early_serial_console is the one I use) and avoids all
problems that way.

Its bullet proof console output. Always works. Its been very good to me.

(it of course doesn't help that I work on the scheduler and perf, the
latter of which does lots of cruft in NMI context. So I tend to run into
the very worst possible situations more than most other people)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web