All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luiz Capitulino (Red Hat)" <luiz.capitulino@linux.dev>
To: Michael Ellerman <mpe@tenstorrent.com>,
	maddy@linux.ibm.com, npiggin@gmail.com,
	linuxppc-dev@lists.ozlabs.org
Cc: chleroy@kernel.org, ritesh.list@gmail.com, sshegde@linux.ibm.com,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] powerpc/watchdog: disable watchdog when watchdog_thresh=0
Date: Fri, 6 Nov 2026 10:13:26 -0500	[thread overview]
Message-ID: <cb06b1b9-fed4-4071-964d-90ae44803440@linux.dev> (raw)
In-Reply-To: <9fada7bf-11b5-45b6-858d-4c6b79d6a507@kernel.org>



On 11/6/26 5:26 AM, Michael Ellerman wrote:
> On 4/11/26 2:40 pm, Luiz Capitulino (Red Hat) wrote:
>> On powerpc, trying to disable the hardlockup detector with:
>>
>>   # echo 0 > /proc/sys/kernel/watchdog_thresh
>>
>> causes an immediate and endless hardlockup detection, eventually leading
>> to an unusable system (splat example below).
> 
> ...
>> This condition is already checked in __lockup_detector_reconfigure() for
>> the soft lockup detector and the arch-independent hardlockup detector,
>> what's missing is powerpc performing the same check in start_watchdog().
> 
> Arguably setting watchdog_thresh to 0 should mean watchdog_enabled becomes false.
> Then there wouldn't need to be extra checks for thresh == 0 anywhere.
> 
> But if the existing code already checks for thresh == 0 then this is fine.

Yes, the common code in kernel/watchdog.c actually checks for both.

Thanks for the review.

> 
>> Fixes: 2104180a5369 ("powerpc/64s: implement arch-specific hardlockup watchdog")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Luiz Capitulino (Red Hat) <luiz.capitulino@linux.dev>
>> ---
>> Notes:
>> - This issue was not discovered by AI. We have a new test-case in our CI that
>>    sets watchdog_thresh=0, when running on powerpc we get the described issue
>> - This issue was initially reproduced on Power10, but I developed the fix
>>    on Power9 (which is what I have access now)
>>
>>   arch/powerpc/kernel/watchdog.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/powerpc/kernel/watchdog.c b/arch/powerpc/kernel/watchdog.c
>> index 582ee3fd71c1..44f178e07531 100644
>> --- a/arch/powerpc/kernel/watchdog.c
>> +++ b/arch/powerpc/kernel/watchdog.c
>> @@ -487,6 +487,9 @@ static void start_watchdog(void *arg)
>>       if (!(watchdog_enabled & WATCHDOG_HARDLOCKUP_ENABLED))
>>           return;
>> +    if (!watchdog_thresh)
>> +        return;
>> +
>>       if (!cpumask_test_cpu(cpu, &watchdog_cpumask))
>>           return;
> 
> 
> Fix looks good to me.
> 
> Reviewed-by: Michael Ellerman <mpe@kernel.org>
> 
> cheers


      reply	other threads:[~2026-11-06 15:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-04  3:40 [PATCH] powerpc/watchdog: disable watchdog when watchdog_thresh=0 Luiz Capitulino (Red Hat)
2026-11-06 10:26 ` Michael Ellerman
2026-11-06 15:13   ` Luiz Capitulino (Red Hat) [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cb06b1b9-fed4-4071-964d-90ae44803440@linux.dev \
    --to=luiz.capitulino@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=chleroy@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=mpe@tenstorrent.com \
    --cc=npiggin@gmail.com \
    --cc=ritesh.list@gmail.com \
    --cc=sshegde@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.