Login
Login-Name Passwort


 
Newsletter
Werbung

Mo, 5. Januar 2009, 17:57

Software::Kernel

Schaltsekunde deckt Fehler im Linux-Kernel auf

Ein Fehler bei der Behandlung von Schaltsekunden brachte einige Linux-Rechner zur Jahreswende zum Stillstand.

Kurz nach dem Start ins neue Jahr mussten einige Administratoren erstaunt feststellen, dass der eine oder andere Linux-Rechner keine Reaktion mehr zeigte. Nach einem Reboot liefen die betroffenen Systeme normal weiter. Linas Vepstas sammelte die in den verschiedenen Bugtracking-Systemen eingehenden und diskutierten Berichte und sandte sie zu weiteren Analysen an die Linux-Kernel-Mailingliste.

Vepstas vermutete aufgrund der meist unvollständigen Berichte, dass die am Silvesterabend um Mitternacht eingefügte Schaltsekunde etwas mit dem Problem zu tun haben könnte. Betroffen waren Systeme mit den Kernelversionen 2.6.21, 2.6.26 und 2.6.27, jedoch bei weitem nicht alle. Es musste also von weiteren Faktoren abhängen, ob der Fehler auftrat oder nicht.

Es kostete den Entwickler Chris Adams wenig Mühe, das Problem zu reproduzieren. Er erhielt einen Stack-Trace, der es ihm ermöglichte, das Problem vollständig zu erklären. Demnach ruft der Timer-Interrupt-Handler den Code zur Behandlung der Schaltsekunde auf, wobei er die Sperre xtime_lock hält. Dieser Code ruft die Funktion printk auf, um eine entsprechende Meldung auszugeben. Damit diese Meldung auch sichtbar wird, läuft normalerweise der Daemon klogd, der von printk durch einen Aufruf des Schedulers aufgeweckt wird. Unter bestimmten Umständen versucht der Scheduler, die aktuelle Zeit zu lesen, wozu er die Sperre xtime_lock belegen muss. Da diese bereits belegt ist, ist ein Deadlock erreicht: Das System hängt bis zum Neustart.

Eine einfache Lösung des Problems, das wohl erst in einigen Jahren wieder in der realen Welt auftreten kann, besteht darin, den Aufruf von printk zu entfernen. Es gibt jedoch bereits einen ebenfalls sehr einfachen Patch, der den Fehler ohne Verlust der printk-Funktion beseitigt. Wahrscheinlich wird der Patch ohne weiteres in die nächste Kernel-Version integriert. Interessant ist noch die Frage, warum der Fehler bisher unentdeckt blieb, obwohl es im Kernel Debugging-Werkzeuge gibt, um Probleme mit Sperren in der Entwicklungsphase zu erkennen. Möglicherweise müssen die Regeln, auf denen das Tool beruht, erweitert oder aktualisiert werden.

Werbung
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung