[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200326163245.119670-1-jannh@google.com>
Date: Thu, 26 Mar 2020 17:32:43 +0100
From: Jann Horn <jannh@...gle.com>
To: Peter Zijlstra <peterz@...radead.org>,
Petr Mladek <pmladek@...e.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Cc: linux-kernel@...r.kernel.org, Dennis Zhou <dennis@...nel.org>,
Tejun Heo <tj@...nel.org>, Christoph Lameter <cl@...ux.com>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Gleixner <tglx@...utronix.de>,
Frederic Weisbecker <frederic@...nel.org>
Subject: [PATCH 0/2] Make printk_deferred() work properly before percpu setup
is done
While I was doing some development work, I noticed that if you call
printk_deferred() before percpu setup has finished, stuff breaks, and
e.g. "dmesg -w" fails to print new messages.
This happens because writing to percpu memory before percpu
initialization is done causes the modified percpu memory to be
propagated from the boot CPU to all the secondary CPUs; and both the
printk code as well as the irq_work implementation use percpu memory.
I think that printk_deferred() ought to work even before percpu
initialization, since it is used by things like pr_warn_ratelimited()
and the unwinder infrastructure. I'm not entirely sure though whether
this is the best way to implement that, or whether it would be better to
let printk_deferred() do something different if it is called during
early boot.
Jann Horn (2):
irq_work: Reinitialize list heads for secondary CPUs
printk: Reinitialize klogd percpu state for secondary CPUs
kernel/irq_work.c | 22 ++++++++++++++++++++++
kernel/printk/printk.c | 23 +++++++++++++++++++++++
2 files changed, 45 insertions(+)
base-commit: 76ccd234269bd05debdbc12c96eafe62dd9a6180
--
2.25.1.696.g5e7596f4ac-goog
Powered by blists - more mailing lists