linux-kernel - Re: [PATCH] panic: keep blinking in spite of long spin timer mode

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]

Date:	Sat, 29 May 2010 07:11:06 +0900
From:	TAMUKI Shoichi <tamuki@...et.gr.jp>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Anton Blanchard <anton@...ba.org>,
	Andy Green <andy@...mcat.com>,
	TAMUKI Shoichi <tamuki@...et.gr.jp>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] panic: keep blinking in spite of long spin timer mode

Hello,

On Fri, May 28, 2010 at 11:13:54 +0200, Andi Kleen wrote:
> > To keep panic_timeout accuracy when running under a hypervisor, the
> > current implementation only spins on long time (1 second) calls to
> > mdelay.  That brings a good effect, but we must give up blinking even
> > if we have a panic_blink.
> > 
> > This patch keeps blinking in spite of long spin timer mode.
> > 
> > We now have new kernel parameter (panic_longspin) to enable long spin
> > timer mode when kernel panics.  This is to be used when running under
> > a hypervisor (default is disable).
> 
> Sorry I didn't understand the problem based on your description.
> 
> What exactly is the problem with the current code under your
> hypervisor?
> 
> New parameters for this are probably not the right answer,
> who would figure out when to set them.

Sorry for my poor explanation.

As Anton Blanchard wrote, who posted "[PATCH] panic: Fix panic_timeout
accuracy when running on a hypervisor", he had had some complaints
about panic_timeout being wildly innacurate on shared processor PowerPC
partitions (a 3 minute panic_timeout taking 30 minutes).

The fact is we loop on mdelay(1) and with a 1ms in 10ms hypervisor
timeslice each of these will take 10ms (i.e. 10x) longer.  To avoid
this, it had been changed to do 1 second mdelays if we don't have a
panic_blink.

The problem is the keyboard LEDs don't blink at all on that situation.

Therefore, I changed to call panic_blink_enter() between every mdelay.
The default time calls to mdelay is 1ms.  If the kernel parameter
panic_longspin is set to true, it will be switched to 240ms and the
maximum speed of blinking will be automatically limited slower due to
the granularity of the blinking time.

It is complicated to change the speed of panic blink that the indi-
vidual drivers do.

This is the reason why the place to control blinking has been moved
from panic_blink() (i.e. gta02_panic_blink() or i8042_panic_blink()
for now) to panic_blink_enter().

Regards,
TAMUKI Shoichi
--
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/