Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
The Extensible Firmware Interface - an introduction
Posted Aug 15, 2011 17:58 UTC (Mon) by knobunc (subscriber, #4678)
Posted Aug 23, 2011 10:22 UTC (Tue) by etienne (subscriber, #25256)
Let's imagine yesterday kernel managing yesterday device.
That yesterday device has some configuration bits labelled "do not touch", i.e. bits that you should write to the same value that you read them.
Having "do not touch" bits in configuration words is a usual way to plan for extensibility, those bits are currently zero, but in future (backward compatible) version of the device they may have a meaning, like enabling the super-duper new function.
So yesterday kernel behaves perfectly well, preserving the value of the "do not touch" bits, and obviously do not have the driver of the super-duper function.
Back to today, I have currently booted the today kernel, which knows how to drive the super-duper function, and because it has recognised the more powerful today's device, it has enabled the super-duper function in the device by setting the previously "do not touch" bit (now enable super-duper function bit) to the device register.
Now, if I kexec yesterday's kernel, it will not change the "do not touch" bit, but it does not have the super-duper function driver neither.
I am not saying this pattern happens often, I am not saying the system will always misbehave, I am just saying there is a risk.
Posted Aug 23, 2011 10:28 UTC (Tue) by cortana (subscriber, #24596)
Debian's kexec-tools package for instance always boots /vmlinuz, which is a symlink maintained by the various linux-image-* packages and which usually points to the latest installed kernel. IMO this is a mistake, and kexec should attempt to boot into the currently installed kernel, if it still exists.
This doesn't sound too hard--just look at the results of uname(2) and then look for a matching file in /boot. I think this would make your scenario less likely, however (at least in Debian's case) they only use a different filename for different kernel releases and ABI-changing updates to the same release, so the file /boot/vmlinux-3.0.0-1-amd64 that currently exists on my system may have been updated since the system booted with a file of the same name.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds