[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1477054235-1624-1-git-send-email-pmladek@suse.com>
Date: Fri, 21 Oct 2016 14:50:33 +0200
From: Petr Mladek <pmladek@...e.com>
To: Jason Wessel <jason.wessel@...driver.com>
Cc: Daniel Thompson <daniel.thompson@...aro.org>,
Peter Zijlstra <peterz@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
linux-kernel@...r.kernel.org, Petr Mladek <pmladek@...e.com>
Subject: [PATCH 0/2] kdb: Fix locking in vkdb_printf()
I have been asked whether it is safe to call vkdb_printf() from
vprintk_nmi() in NMI context. It seems that it is not safe.
Well, is not a big deal.
But I have noticed suspicious patterns when looking at the
vkdb_printf() locking code and prepared two patches that
should avoid some possible races.
Please, note that I am not familiar with the kdb implementation.
I hope that I have got the requested behavior right. I did
some basic testing and did not found any problem. But I am sure
that I did not test all usecases.
Petr Mladek (2):
kdb: Properly synchronize vkdb_printf() calls with other CPUs
kdb: Call vkdb_printf() from vprintk_default() only when wanted
include/linux/kdb.h | 1 +
kernel/debug/kdb/kdb_io.c | 41 +++++++++++++++++------------------------
kernel/debug/kdb/kdb_private.h | 1 -
kernel/printk/printk.c | 4 +++-
4 files changed, 21 insertions(+), 26 deletions(-)
--
1.8.5.6
Powered by blists - more mailing lists