[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZHYOmkZBxd4TiTv-@alley>
Date: Tue, 30 May 2023 16:56:26 +0200
From: Petr Mladek <pmladek@...e.com>
To: Douglas Anderson <dianders@...omium.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
kgdb-bugreport@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
Nicholas Piggin <npiggin@...il.com>,
Michael Ellerman <mpe@...erman.id.au>,
linuxppc-dev@...ts.ozlabs.org,
Christophe Leroy <christophe.leroy@...roup.eu>,
sparclinux@...r.kernel.org,
"David S . Miller" <davem@...emloft.net>,
linux-perf-users@...r.kernel.org
Subject: Re: [PATCH 06/10] watchdog/buddy: Cleanup how
watchdog_buddy_check_hardlockup() is called
On Fri 2023-05-26 18:41:36, Douglas Anderson wrote:
> In the patch ("watchdog/hardlockup: detect hard lockups using
> secondary (buddy) CPUs"), we added a call from the common watchdog.c
> file into the buddy. That call could be done more cleanly.
> Specifically:
> 1. If we move the call into watchdog_hardlockup_kick() then it keeps
> watchdog_timer_fn() simpler.
> 2. We don't need to pass an "unsigned long" to the buddy for the timer
> count. In the patch ("watchdog/hardlockup: add a "cpu" param to
> watchdog_hardlockup_check()") the count was changed to "atomic_t"
> which is backed by an int, so we should match types.
>
> Suggested-by: Petr Mladek <pmladek@...e.com>
> Signed-off-by: Douglas Anderson <dianders@...omium.org>
The change looks fine:
Reviewed-by: Petr Mladek <pmladek@...e.com>
That said, I would prefer to squash it into the patch ("watchdog/hardlockup:
detect hard lockups using secondary (buddy) CPUs"). It would remove
some back and forth churn in the git history. But it is up to Andrew.
Best Regards,
Petr
Powered by blists - more mailing lists