linux-kernel - Re: [PATCH v4] 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]

Message-ID: <20100622203317.GA7401@core.coreip.homeip.net>
Date:	Tue, 22 Jun 2010 13:33:17 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	TAMUKI Shoichi <tamuki@...et.gr.jp>, Ingo Molnar <mingo@...e.hu>,
	Anton Blanchard <anton@...ba.org>,
	Andi Kleen <andi@...stfloor.org>,
	Andy Green <andy@...mcat.com>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] panic: keep blinking in spite of long spin timer mode

On Tue, Jun 22, 2010 at 01:16:54PM -0700, Andrew Morton wrote:
> On Mon, 21 Jun 2010 07:52:24 +0900
> TAMUKI Shoichi <tamuki@...et.gr.jp> 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 the problem is the keyboard
> > LEDs don't blink at all on that situation.
> > 
> > This patch changes to call to panic_blink_enter() between every mdelay
> > and keeps blinking in spite of long spin timer mode.
> > 
> > The time to call to mdelay is now 100ms.  Even this change will keep
> > panic_timeout accuracy enough when running under a hypervisor.
> > 
> 
> Thaks for sticking with it - I think the code's a lot better now.  Are
> you happy with it?
> 
> > ---
> >  Changes since v3:
> >  - get rid of CONFIG_PANIC_LONGSPIN_TIMER kernel config option
> > 
> >  Documentation/kernel-parameters.txt |    3 -
> >  arch/arm/mach-s3c2440/mach-gta02.c  |   17 ++-----
> >  drivers/input/serio/i8042.c         |   25 ++---------
> >  include/linux/kernel.h              |    2 
> >  kernel/panic.c                      |   58 +++++++++++---------------
> >  5 files changed, 37 insertions(+), 68 deletions(-)
> 
> And isn't that a nice sight.
> 
> > --- a/drivers/input/serio/i8042.c
> > +++ b/drivers/input/serio/i8042.c
> 
> Dmitry, I think drivers/input/serio/i8042.c is buggy.  It does
> 
> 	panic_blink = NULL;
> 
> as the very last thing on module exit.  However it surely should do
> this at least at the _start_ of i8042_exit() and I suspect it really
> should be doing this at the start of i8042_shutdown()?
> 
> As things stand, a well-timed panic will end up trying to flash LEDs
> via hardware which has been "shut down".
> 

Andrew,

i8042_panic_blink() is designed to work standalone, without any support
from the rest of i8042 infrastructure - becase it is called during panic
it does not rely on interrupt handlers, locks or anything else so it
really does not matter at what point during driver removal we would
replace the handler. That said, if we were to move it upward so it is
symmetrical with the order in i8042_init() that'd be fine too.

BTW, changes to i8042 looks good, so:

	Acked-by: Dmitry Torokhov <dtor@...l.ru>

Thanks.

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