linux-kernel - Re: [PATCH 9/11] Panic delay fix

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: <1171493506.19842.179.camel@localhost.localdomain>
Date:	Thu, 15 Feb 2007 09:51:46 +1100
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Zachary Amsden <zach@...are.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akp=m@...l.org>, Andi Kleen <ak@....de>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Chris Wright <chrisw@...s-sol.org>,
	Alan <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH 9/11] Panic delay fix

On Mon, 2007-02-05 at 19:53 -0800, Zachary Amsden wrote:
> Failure to use real-time delay here causes the keyboard to become demonically
> possessed in the event of a kernel crash, with wildly blinking lights and
> unpredictable behavior.  This has resulted in several injuries.

The problem is the normal one when we introduce a new concept into the
kernel; there are two kinds of udelay, and they've been conflated.  The
most common case is a delay for real hardware devices; this can be
eliminated for paravirtualization.  The other cases, the tiny minority,
are visible delays (keyboard leds), not knowing if they're necessary
(very early boot), and async events (other CPUs coming up): ie.
everything else.

Is implementation of this distinction worth it?  The answer IMHO is no;
this is a case where simplicity wins.

Firstly, most modern distributions ship kernels which have almost no
drivers, and modprobe in early boot.  So assuming paravirtualized
drivers, we don't even experience the boot delays.

Secondly, the major delay for my current kernel is IDE probing (3 out of
5 seconds of boot time!), but implementing the delay ops in lguest does
*nothing* for this, because it uses "msleep()" not "mdelay()". so the
current solution isn't sufficient anyway.  If this is a real problem for
users I'd rather try to convince the IDE maintainer to use a
"real_hardware_mdelay()" or something here.

Cheers!
Rusty.
PS.  lguest doesn't implement the delay functions; I just tried
implemented that now for testing.

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