linux-kernel - Re: [PATCH 2/2] Kexec jump: Kexec jump

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] [day] [month] [year] [list]

Message-Id: <1184360611.1069.23.camel@caritas-dev.intel.com>
Date:	Fri, 13 Jul 2007 21:03:31 +0000
From:	"Huang, Ying" <ying.huang@...el.com>
To:	Pavel Machek <pavel@....cz>
Cc:	nigel@...el.suspend2.net, "Rafael J. Wysocki" <rjw@...k.pl>,
	Jeremy Maitin-Shepard <jbms@....edu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org
Subject: Re: [PATCH 2/2] Kexec jump: Kexec jump

On Thu, 2007-07-12 at 11:42 +0200, Pavel Machek wrote:
> > This patch provide the kexec based implementation of hibernation image
> > operation. Now, only jumping between original kernel and kexeced
> > kernel is supported, real image write/read/check will be provided in
> > next patches.
> 
> I'd prefer this not to use hibernation hooks... existing dumping
> infrastructure should be good enough to write resume image, no?
> 
> BTW... is this able to do kdump, then return back to the old kernel?
> That seems to be similar functionality to hibernation, and I was told
> it would be very welcome.

Yes. Just because there are so much similarity between them, many people
think they can be merged.

> > +static int kexec_suspend(void)
> > +{
> > +	int error;
> > +
> > +	local_irq_disable();
> > +	/* At this point, device_suspend() has been called, but *not*
> > +	 * device_power_down(). We *must* device_power_down() now.
> > +	 * Otherwise, drivers for some devices (e.g. interrupt controllers)
> > +	 * become desynchronized with the actual state of the hardware
> > +	 * at resume time, and evil weirdness ensues.
> > +	 */
> > +	error = device_power_down(PMSG_FREEZE);
> > +	if (error) {
> > +		printk(KERN_ERR "Some devices failed to power down, aborting suspend\n");
> > +		goto Enable_irqs;
> > +	}
> > +
> > +	save_processor_state();
> > +	error = kexec_jump(KEXEC_JUMP_TYPE_EXEC);
> > +	restore_processor_state();
> > +
> > +	/* NOTE:  device_power_up() is just a resume() for devices
> > +	 * that suspended with irqs off ... no overall powerup.
> > +	 */
> > +	device_power_up();
> > + Enable_irqs:
> > +	in_suspend = 0;
> > +	local_irq_enable();
> > +	return error;
> > +}
> ...
> > +static int kexec_resume(void)
> > +{
> > +	int error = 0;
> > +
> > +	local_irq_disable();
> > +	/* NOTE:  device_power_down() is just a suspend() with irqs off;
> > +	 * it has no special "power things down" semantics
> > +	 */
> > +	if (device_power_down(PMSG_PRETHAW))
> > +		printk(KERN_ERR "Some devices failed to power down, very bad\n");
> > +	/* We'll ignore saved state, but this gets preempt count (etc) right */
> > +	save_processor_state();
> > +	kexec_restore_backup();
> > +	error = kexec_jump(KEXEC_JUMP_TYPE_JUMP);
> > +	swsusp_free();
> > +	restore_processor_state();
> > +	touch_softlockup_watchdog();
> > +	device_power_up();
> > +	local_irq_enable();
> > +	return error;
> > +}
> 
> This seems like mostly generic stuff for going between two kernels,
> no? I'd prefer it not be hooked into hibernation infrastructure.

Yes. In fact, with device_suspend(...), disable_nonboot_cpus() and
enable_nonboot_cpus(), device_resume(...) around the above two
functions, the jumping between normal kernel and kexeced kernel can work
too. Maybe it is more approriate not to hook the kexec into current
hibernation. It seems that there are no much code shared between them
except device/CPU state quiescent/save/restore.

Best Regards,
Huang Ying
-
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/