From: Thomas Gleixner <hidden> Date: 2017-10-02 18:46:32
On Sun, 1 Oct 2017, Linus Torvalds wrote:
So get rid of that kind of shit, and I may reconsider. But as is, I
look at that patch and say "no, this is worse than the garbage it used
to be".
I agree that adding that 'run' argument was certainly not a piece of
art. Though I disagree with the sentiment that non-functional garbage is
preferrable over functionally correct code which merily contains a bad
implementation choice. Without knowing you for years, it would certainly
seem more rewarding to dump garbage and get it merged, than caring and
mopping up garbage, which should not have been merged in the first
place. Your motivation skills are truly outstanding.
Enough vented. Find below the cure for that major offense.
Thanks,
tglx
8<--------------------
Subject: watchdog/core, powerpc: Replace watchdog_nmi_reconfigure()
From: Thomas Gleixner <redacted>
Date: Mon, 02 Oct 2017 12:34:50 +0200
The recent cleanup of the watchdog code split watchdog_nmi_reconfigure()
into two stages. One to stop the NMI and one to restart it after
reconfiguration. That was done by adding a boolean 'run' argument to the
function, which is functionally correct but not necessarily a piece of art.
Replace it by two explicit functions: watchdog_nmi_stop() and
watchdog_nmi_start().
Fixes: 6592ad2fcc8f ("watchdog/core, powerpc: Make watchdog_nmi_reconfigure() two stage")
Requested-by: Linus 'Nursing his pet-peeve' Torvalds [off-list ref]
Signed-off-by: Thomas 'Mopping up garbage' Gleixner <redacted>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/kernel/watchdog.c | 23 ++++++++++++++---------
include/linux/nmi.h | 3 ++-
kernel/watchdog.c | 33 ++++++++++++++++++---------------
3 files changed, 34 insertions(+), 25 deletions(-)
On Mon, Oct 2, 2017 at 11:46 AM, Thomas Gleixner [off-list ref] wrote:
I agree that adding that 'run' argument was certainly not a piece of
art. Though I disagree with the sentiment that non-functional garbage is
preferrable over functionally correct code which merily contains a bad
implementation choice.
I agree that it's somewhat arbitrary, but I also find it really hard
to vet code where my initial reaction is just "this is too ugly".
So it may be superficial, but ..
Enough vented. Find below the cure for that major offense.
Looks much better to me. Thanks.
Side note: would it perhaps make sense to have that
cpus_read_lock/unlock() sequence around the whole reconfiguration
section?
Because while looking at that sequence, it looks a bit odd to me that
cpu's can come and go in the middle of the nmi watchdog
reconfiguration sequence.
In particular, what happens if a new CPU is brought up just as the NMI
matchdog is being reconfigured? The NMI's have been stopped for the
old CPU's, what happens for the new one that came up in between that
watchdog_nmi_stop/start?
This may be all obviously safe, I'm just asking for clarification.
Linus
From: Thomas Gleixner <hidden> Date: 2017-10-02 19:33:02
On Mon, 2 Oct 2017, Linus Torvalds wrote:
Side note: would it perhaps make sense to have that
cpus_read_lock/unlock() sequence around the whole reconfiguration
section?
Because while looking at that sequence, it looks a bit odd to me that
cpu's can come and go in the middle of the nmi watchdog
reconfiguration sequence.
In particular, what happens if a new CPU is brought up just as the NMI
matchdog is being reconfigured? The NMI's have been stopped for the
old CPU's, what happens for the new one that came up in between that
watchdog_nmi_stop/start?
This may be all obviously safe, I'm just asking for clarification.
It's safe because the newly upcoming CPU will see an empty enabled mask in
the powerpc implementation. The perf based implementation has a similar
protection.
Though yes, it would be more obvious to expand the cpus locked
section. That requires a bit of shuffling. Untested patch below.
Thanks,
tglx
8<------------------
@@ -351,7 +351,7 @@ void smpboot_update_cpumask_percpu_threastaticstructcpumasktmp;unsignedintcpu;-get_online_cpus();+lockdep_assert_cpus_held();mutex_lock(&smpboot_threads_lock);/* Park threads that were exclusively enabled on the old mask. */
From: Don Zickus <hidden> Date: 2017-10-02 20:32:12
On Mon, Oct 02, 2017 at 07:32:57PM +0000, Thomas Gleixner wrote:
quoted hunk
On Mon, 2 Oct 2017, Linus Torvalds wrote:
quoted
Side note: would it perhaps make sense to have that
cpus_read_lock/unlock() sequence around the whole reconfiguration
section?
Because while looking at that sequence, it looks a bit odd to me that
cpu's can come and go in the middle of the nmi watchdog
reconfiguration sequence.
In particular, what happens if a new CPU is brought up just as the NMI
matchdog is being reconfigured? The NMI's have been stopped for the
old CPU's, what happens for the new one that came up in between that
watchdog_nmi_stop/start?
This may be all obviously safe, I'm just asking for clarification.
It's safe because the newly upcoming CPU will see an empty enabled mask in
the powerpc implementation. The perf based implementation has a similar
protection.
Though yes, it would be more obvious to expand the cpus locked
section. That requires a bit of shuffling. Untested patch below.
Thanks,
tglx
8<------------------
@@ -351,7 +351,7 @@ void smpboot_update_cpumask_percpu_threastaticstructcpumasktmp;unsignedintcpu;-get_online_cpus();+lockdep_assert_cpus_held();mutex_lock(&smpboot_threads_lock);/* Park threads that were exclusively enabled on the old mask. */
@@ -561,6 +561,12 @@ static void softlockup_reconfigure_threa if (watchdog_enabled && watchdog_thresh) softlockup_unpark_threads(); watchdog_nmi_start();+ cpus_read_unlock();+ /*+ * Must be called outside the cpus locked section to prevent+ * recursive locking in the perf code.+ */+ __lockup_detector_cleanup(); } /*
From: Thomas Gleixner <hidden> Date: 2017-10-02 20:45:12
On Mon, 2 Oct 2017, Don Zickus wrote:
On Mon, Oct 02, 2017 at 07:32:57PM +0000, Thomas Gleixner wrote:
quoted
static void softlockup_reconfigure_threads(void)
There is a second copy of ^^^^, you will need to add identical locking there
too.
Good catch, but then we might move it further out
quoted
+ cpus_read_unlock();
+ /*
+ * Must be called outside the cpus locked section to prevent
+ * recursive locking in the perf code.
+ */
+ __lockup_detector_cleanup();