Jaderné noviny - 21. 6. 2006

3. 7. 2006 | Robert Krátký | Jaderné noviny | 4477×

Aktuální verze jádra: 2.6.17.1. Citát týdne: Linus Torvalds. Konečně dojde ke změně ovladačového kódu. Další symbolické odkazy v sysfs. Detekování úniků paměti v jádře. Dávkované zápisy. Proč odstranit DevFS.

Aktuální verze jádra: 2.6.17.1

Správci stabilního jádra vydali 2.6.17.1 s bezpečnostní opravou v síťovém protokolu SCTP a 2.6.16.21 se stejnou SCTP opravou, dále opravou pro 32bitová PPC a konečně opravou lokálního DoS.

Od vydání jádra 2.6.17 se Linusův strom začal velmi rychle naplňovat; během 3 dnů bylo přijato skoro 3000 patchů. Je mezi nimi velká aktualizace MIPS a dále běžné aktualizace ARM, SCSI PCI hotplug, bezdrátového a běžného síťování, síťového ovladače, firewire a pročištění hlavičkových souborů.

Citát týdne: Linus Torvalds

Věc se má tak, že já si nijak nelibuji v debugování vlastních počítačů. _Daleko_ raději mám, když jiní lidi debugují _své_ počítače, a při tom spraví i ten můj.

-- Linus Torvalds

Konečně dojde ke změně ovladačového kódu

Článek napsal Greg Kroah-Hartman.

V listopadu minulého roku jsem napsal seznam kroků, kterými se bude v budoucnu ubírat základní ovladačový kód v jádře. Konečně byly některé z popisovaných kroků implementovány.

Odstranění struct class_device

V jaderném stromu -mm je malý patch, který téměř všem uživatelům struktury struct class_device v rámci jádra umožňuje přechod na strukturu struct device. Daný patch mění struct device přidáním následujících polí:

struct device_attribute *devt_attr;
struct list_head        node;
struct class            *class;
dev_t                   devt;

První dvě pole, devt_attr a node, používá ovladačový kód interně a nic jiného by se jich nemělo dotknout. Další dvě pole, class a devt, jsou to, co použije kterýkoliv kód, jež si přeje přejít na strukturu struct device.

Je-li pole class někým nastaveno před registrací struct device, ovladačový kód předpokládá, že je tato struct device přiřazena k specifikované struct class. To znamená, že je zařízení přidáno do seznamu všech zařízení připojených k této třídě a v adresáři třídy v sysfs je vytvořen symbolický odkaz ukazující jeho přítomnost.

Je-li nastaveno pole devt, bude pro zařízení v sysfs adresáři vytvořen soubor dev, který obsahuje major a minor čísla zařízení. To pak programy jako udev používají k správnému dynamickému zaplnění adresáře /dev podle zařízení přítomných v systému.

Příklad toho, jak vypadají změny sysfs, jsou-li tato pole nastavena, najdete v kódu třídy usb_device, která byla v posledním -mm konvertována, aby používala nové rozhraní.

Adresář /sys/class/usb_device v jádře 2.6.17 vypadal na většině systémů takto:

$ tree /sys/class/usb_device/
/sys/class/usb_device/
|-- usbdev1.1
|   |-- dev
|   |-- device -> ../../../devices/pci0000:00/0000:00:1d.7/usb1
|   `-- uevent
|-- usbdev2.1
|   |-- dev
|   |-- device -> ../../../devices/pci0000:00/0000:00:1d.0/usb2
|   `-- uevent
|-- usbdev3.1
|   |-- dev
|   |-- device -> ../../../devices/pci0000:00/0000:00:1d.1/usb3
|   `-- uevent
|-- usbdev4.1
|   |-- dev
|   |-- device -> ../../../devices/pci0000:00/0000:00:1d.2/usb4
|   `-- uevent
`-- usbdev4.3
    |-- dev
    |-- device -> ../../../devices/pci0000:00/0000:00:1d.2/usb4/4-1
    `-- uevent

Ale teď, po převedení na používání struktury struct device místo struct class_device, vypadá takto:

/sys/class/usb_device/
|-- usbdev1.1 -> ../../../devices/pci0000:00/0000:00:1d.7/usb1/usbdev1.1
|-- usbdev2.1 -> ../../../devices/pci0000:00/0000:00:1d.0/usb2/usbdev2.1
|-- usbdev3.1 -> ../../../devices/pci0000:00/0000:00:1d.1/usb3/usbdev3.1
|-- usbdev4.1 -> ../../../devices/pci0000:00/0000:00:1d.2/usb4/usbdev4.1
`-- usbdev4.3 -> ../../../devices/pci0000:00/0000:00:1d.2/usb4/4-1/usbdev4.3

Docílili jsme tím přesunutí struktury USB zařízení, která seděla v adresáři třídy, do samotného stromu zařízení v sysfs, a vytvořili tak jednotný strom zařízení, takže už není nutné se v sysfs dívat na dvě místa, abychom získali informace.

Pomocné funkce

Pro přechod stávajícího jaderného kódu ze struktury struct class_device na struct device byly do ovladačového kódu přidány dvě nové funkce:

struct device *device_create(struct class *cls, struct device *parent,
                             dev_t devt, char *fmt, ...)
                             __attribute__((format(printf,4,5)));
void device_destroy(struct class *cls, dev_t devt);

Funkce device_create funguje skoro stejně jako současná jaderná funkce class_device_create. Dynamicky vytvoří strukturu struct device se všemi specifikovanými informacemi a zaregistruje ji u ovladačového kódu a sysfs.

Druhá funkce (device_destroy) se používá k odstranění všech struktur struct device, které byly dříve vytvořeny voláním device_create. Je téměř totožná s existující funkcí class_device_destroy.

Příkladem jednoduchosti převedení stávajícího kódu je patch, který konverzi provádí v kódu třídy usb_device.

Časem budou všichni uživatelé struct class_device převedeni na struct device a pak bude struct class_device z jádra odstraněna. A doufejme, že bude dosaženo i dalších cílů stanovených v původním článku.

Další symbolické odkazy v sysfs

Článek napsal Greg Kroah-Hartman.

Další změnou v sysfs, kterou přinese jádro 2.6.18, je přidání nového symbolického odkazu do všech adresářů zařízení a tříd zařízení. Kay Sievers napsal patch, který do těchto adresářů přidává symbolický odkaz "subsystem". Odkazuje buď zpět na třídu, ke které je zařízení přiřazeno, nebo na sběrnici, ke které je připojeno.

Tento symbolický odkaz je stejný jako informace, které jádro dodávalo do uživatelského prostoru prostřednictvím rozhraní hotplug vždy, když bylo zařízení vytvořeno nebo odebráno ze systému. Uživatelský prostor využívá informace subsystému k rozhodování o tom, co se zařízením dělat.

Podíváte-li se na starší balíky hotplug, všimnete si, že se skládají ze sad různých skriptů, které jsou spouštěny podle subsystému, o který se jedná:

$ ls /etc/hotplug/*.rc
/etc/hotplug/input.rc
/etc/hotplug/isapnp.rc
/etc/hotplug/pci.rc
/etc/hotplug/pnp.rc
/etc/hotplug/usb.rc

A udev pravidla také reagují na druh subsystému při rozhodování o tom, co se zařízením provést:

$ head -n 3 /etc/udev/rules.d/05-udev-early.rules
# ignore these events until someone needs them
SUBSYSTEM=="drivers",   OPTIONS="ignore_device"
SUBSYSTEM=="module",    OPTIONS="ignore_device"

Předtím, než byl k dispozici tento patch, musel program, který chtěl prolézt sysfs a zjistit subsystém, k němuž bylo zařízení přiřazeno, podstoupit následující:

• Je-li to zařízení, hledej symbolický odkaz bus a následuj ho.
• Je-li to třída zařízení, jdi o adresář výše a podívej se, jestli je to adresář třídy. Pokud ne, jdi o další adresář výše, dokud třídu nenajdeš.

Teď může být díky novému symbolickému odkazu celá akce velmi zjednodušena, protože pro zjištění subsystému, kterému je zařízení přiřazeno, stačí následovat tento odkaz:

$ tree /sys/class/tty/ttyS0/
/sys/class/tty/ttyS0/
|-- dev
|-- device -> ../../../devices/platform/serial8250
|-- subsystem -> ../../../class/tty
`-- uevent

$ tree /sys/devices/pci0000:00/0000:00:00.0/
/sys/devices/pci0000:00/0000:00:00.0/
|-- broken_parity_status
|-- bus -> ../../../bus/pci
|-- class
|-- config
|-- device
|-- driver -> ../../../bus/pci/drivers/e752x_edac
|-- enable
|-- irq
|-- local_cpus
|-- modalias
|-- power
|   |-- state
|   `-- wakeup
|-- resource
|-- subsystem -> ../../../bus/pci
|-- subsystem_device
|-- subsystem_vendor
|-- uevent
`-- vendor

Detekování úniků paměti v jádře

Implementačním jazykem linuxového jádra je C. Taková volba dává výborný smysl; C nestojí programátorům v cestě a nechává je přesně ovládat, co se děje. Avšak každý, kdo se programováním v C trochu více zabývá, jednou skončí u odchytávání úniků paměti. Protože C programátory nutí sledovat každý blok alokované paměti a uklízet po sobě svůj nepořádek, občas něco proklouzne. V aplikacích mohou být úniky paměti problematické - především v těch, které běží dlouho; zeptejte se kteréhokoliv uživatele Firefoxu. Ale úniky paměti v jádře jsou ještě horší - kdykoliv jádru uteče kousek paměti, je v nenávratnu až do dalšího restartu. Systém s vážnými úniky paměti se brzy stane nepoužitelným.

Vysledování úniku paměti může být obtížná práce. Když se před lety objevil proprietární nástroj pro SunOS, který sledoval alokování paměti, nerozpakoval jsem se utratit za něj tisíce dolarů svého zaměstnavatele; investice se velmi rychle vrátila. V současnosti mohou uživatelé Linuxu používat pro sledování úniků paměti v uživatelském prostoru svobodný nástroj valgrind (verze 3.2.0 vyšla 8. června). Ale valgrind nelze použít na běžící jádro. (Pracovalo se na spuštění User-mode Linuxu pod valgrindem, ale někdy je prostě potřeba debugovat hostitelský systém.)

Protože vývojáři jádra při hledání chyb čím dál více spoléhají na automatizované nástroje, je vytvoření detektoru jaderných úniků paměti jasným kandidátem. Catalin Marinas se do toho pustil a výsledkem je sada patchů implementujících detektor úniků paměti v jádře. Pokud by byl přijat do jádra, měl by tento kód pomoci odstranit celou jednu velkou skupinu chyb.

Catalinův patch funguje velmi podobně jako garbage collector [sběrač nepořádku], který prochází a označuje. Prvním krokem je vysledovat všechny alokace paměti v systému; patch pro ten účel využije slab alokátor. Každý blok alokovaný ze slabu (což zahrnuje i alokace od kmalloc()) je uložen do radix stromu; kromě ukazatele na blok je součástí uložených informací velikost bloku a stack stopa, která určuje, kde byl blok alokován. Při uvolnění bloků jsou odpovídající záznamy z radix stromu odstraněny.

Během normálního provozu tento radix strom jen sedí a čeká. Jakmile se někdo zeptá na úniky paměti (přečtením /sys/kernel/debug/memleak), spustí se detekční algoritmus. Provedou se následující úkony:

• Je vytvořen velký seznam všech aktuálních alokací paměti v systému. Seznam se nazývá "čistý"; každá položka je považována za potenciální únik paměti.
• Různé části paměti jsou proskenovány při hledání ukazatelů, které odpovídají alokovaným blokům; kdykoliv je takový ukazatel nalezen, je blok přesunut do "šedého" seznamu paměti, která je stále dostupná - tj. neunikla. Prvotní proskenování zahrnuje i oblasti statických dat jádra, jaderný stack všech procesů a variabilní datovou oblast každého procesu.
• První proskenování nalezne veškerou paměť, na kterou je odkazováno ze statické paměti. Ale jaderné datové struktury jsou komplikovanější. Takže každý blok přeřazený do šedého seznamu je také proskenován. Většina těchto bloků budou struktury alokované ze slab keše a mohly by obsahovat ukazatele na další struktury. Takže je každý blok prověřen, přičemž se sleduje jeho zapamatovaná velikost. Všechny ukazatele v bloku nalezené jsou přesunuty do šedého seznamu a tam proskenovány. Samozřejmě existuje opatření, které slouží k zapamatování, zda už byl daný blok skenován, a brání tak nekonečným smyčkám.
• Po proskenování všech ukazatelů v šedém seznamu byl lokalizován každý dosažitelný blok paměti. Vše zbývající na čistém seznamu je považováno za únik a do uživatelského prostoru je odeslána příslušná informace.

Ve skutečném světě jsou věci komplikovanější, takže detektor úniků není tak jednoduchý, jak je popsáno výše. Jednou ze situací, kterou bylo nutné řešit, jsou případy, při nichž jádro drží ukazatel na vnitřek bloku, ne jeho začátek. To se stává často; mnohé jaderné struktury jsou například lokalizovány pomocí vložené struktury list_head nebo kobjectu. Pro lokalizaci těchto bloků používá detektor úniků paměti makro container_of(); jde především o zapamatování velikosti bloku a offsetu k vložené struktuře. Při alokaci bloku dané velikosti zaznamená detektor "alias" adresy všech možných vložených struktur. Ukazatel na jeden z těchto aliasů je považován za ekvivalent ukazatele na začátek bloku.

Je potřeba se postarat i o další speciální případy. Například na paměť alokovanou přes vmalloc() bude ukazovat sám alokační kód, ale přesto může uniknout. V jiných případech je alokována paměť, kterou nelze najít skenovacím algoritmem; do jádra je přidáno několik poznámek, které mají zabránit výsledným pozitivním nálezům. Detektor lze také ošálit ukazateli, které jsou ponechány v nepoužívané paměti, nebo náhodnými daty, která zrovna vypadají jako ukazatel na alokovaný blok; v takových případech je výsledkem falešný negativní nález.

I s těmito potížemi je situace lepší než kdy dříve - může být nalezeno mnoho situací, při kterých uniká paměť. Ingo Molnar však mluví o mnohem ambicióznějším plánu, který by zahrnoval i uložení informace o typu každého alokovaného bloku. Tato informace by - mimo jiné - umožnila omezit skenování na části bloku, o kterých se ví, že obsahují ukazatele; to by mělo proces zrychlit a vyloučit falešné negativní nálezy. Protože informace o typu jsou volně dostupné, mohl by být každý skenovaný ukazatel zkontrolován, aby se vyjasnilo, jestli ukazuje na blok správného typu, což by do jádra přidalo další úroveň kontroly. Implementace toho všeho je však spousta práce a i Ingo by asi potřeboval pár dní, aby to zvládl.

---

Následující obsah je © KernelTrap

Dávkované zápisy

20. čer, originál

Hans Reiser popsal nedávno navržený patch takto: Upravuje stávající kód reiser4 tak, aby poskytoval dobrý výkon i u zápisů větších než 4k. Dělá to vytrvalým dodržováním principu, že věci, které je nutné udělat jednou za zápis, by měly být provedeny jen jednou za zápis - ne jednou za 4k. A dále vysvětlil: Tento kód empiricky dokazuje, že design obecného FS kódu, který posílá konkrétnímu souborovému systému vždy jen 4k, lze vylepšit. Výkonnostní testy ukazují, že nový kód spotřebovává při 'dd bs=1MB .....' o 40 % méně procesoru. S ohledem na generic_file_write() poznamenal, že při zápisu 64 MB dat to možná půjde k jádru jako 64MB zápis, ale VFS to FS pošle jako 64MB/4k samostatných 4k zápisů.

Andrew Morton reagoval na navrhované změny: Nic na tom vyloženě nekřičí "špatně", ale nic také nekřičí "správně". Zdá se mi to prostě trochu bezdůvodné. Poukázal na to, že reiser4 je v současné době jediný souborový systém, kterému by to přineslo výhody. Abychom mohli říct "ano, to chceme", museli bychom myslím vědět, že by z toho další souborové systémy také mohly těžit. V diskuzi, která následovala, se ukázalo, že jak pro FUSE, tak XFS by tyto změny byly výhodné. Hans se tedy zeptal: Stačí? Andrew souhlasil: Dejme tomu. Pojďme se tedy podívat na diff.

Proč odstranit DevFS

21. čer, originál

Greg KH poslal aktualizovanou sadu patchů pro odstranění devfs z hlavního linuxového jádra - podobně, jako to bylo provedeno v -mm: Jsou to ty samé patche pro smazání devfs, které jsem navrhoval do 2.6.12, 2.6.13, 2.6.14, 2.6.15 a 2.6.16. Vyrazí z jádra všechno devfs a ušetří spoustu místa. Odstraňování nespravovaného devfs, které bylo nahrazeno udev, je přetřásáno od roku 2003. V roce 2005 nabraly snahy o odstranění obrátky, což vedlo k dlouhým debatám. V posledním mailu Greg vysvětloval: Od vydání 2.6.13 jsem si nevšiml žádných připomínek ohledně toho, že devfs už nejde zapnout. Kromě toho to vypadá, že mnohé subsystémy už devfs odstraňují nějakou chvilku, aniž by to někomu vadilo (nikdo to nepoužívá). A vypočítává další důvody:

Tato sada patchů byla navíc v -mm bez jakýchkoliv připomínek nebo problémů už několik měsíců. Je to také skoro rok, co jsme prostřednictvím souboru Documentation/feature-removal-schedule.txt řekli, že devfs půjde pryč, a skoro dva roky od chvíle, kdy jsme veřejně oznámili úmysl odebrat devfs ze stromu zdrojových kódů jádra. Takže myslím, že byli lidi varováni opravdu s dostatečným předstihem :-).

       

Komentáře

[Drom]

Otazka DevFS je jak mexicka telenovela, porad dalsi dily a konec v nedohlednu :)

[michich]

Konec už nastal. Linus ve čtvrtek ty Gregovy patche potáhnul do svého git repozitáře.

[stativ]

Tak, pánové, a to je konec.
Hurááá!

[valesek]

Co, co, cože,devFS se bude rušit? To nééééééééééé ......

:)))))))