linux-kernel - Re: [PATCH] Watchdog: add pretimeout

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] [day] [month] [year] [list]

Date:	Mon, 22 Apr 2013 18:45:48 -0400
From:	Jörn Engel <joern@...fs.org>
To:	Guenter Roeck <linux@...ck-us.net>
Cc:	Alan Cox <alan@...ux.intel.com>,
	Hans de Goede <hdegoede@...hat.com>,
	Wim Van Sebroeck <wim@...ana.be>,
	linux-kernel@...r.kernel.org, linux-watchdog@...r.kernel.org
Subject: Re: [PATCH] Watchdog: add pretimeout

On Mon, 22 April 2013 16:26:13 -0700, Guenter Roeck wrote:
> On Mon, Apr 22, 2013 at 05:38:39PM -0400, Jörn Engel wrote:
> > On Mon, 22 April 2013 15:42:03 -0700, Guenter Roeck wrote:
> > 
> > The counter-argument is that applications have to opt-in by setting a
> > pretimeout.  Although I have to admit to not testing applications that
> > don't opt-in.
> > 
> Still, how does the application distinguish SIGINT (real from SIGINT (watchdog) ?

It cannot.  I picked SIGILL based on "this couldn't ever matter to
us", but when using instructions for modern cpus on older cpus it
actually does.  So whatever signal you pick, you always pick wrong.
Which is why you should have commented on the two paragraphs below
instead. ;)

> > Udev sounds like a bad idea, as that usually means spawning a number
> > of shell scripts and is more likely to get lost in realtime systems or
> > similar.  Polling on a file descriptor would make sense.
> > 
> > I would be fine with removing the notification for now and have
> > someone else add a proper interface as time permits.  Someone else may
> > well be a future version of me.
> > 
> > > Also, I think there should be a callback into the watchdog drivers.
> > > There are watchdogs out there implementing a pre-timeout in hardware,
> > > and the watchdog code could make use of that functionality.
> > 
> > Sounds like a good idea in principle, but I can see few advantages in
> > reality.  The code gets slightly more complex, test coverage is
> > divided between platforms and it only matters if kernel timers are
> > somehow borked.  Not sure if you have a strong argument in favor.
> > 
> I am currently dealing with a watchdog which does support pre-timeouts.
> It would seem odd to me if the core watchdog API would support pre-timeouts,
> but not the pre-timeouts supported by the actual watchdog driver.

Agreed.  However the pretimeout gets generated and delivered to the
kernel, the userspace ABI should be identical.  Currently that covers
the ipmi_watchdog and my patch.

Neat.  Ipmi already has the poll interface.  So what we should be
doing is generalize it from the ipmi driver.  I will see if I can
sneak off into a dark corner and do so before $BOSS notices.

Jörn

--
Linux is more the core point of a concept that surrounds "open source"
which, in turn, is based on a false concept. This concept is that
people actually want to look at source code.
-- Rob Enderle
--
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/