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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <201106242314.37119.arnd@arndb.de>
Date:	Fri, 24 Jun 2011 23:14:36 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Wim Van Sebroeck <wim@...ana.be>
Cc:	Mark Lord <kernel@...savvy.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux Watchdog Mailing List <linux-watchdog@...r.kernel.org>
Subject: Re: [PATCH 7/10 v2] Generic Watchdog Timer Driver

On Friday 24 June 2011, Wim Van Sebroeck wrote:
> > > > This is another tricky thing were developers will always discuss about.
> > > > What you don't want to happen is that the watchdog reboots your system when it does
> > > > an fsck at bootup (for instance because the system rebooted by the watchdog and left
> > > > the filesystem in a dirty state...).
> > > > 
> > > > So it's more complex if you look at the overal system...
> > > 
> > > Sure, but that's got little to do with wanting a kernel parameter to OPTIONALLY
> > > enable a hardware watchdog timer at boot.
> > > 
> > > Filesystem checks are a separate issue, easily worked around in practice.
> > 
> > I agree, it's nice to give system integrators the option to enable the watchdog
> > very early, the problems that Wim mentioned need to be solved in user space
> > but are not a serious limitation.
> 
> I'm definitely not against it and I am sure that we all agree that this is a valid
> option for some drivers (certainly in embedded environments). But for me it has to
> stay an option.

I certainly wouldn't make it the default to enable watchdogs on boot, but having
a generic command line argument in the core seems more appropriate to me than
doing it in the drivers, which would require knowing which driver is responsible.

> FYI: We allready have one driver that does this: w83697hf_wdt.c See commit
> 6fd656012bb8d5c5a4570adc2e630668b0109cb0.

This one is somewhat different because the watchdog is already enabled in
this case on bootup, and the command line option tells the driver not
to disable it if it's already on. I can also see why that may be useful,
but an option to enable it independent of its current state would be more
logical to other drivers that always come up disabled.

Anyway, it's certainly not an important functionality to have, and getting
your patches merged shouldn't wait for it.

	Arnd
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ