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: <d120d5000702080641p515b0226v27f208d0e685b898@mail.gmail.com>
Date:	Thu, 8 Feb 2007 09:41:03 -0500
From:	"Dmitry Torokhov" <dmitry.torokhov@...il.com>
To:	"Andi Kleen" <ak@....de>
Cc:	"Zachary Amsden" <zach@...are.com>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Andrew Morton" <akpm@...l.org>,
	"Rusty Russell" <rusty@...tcorp.com.au>,
	"Jeremy Fitzhardinge" <jeremy@...p.org>,
	"Chris Wright" <chrisw@...s-sol.org>
Subject: Re: [PATCH 9/11] Panic delay fix

On 8 Feb 2007 14:33:21 +0100, Andi Kleen <ak@....de> wrote:
> On Thu, Feb 08, 2007 at 01:08:14AM -0800, Zachary Amsden wrote:
> > Andi Kleen wrote:
> > >On Wed, Feb 07, 2007 at 02:31:57PM -0800, Zachary Amsden wrote:
> > >
> > >>Dmitry Torokhov wrote:
> > >>
> > >>>I am confused - does i8042 talk to a virtual or real hardware here? In
> > >>>any case I think you need to fix kernel/panic.c to have proper
> > >>>(m)delay, not mess with i8042.
> > >>>
> > >>I think I need to fix both of them actually.  This is virtual hardware,
> > >>but when you grab focus on a VM, the virtual hardware gets reflected to
> > >>the actual physical keyboard.  Driving physical hardware that fast is bad.
> > >>
> > >
> > >???
> > >
> > >Surely the physical keyboard is always handled by the host kernel?
> > >I hope you're not saying it's trying to access the io ports directly?
> > >
> >
> > No, not that.  But the virtual keyboard I/O gets processed and converted
> > to physical keyboard I/O when a keyboard is attached to a VM.  The
>
> You mean the commands to change the keyboard LEDs?
>
> > result is that the virtual keyboard spinning out of control causes the
> > physical keyboard to receive the same commands, far too rapidly.
>
> Hmm i would expect the host kernel keyboard driver to throttle these.
> I'm pretty sure the Linux one does the necessary mdelays at least.

There is no throttling, we will switch leds as fast as keyboard
controller will allow us (not that I consider it a bad thing).

>
> > So the keyboard blinks out of control and acts as if possessed by demons.
>
> Still sounds weird.
>

The problem is that panic blink routine expects to be called with 1ms
frequency. If mdelay in kernel/panic.c is changed to noop then i8042
will try to blink as fast as it possibly can.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ