[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <925869a6-7563-459b-b42b-b7b9b8ea0b0a@roeck-us.net>
Date: Thu, 6 Mar 2025 09:22:47 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: George Cherian <gcherian@...vell.com>
Cc: Ahmad Fatoum <a.fatoum@...gutronix.de>,
"wim@...ux-watchdog.org" <wim@...ux-watchdog.org>,
"jwerner@...omium.org" <jwerner@...omium.org>,
"evanbenn@...omium.org" <evanbenn@...omium.org>,
"krzk@...nel.org" <krzk@...nel.org>,
"mazziesaccount@...il.com" <mazziesaccount@...il.com>,
"thomas.richard@...tlin.com" <thomas.richard@...tlin.com>,
"lma@...omium.org" <lma@...omium.org>,
"bleung@...omium.org" <bleung@...omium.org>,
"support.opensource@...semi.com" <support.opensource@...semi.com>,
"shawnguo@...nel.org" <shawnguo@...nel.org>,
"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
"kernel@...gutronix.de" <kernel@...gutronix.de>,
"festevam@...il.com" <festevam@...il.com>,
"andy@...nel.org" <andy@...nel.org>,
"paul@...pouillou.net" <paul@...pouillou.net>,
"alexander.usyskin@...el.com" <alexander.usyskin@...el.com>,
"andreas.werner@....de" <andreas.werner@....de>,
"daniel@...ngy.jp" <daniel@...ngy.jp>,
"romain.perier@...il.com" <romain.perier@...il.com>,
"avifishman70@...il.com" <avifishman70@...il.com>,
"tmaimon77@...il.com" <tmaimon77@...il.com>,
"tali.perry1@...il.com" <tali.perry1@...il.com>,
"venture@...gle.com" <venture@...gle.com>,
"yuenn@...gle.com" <yuenn@...gle.com>,
"benjaminfair@...gle.com" <benjaminfair@...gle.com>,
"maddy@...ux.ibm.com" <maddy@...ux.ibm.com>,
"mpe@...erman.id.au" <mpe@...erman.id.au>,
"npiggin@...il.com" <npiggin@...il.com>,
"christophe.leroy@...roup.eu" <christophe.leroy@...roup.eu>,
"naveen@...nel.org" <naveen@...nel.org>,
"mwalle@...nel.org" <mwalle@...nel.org>,
"xingyu.wu@...rfivetech.com" <xingyu.wu@...rfivetech.com>,
"ziv.xu@...rfivetech.com" <ziv.xu@...rfivetech.com>,
"hayashi.kunihiko@...ionext.com" <hayashi.kunihiko@...ionext.com>,
"mhiramat@...nel.org" <mhiramat@...nel.org>,
"linux-watchdog@...r.kernel.org" <linux-watchdog@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
"chrome-platform@...ts.linux.dev" <chrome-platform@...ts.linux.dev>,
"imx@...ts.linux.dev" <imx@...ts.linux.dev>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
"openbmc@...ts.ozlabs.org" <openbmc@...ts.ozlabs.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"patches@...nsource.cirrus.com" <patches@...nsource.cirrus.com>,
Marek BehĂșn <kabel@...nel.org>
Subject: Re: [EXTERNAL] Re: [PATCH v4 1/2] watchdog: Add a new flag
WDIOF_STOP_MAYSLEEP
On Thu, Mar 06, 2025 at 12:18:20PM +0000, George Cherian wrote:
> Hi Guenter,
>
> I am summarizing the topics we discussed in multiple threads here.
>
> >>On 3/5/25 03:01, Ahmad Fatoum wrote:
> >> Hi George,
> >> Hi Guenter,
> >>
> >> On 05.03.25 11:34, George Cherian wrote:
> >>>> why is armada_37xx_wdt also here?
> >>>> The stop function in that driver may not sleep.
> >>> Marek,
> >>>
> >>> Thanks for reviewing.
> >>> Since the stop function has a regmap_write(), I thought it might sleep.
> >>> Now that you pointed it out, I assume that it is an MMIO based regmap being used for armada.
> >>> I will update the same in the next version
> >>
> >> Failure to add WDIOF_STOP_MAYSLEEP when it's needed can lead to
> >> kernel hanging. Failure to add an alternative WDIOF_STOP_ATOMIC
> >> would lead to the kernel option being a no-op.
> >>
> >> I think a no-op stop_on_panic (or reset_on_panic) is a saner default.
> >>
> >
> >Agreed. Also, I like WDIOF_STOP_ATOMIC more than the WDIOF_STOP_NOSLEEP
> >I had suggested in my other response.
>
> 1. Instead of blacklisting drivers as WDIOF_STOP_MAYSLEEP, the option will an opt-in.
> 2. This may not be WDIOF_STOP_AOMIC, instead would be a generic flag not limited to STOP
> operation. May be WDIOF_OPS_ATOMIC (OPS include - .start, .stop, .set_timeout, .ping)
I don't see a value in this because AFAICS atomic operation is only needed when
stopping the watchdog. At least in theory, some watchdogs might need to sleep
for other functions, but not for the stop operation. Please provide a rationale.
> 3. Remove the kernel command line option (stop_on_panic) and have a generic reset_on_panic.
> 4. reset_on_panic=60 (by default ) meaning on a panic the wdog timeout is updated to 60sec
> or the clamp_t(reset_on_panic, min, max_hw_heartbeat_ms).
Default should be the current behavior, that the watchdog keeps running with the
configured timeout.
> 5. if reset_on_panic=0, it means the watchdog is stopped on panic.
If we need both a panic timeout and the ability to disable the watchdog entirely
on panic, there should be two parameters - one to select the watchdog timeout
on panic, and one to disable the watchdog entirely on panic. If there is only
one parameter, it should be the watchdog timeout on panic, with ==0 meaning
"keep the configured timeout" (i.e., the current behavior).
Thanks,
Guenter
Powered by blists - more mailing lists