linux-kernel - Re: [PATCH] [RFC]Watchdog:core: constant pinging until userspace timesout when delay very less

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 4 Jun 2013 08:39:10 +0530
From:	anish singh <anish198519851985@...il.com>
To:	Guenter Roeck <linux@...ck-us.net>, randy.dunlap@...cle.com,
	"alan@...rguk.ukuu.org.uk" <alan@...rguk.ukuu.org.uk>
Cc:	Wim Van Sebroeck <wim@...ana.be>, linux-watchdog@...r.kernel.org,
	linux-kernel-mail <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [RFC]Watchdog:core: constant pinging until userspace
 timesout when delay very less

On Tue, Jun 4, 2013 at 3:55 AM, Guenter Roeck <linux@...ck-us.net> wrote:
> On Mon, Jun 03, 2013 at 10:23:04PM +0530, anish singh wrote:
>> On Mon, Jun 3, 2013 at 8:57 PM, Guenter Roeck <linux@...ck-us.net> wrote:
>> > On Sun, Jun 02, 2013 at 03:43:07PM +0530, anish kumar wrote:
>> >> Certain watchdog drivers use a timer to keep kicking the watchdog at
>> >> a rate of 0.5s (HZ/2) untill userspace times out.They do this as
>> >> we can't guarantee that watchdog will be pinged fast enough
>> >> for all system loads, especially if timeout is configured for
>> >> less than or equal to 1 second(basically small values).
>> >>
>> >> As suggested by Wim Van Sebroeck & Guenter Roeck we should
>> >> add this functionality of individual watchdog drivers in the core
>> >> watchdog core.
>> >>
>> >> Signed-off-by: anish kumar <anish198519851985@...il.com>
>> >
>> > Not exactly what I had in mind. My idea was to enable the softdog only if
>> > the hardware watchdog's maximum timeout was low (say, less than a couple
>> > of minutes), and if a timeout larger than its maximum value was configured.
>>
>> watchdog_timeout_invalid wouldn't this check will fail if the user space tries
>> to set maximum timeout more that what driver can support?It would work
>> for pika_wdt.c as it is old watchdog driver and doesn't register with watchdog
>> framwork but new drivers has to pass this api.
>>
>> OR
>>
>> Do you want to remove this check and go as explained by you?I would
>> favour this approach though.
>>
> One would still have a check, but the enforced limits would no longer be
> the driver limits, but larger limits implemented in the watchdog core.
How much larger would be the big question here?Should it be configurable
property(sysfs?) or some hardcoding based on existing drivers?

Before going for next patch, it would be better for me to wait for some
more comments.
>
>> > In that case, I would have set the hardware watchdog to its maximum value
>> > and use the softdog to ping it at a rate of, say, 50% of this maximum.
>> >
>> > If userspace would not ping the watchdog within its configured value,
>> > I would stop pinging the hardware watchdog and let it time out.
>>
>> One more question.Why is the return value of watchdog_ping int? Anyway
>> we discard it.
>
> I can not answer that question.
>
> Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/