linux-kernel - Re: [PATCH v4 5/7] Watchdog: introduce ARM SBSA watchdog driver

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

Message-ID: <7870088.TdP6RHCoCB@wuerfel>
Date:	Wed, 03 Jun 2015 21:29:12 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Timur Tabi <timur@...eaurora.org>
Cc:	Guenter Roeck <linux@...ck-us.net>, fu.wei@...aro.org,
	Suravee.Suthikulpanit@....com, linaro-acpi@...ts.linaro.org,
	linux-watchdog@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
	tekkamanninja@...il.com, graeme.gregory@...aro.org,
	al.stone@...aro.org, hanjun.guo@...aro.org,
	ashwin.chaugule@...aro.org, vgandhi@...eaurora.org, wim@...ana.be,
	jcm@...hat.com, leo.duran@....com, corbet@....net,
	mark.rutland@....com, catalin.marinas@....com, will.deacon@....com,
	rjw@...ysocki.net
Subject: Re: [PATCH v4 5/7] Watchdog: introduce ARM SBSA watchdog driver

On Wednesday 03 June 2015 13:53:29 Timur Tabi wrote:
> On 06/03/2015 01:25 PM, Guenter Roeck wrote:
> > In general the idea here would be to use a crashdump kernel, which,
> > when loaded, would reset the watchdog before it fires. This kernel
> > would then write a core dump to a specified location.
> 
> What is the mechanism for resetting the watchdog?  The only code that 
> knows about the hardware registers is this driver.  Does the crashdump 
> kernel call the watchdog stop function?

It might or might not, depending on what you want to achieve. In most
cases, I'd expect the crashdump kernel to have it enabled if we want
to let the user set a pretimeout, but that is a policy question that
is not for the kernel to decide.

> > If arm64 doesn't support a crashdump kernel, it might still be possible
> > to log the backtrace somewhere (eg in nvram using pstore if that is
> > supported via acpi or efi).
> 
> I think it's expected that the firmware support a crash dump mechanism 
> of some kind.  But if we're talking about firmware support, then why 
> bother with the panic() in the first place?

panic() is what triggers all the crash dump or pstore mechanisms, it
has to do that anyway.

> > Is there reason to believe that this all won't work on arm64 ?
> 
> No, but I'm still trying to figure out why pre-timeout is valuable.  If 
> we don't disable WS1, then we risk having the hardware reset before we 
> can take advantage of what the panic() offers.  In which case, what's 
> the point of pre-timeout?

The timeouts are both configurable, so the sysadmin has to make sure that
the time between them is long enough to do whatever is necessary.

	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/