Kernel Traffic #122 For 18 Jun 2001

There were 393 different contributors. 190 posted more than once. 152 posted last week too.

Derek Glidden konnte reproduzieren, dass sein komplettes System minutenlang steht. Er schob das Problem auf den VM in 2.4 und meinte, dass es immer noch ernsthafte Problem mit dem 2.4er VM gibt. Ein paar andere bestätigten das Problem und es folgte eine lange Diskussion. Miles Lane sagte dann, " Mike und ich haben diese Kommentare langsam satt. Sheesh. Die VM Entwickler haben die Probleme längst erkannt und arbeiten daran, es gibt bereits mindestens einen Patch, der dieses Problem behebt. Es scheint offentsichtlich, dass der Aufruhr um das Handling des Swapbereichs aufgenommen wurde und jetzt bearbeitet wird. Wahrscheinlich wird das nicht heute und nicht morgen behoben sein, aber bald. Was wollt ihr denn noch?" Derek warf ein, dass seine Original Mail darauf abzielen sollte, ein paar Daten-Einstiegspunkte zu liefern und Miles antwortete, " Tatsächlich fand ich deine erste Mail recht nützlich. Sie hat zu einem Umdenken einiger Design Sachen im 2.4er VM angespornt und auch einige Bugs aufgezeigt. Du warst nicht mit den angreifenden Worten gemeint, sondern diejenigen, die einfach nur über die Anforderungen der Swapbereichsgröße lästerten, ohne den Entwicklern nützliche Infos zu geben, wie die Situation verbessert werden kann. Also danke, dass du dieses Thema angeschnitten hast :-)"

Das mag alles recht wahr sein, aber was du damit demonstriert hast, ist das "swapoff()" extrem (und damit meine ich _EXTREM_) ineffizient ist, beinahe so schlimm, es besser als unnutzbar zu markieren. Das wurde mit 2.4.x nicht unbedingt schlimmer, weil VM schlimmer wurde, sondern weil das viel ausdauerndere Swapcache Verhalten in 2.4.x die Ineffizienz von "swapoff()" deutlicher werden lässt. Ich glaube nicht, dass sich der swapoff() Algorithmus geändert hat, ich denke nur, dass es daher kommt, weil der Algorithmus schon immer exponentiell war (und wegen dem beständigeren Swapcache, wurde das "n" im Algorithmus eben wesentlich grösser). Es ist also ein anderes Problem unabhängig von den vorhandenen VM Balancing Sachen. Man schaue sich die "try_to_unuse()" Logik an, da bekommt man das Zucken. Es wäre echt klasse, wenn sich jemand mehr um swap-off kümmern würde. Es könnte durchaus sein, dass z.B. swap-off die toten Swap-Pages überhaupt nicht mehr registriert - jemand sollte prüfen, ob es nicht einliest und "try_to_unuse"() auf die toten Swap Einträge macht. Das würde die Ineffizienz wesentlich besser zeigen.

Felix von Leitner berichtete, dass einige der Kernelheader Dateien die Userland Bibliotheken wie dietlibc dazu bringen, eine falsche API zu exportieren. Er gab einen kurzen Fix dazu, doch David S. Miller meinte, " Die Kernelheader sollten nicht für Userspace genutzt werden. Kernel und Userspace Headers haben unterschiedliche Namespaces und du hast ein Beispiel aufgezeigt, wo verschiedene Namen/Strukturen usw. für Kernel Netzwerk Headers und dem, was der User möchte existieren."

Peter J. Braam stellte ein paar ext3 rpms zusammen und machte sie auf ftp://ftp.clusterfilesystem.com/pub/ext3 verfügbar. P.A.M. van Dam fragte nach, wo er ext3 Patches für 2.4 finden kann und Andrew Morton antwortete:

Die ganzen Details sind auf http://www.uow.edu.au/~andrewm/linux/ext3/

Der gegenwärtige Stand ist "ziemlich solide". Performance ist gut. Mit LVM und RAID ist es nicht getestet. Unter hoher Last und Quotas können Dead Locks entstehen.

Vermeidet diese Dinge und es sollte keine Problem damit geben.

Die nächste Sache wird sein es zurück auf -ac zu portieren und die Quotas Probleme zu beheben.

Dawson Engler schrieb ein Hilfsprogramm, um Quellcode auf Bugs zu untersuchen. Insbesondere sagte er, " kann man mit diesen Tracker prüfen, ob die Information aus einer unsicheren Quelle (z.B. von copy_from_user) einen trusting sink (z.B. ein Array) erreichen kann. Haupthinderniss für effizientes tracken ist, dass alle eine ziemlich unterschiedliche Vorstellung von dem Begriff trusting sinks haben. Falls jemand weitere Vorschläge hat, wo es gefährlich sein kann, solche Daten einfach aufzunehmen, bitte einfach mailen." Er listete 15 Bugs auf, die er mit dem Tool aufgespürt hat. Alan Cox patchte gleich mehrere davon und Oliver Xymoron sagte:

Ich habe etwas änhliches im User Space geschrieben (via ld preload). Die meisten meiner Prüfungen folgten Strings auf korrekte Länge, um Stack Overflows zu entdecken, aber es werden auch Argumente bei open gecheckt, etc..

Bei deinem Fall sind eigentlich alle Ziele potienzielle trusting sinks: Aus dem User Space kommen Daten, die wohin müssen. Vielleicht solltest du eher prüfen, dass die Daten über Funktionsaufrufe laufen, die nichts verderben, indem du Capabilities usw. checkst. Ich wette du kannst mit einigen wenigen Checks um die 90% der Codepfade abdecken. Und der Rest davon kann dazu umgeschrieben werden.

Eric S. Raymond berichtete von einigen neuen Konfigurationssymbolen, die in 2.4.6pre2 keine dazugehörende Doku haben. Er listete sie auf:

Maksim Krasnyanskiy benannte die CONFIG_BLUEZ Punkte und erklärte, dass diese zum Bluetooth Subsystem gehören, verschwieg auch nicht, dass Linux das erste OS sei, welches offiziell Bluetooth Unterstützung hat. Er beschrieb die einzelnen Funktionen:

CONFIG_BLUEZ

Bluetooth is low-cost, low-power, short-range wireless technology. It was designed as a replacement for cables and other short-range technologies like IrDA. Bluetooth operates in personal area range that typically extends up to 10 meters. More information about Bluetooth can be found at http://www.bluetooth.com

Linux Bluetooth subsystem consist of several layers:

HCI Core (device and connection manager, scheduler)
HCI Device drivers (interface to the hardware)
L2CAP Module (L2CAP protocol)

Say Y here to enable Linux Bluetooth support and to build HCI Core layer.

To use Linux Bluetooth subsystem, you will need several user-space utilities like hciconfig and hcid. These utilities and updates to Bluetooth kernel modules are provided in the BlueZ package. For more information, see http://bluez.sf.net.

If you want to compile HCI Core as module (hci.o) say M here.

Not unsure ? say N.

CONFIG_BLUEZ_L2CAP

L2CAP (Logical Link Control and Adaptation Protocol) provides connection oriented and connection-less data transport. L2CAP support is required for most Bluetooth applications.

Say Y here to compile L2CAP support into the kernel or say M to compile it as module (l2cap.o).

Not unsure ? say M.

CONFIG_BLUEZ_HCIUART

Bluetooth HCI UART driver. This driver is required if you want to use Bluetooth devices with serial port interface.

Say Y here to compile support for Bluetooth UART devices into the kernel or say M to compile it as module (hci_uart.o).

Not unsure ? say M.

CONFIG_BLUEZ_HCIUSB

Bluetooth HCI USB driver. This driver is required if you want to use Bluetooth devices with USB interface.

Say Y here to compile support for Bluetooth USB devices into the kernel or say M to compile it as module (hci_usb.o).

Not unsure ? say M.

CONFIG_BLUEZ_HCIEMU

Bluetooth Virtual HCI device driver. This driver is required if you want to use HCI Emulation software.

Say Y here to compile support for Virtual HCI devices into the kernel or say M to compile it as module (hci_usb.o).

Not unsure ? say M.

Randy Dunlap empfahl, statt "Not unsure? Say M" ein "Sure? Say M", worauf Maksim einging und eine geänderte Liste postete.

Matt Nelson hatte ein Projekt, das um die 6G RAM auf der Intel-Plattform benötigt und wollte wissen, ob es hier irgendwelche Probleme geben kann. Doug McNaught empfahl ihm eine Alpha-Maschine und erklärte, "Auf IA32 sind Zeiger immer noch 32 Bits, also kann (so wie ich das verstehe) jeder Prozess höchstens 4GB adressieren. Du könntest mehrere Teilbereiche zuweisen (im Shared Memory oder mmap()ed Dateien, damit sie dauerhaft sind) und sie je nach Gebrauch rein- und rausmappen (was haarig werden kann). Oder du splittest dein Programm auf mehere Prozesse auf, wobei ein Prozesse nicht mehr als 4GB in Anspruch nimmt, das würde auf IA32 laufen." Später sagte Matt dann, " Danke an alle, die geantwortet haben. Ich habe noch nie soviel Speicher gebraucht und wusste nicht genau Bescheid, wie das mit dem 64GB auf IA32 läuft... jetzt muss ich mir nur ein erschwingliches SMP Alpha System besorgen..."

Craig Lyons von Promise Technology sandte Andre Hedrick einen Patch und erklärte, " Der 2.4er Kernel unterstützt einige unserer Produkte (Ultra 66, Ultra 100, etc.). Wie manche vielleicht wissen, nutzen unsere Controller (die einfache Standard IDE Controller sind und kein RAID haben) dieselbe ASIC als die FastTrak RAID Controller. Der 2.4 Kernel erkennt die Ultra Controller-Familie, das Problem ist, die FastTrak Controller-Familie wird ebenso als Ultra erkannt. Dadurch wird das Array von FastTrak Controllern nicht als solches erkannt, sondern jede Disk wird einzeln angesprochen und die Userdaten werden nicht korrekt benutzt. Wir haben hier einen Patch, der das Problem behebt und fragen uns, ob er so in den Kernel eingehen kann." Andre antwortete (festhalten!), " Ich will und brauche die Patches eures Unternehmens nicht, punkt. Ich werde keinen Dreckscode annehmen, der es einem übel geschriebenen Binary Treiber erlaubt, sein eigenes ISR zu kontrollieren, ausserdem greift er störend in den nativen ATA Treiber ein. "

Bert Hubert zügelte, "Craig hat dich kontaktiert, damit man herausfinden kann, wo die Probleme liegen und wie sie zu lösen sind. Linus würde auch Patches von Bill Gates akzeptieren, wenn sie die richtige Lizens haben und guten Code darstellen, also sehe ich keinen Grund, warum das bei Promise anders laufen sollte." Zu Craig sagte er, " Der Ablauf sollte sein, den Patch öffentlich auf der Liste zu zeigen, damit die Leute darüber kommentieren und ihn probieren können. Es stellt sich häufig heraus, dass der Code nicht up-to-date mit der Kernelversion ist oder eben nicht dem Kernelstil folgt. Das ist nicht böse gemeint, die Kernelentwickler sind eben recht wählerisch. Aber mit dem richtigen Fingerspitzengefühl zeigen sie einem auch, wie der Code auszusehen hat, damit er akzeptiert wird. Alternativ schauen sie sich den Code an und arbeiten das Gute selbst heraus." Andre warf wieder ein, " Nein, ich würde den Code nicht haben wollen und ihn akzeptieren. Ich will ihn nicht einmal anschauen. Alles was ich will sind die API Regeln zu den Signaturen, die wir jetzt haben. Wir brauchen ihren Treiber nicht." Rob Landley fühlte, dass Andre als Maintainer ein wenig "offener" über die Patches denken sollte. Andre antwortete, " Ich haben einen gesehen und würde daraufhin körperlich krank."

Der Thread endete hier, aber später räumte Andre ein und begrüsste Craig zu dem Schritt hin zur GNU/GPL Linie. Craig konnte nicht versprechen, dass sein Unternehmen jetzt komplett auf Opensource Treiber umstellt, bedankte sich aber damit, dass er "schaut was sich machen lässt".


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	5 Jun 2001 - 12 Jun 2001	(150 posts)	Status Of 2.4 Virtual Memory Subsystem
2.	8 Jun 2001	(6 posts)	Using Kernel Headers In User Programs
3.	8 Jun 2001 - 9 Jun 2001	(4 posts)	Status Of ext3
4.	8 Jun 2001 - 11 Jun 2001	(10 posts)	Automatic Bug Hunter
5.	10 Jun 2001 - 13 Jun 2001	(4 posts)	Undocumented Configuration Symbols In 2.4.6pre2
6.	11 Jun 2001 - 13 Jun 2001	(9 posts)	Bigmem Limitations
7.	12 Jun 2001 - 13 Jun 2001	(10 posts)	Commercial Patches

Kernel Traffic #122 For 18 Jun 2001

By Zack Brown

Translated By: Florian Zimmermann