On Sun, 28 May 2000, Hilmar Preusse wrote:
Hello Konrad Rosenbaum! On Don, Mai 25, 2000 at 07:58:37 +0200 you wrote me..
On Wed, 24 May 2000, Hilmar Preusse wrote:
Das heißt dann also, daß er uns den Punkt, daß die neuen Module nicht installiert werden konnten, ganz einfach verschwiegen hat und der neue Kernel jetzt Probleme mit den alten Modulen hat. Gut. Dem Problem des Kernelcrashs sind wir damit aber IMHO keinen Millimeter näher gekommen, weil sowas wie da oben allemal ein paar Warnings erzeugen dürfte.
Nicht, wenn die Kernel-symbole keine Signaturen enthalten (Option "Set Version Info..."). AFAIK aendern sich einige Strukturen, wenn man den Kern mit/ohne SMP kompiliert. Der Linker bekommt das nicht mit, also geht es dann spaeter schief. Da es die selbe Kernel-Version ist gibt es auch da keine Konflikte, die der Linker auloesen koennte.
Linker = kerneld/kmod?
ja.
Zu deutsch, der kriegt nicht mit, daß die alten Module eigentlich zu ihm gehören und will sie deshalb nicht mehr laden und damit läuft die Mühle gegen den Baum...
Nein, genau umgekehrt: er bekommt nicht mit, dass er die Module gar nicht laden duerfte. Er laedt sie und beim ersten Versuch die neuen Symbole zu nutzen gibt es das Kernel-Aequivalent eines SIGSEGV: oops oder gar panic. Kleines Beispiel: wie definieren die Struktur ksomething struct { #ifdef __SMP__ int processor; #endif int somedata; } ksomething;
jetzt eine Funktion dazu: int sys_somefunc(struct ksomething s) { ... }
wir kompilieren einmal mit SMP (wie das die meisten Distries machen) und installieren die Module und den Kernel. Alles funzt. Nun kompilieren wir ohne SMP (was optimaler auf SingleProcessor MAschinen laeuft) und vergessen die neuen Module zu installieren. Ergebnis: sys_somefunc bekommt nur noch 4 Byte uebergeben, er greift aber auf 8 Byte zu und ueberschreibt damit seine Ruecksprungaddresse -> Absturz beim Ruecksprung. Ich habe solche Effekte in den letzten Wochen oft im Userspace gehabt - ist echt lustig solche Bugs zu suchen. ;-)
Konrad