linux-kernel - Re: [PATCH] x86_64 kexec: Remove experimental mark of kexec

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 07 Sep 2006 18:54:00 -0700
From:	Piet Delaney <piet@...elane.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Piet Delaney <piet@...elane.com>, Andi Kleen <ak@...e.de>,
	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
	fastboot@...l.org
Subject: Re: [PATCH] x86_64 kexec: Remove experimental mark of kexec

On Thu, 2006-09-07 at 00:55 -0600, Eric W. Biederman wrote:
> Piet Delaney <piet@...elane.com> writes:
> 
> > On Wed, 2006-09-06 at 14:15 -0600, Eric W. Biederman wrote:
> >> Andi Kleen <ak@...e.de> writes:
> >> 
> >> > On Wednesday 06 September 2006 18:55, Eric W. Biederman wrote:
> >> >> 
> >> >> kexec has been marked experimental for a year now and all
> >> >> of the serious problems have been worked through.  So it
> >> >> is time (if not past time) to remove the experimental mark.
> >> >> 
> >> >
> >> > Hmm, I personally have some doubts it is really not experimental
> >> > (not because of the kexec code itself, but because of all the other drivers
> >> > that still break)
> >> 
> >> That is a reasonable viewpoint.  Although by that a lot more of the kernel
> >> deserves to be marked experimental. 
> >> 
> >> On the perverse side of the sentiment taking off experimental may increase
> >> our number of testers and get the bugs fixed faster :)
> >
> > I take it that for using kexec to boot a kdump kernel and then
> > rebooting the primary kernel that there are a few drivers in
> > the dumping kernel that wouldn't work but they aren't likely
> > to be used. Ie: it's "just" a hardware initialization issue
> > on kernels booted with kexec.
> 
> Yes.  The only place you are likely to observe the driver
> initialization problems are kernels booted with kexec.  But there
> are other rare scenarios that can yield challenging boot driver
> initialization scenarios.   I know soft booting from windows used
> to be one of them.
> 
> As for the kdump kernel usually you won't load (or build in) any
> drivers you don't intend to use.  If the drivers actually get loaded
> even if you aren't using them you could have problems.

Thanks for the tip, I'll make sure my dumping kernel only
has drivers necessary to make the kernel core file configured.

-piet

> 
> Eric
-- 
Piet Delaney                                    Phone: (408) 200-5256
Blue Lane Technologies                          Fax:   (408) 200-5299
10450 Bubb Rd.
Cupertino, Ca. 95014                            Email: piet@...elane.com

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)