Jaderné noviny - 27. 2. 2008

7. 5. 2008 | Lukáš Helebrandt | Jaderné noviny | 2706×

Aktuální verze jádra: 2.6.25-rc3. Citát týdne: Jörn Engel. Časné začleňování ovladačů. Sledování memory-mapped I/O operací.

Obsah

• Aktuální verze jádra: 2.6.25-rc3
• Citát týdne: Jörn Engel
• Časné začleňování ovladačů
• Sledování memory-mapped I/O operací

Aktuální verze jádra: 2.6.25-rc3

Aktuální vývojová verze jádra (27. 2. 2008) je 2.6.25-rc3, vydaná 24. února. Změny tvoří opět většinou opravy, ale objevil se třeba nový parametr modulu libata.force, ovladač pro hardwarové monitorovací čipy ADT7473 a pro SAS/SATA řadiče Marvell 88SE6440, nový stav power managementu PM_EVENT_HIBERNATE {a new PM_EVENT_HIBERNATE power management state} a podpora kvalifikací souborů [file capabilities] pro bezpečnostní modul SMACK. Detaily hledejte v krátkém nebo dlouhém changelogu.

Od vydání -rc3 se do hlavního git repozitáře pomalu trousily opravy chyb.

Aktuální stabilní jádro je 2.6.24.3, vydané 25. února s pěknou dávkou oprav. Stejného dne vyšly s menším množstvím oprav také aktualizace stabilních jader 2.6.23.17 a 2.6.22.19; jsou to pravděpodobně poslední aktualizace řad 2.6.22 a 2.6.23.

Starší jádra: 24. února bylo vydáno 2.4.36.2; opravuje bug zavedený v 2.4.36.1 a jeden poměrně obskurní bezpečnostní problém.

Citát týdne: Jörn Engel

Strojově generovaná varování jsou skvělým způsobem, jak v jinak nepřeberném množsví kódu najít podezřelé věci. Ani moc nezáleží na tom, jaká varování hledáte; téměř všechny kontrolery kódu {code checkers} najdou ta stejná ožehavá místa.

Je v tom ale malý háček. Pokud použijete příliš horlivou varovací politiku, která "opraví všechny ty warningy", varování sice mohou zmizet, ale opravdové problémy ne. Radši ani nezmiňuji nové problémy zavedené těmito takzvanými "opravami". [...]

Nezapomeňte na jeden děsivý děsivý důsledek: kontrolery kódu v nesprávných rukou aktivně škodí.

-- Jörn Engel

Časné začleňování ovladačů

Ovladače mají tendenci žít ve svém vlastním světě, ve kterém se chyby často týkají jen velmi malé skupiny uživatelů jádra. Bohužel každý, kdo je chce testovat nebo pomoct pročistit v době, než jsou začleněny, si užije svoje. Aby pomohl tyto bariéry zredukovat, začal Linus Torvalds spolu s dalšími obhajovat časné začleňování ovladačů s tím, že jejich další vylepšování bude probíhat přímo v jádře.

Politiku včasného začleňování ale nevítají úplně všichni, přičemž jako příklad byl uveden nedávný ethernetový ovladač vzdáleného DMA (RDMA), který sídlí ve stromu infiniband. Na základě problémů, které v ovladači objevil, se Adrian Bunk zeptal: To opravdu chceme začleňovat ovladače bez _jakékoli_ kontroly? To byla patrně příliš dramatická otázka, jelikož ten ovladač podstoupil kontrolu, ale ne všechny změny se odrazily ve verzi, která je v hlavním jádře. Je na něm ještě spousta práce, zdůrazňuje maintainer Infiniband stromu Roland Dreier:

Jen aby bylo jasno, ten ovladač byl zkontrolován. Bylo nalezeno mnoho problémů; mnohé z nich byly opraveny a na dalších se pracuje.

Je věcí názoru, kdy by se měly věci začleňovat, ale v tomto případě, kdy výrobce dobře spolupracoval, jsem v jeho odložení neviděl žádné výhody.

Tento názor zastávají i další vývojáři jádra; pokud je po ruce vývojář, který reaguje na zpětnou vazbu a má funkční ovladač, je jednoznačným přínosem dostat jej do hlavního jádra, kde jej může podrobněji zkontrolovat mnohem více očí. Linus by tento postup v zájmu rozšíření spolupráce uvítal:

Opravdu bych ty ovladače raději přijal, protože i *další* lidi pak mohou posílat patche!

Jde o to, co začlenění opravdu znamená - lidé na tom mohou rozumně společně pracovat. Před začleněním je to mnohem těžší, takže pokud to s tím ovladačem někdo nemyslí opravdu vážně, provádí se údržba jen velmi zřídka.

Další správci popsali svá kritéria pro přijetí ovladačů nedosahujících obvyklé kvality. Shodli se na tom, že přijatelné jsou ty, které:

• se zkompilují a vypadají funkčně
• neobsahují žádné očividné bezpečnostní díry
• mají aktivního správce
• ovlivní pouze lidi, kteří mají daný hardware
• nezavádí žádná nepotřebná nebo nedomyšlená rozhraní v uživatelském prostoru

Na straně nevýhod je toho jen málo. Protože jsou ovladače samostatné, nezpůsobují obvykle problémy na jiných místech v jádře. Za předpokladu, že si lidé, kteří kód kontrolují, pohlídají možné bezpečnostní problémy, které by mohly vést ke kompromitaci stroje nic netušícího uživatele, neexistuje moc způsobů, jak by mohly negativně ovlivnit jádro jako celek. Rozhraní v uživatelském prostoru, která používají ioctl(), sysfs nebo další prostředky musí být také pořádně zkontrolována, jelikož jsou spravována jako část rozhraní jádra.

Mezitím se objevila spousta stížností na checkpatch - skript v perlu upozorňující na různé stylistické problémy v patchích. Je pozoruhodné, že výše uvedený seznam vůbec neobsahuje požadavek na vyřešení chyb či varování, na které checkpatch upozorňuje. Důvodem většiny stížností proti němu je kontrola délky řádku, kterou provádí; výsledné "opravy" kódu často nejsou nejlepší. Zatímco se všeobecně souhlasí s tím, že dlouhé řádky mají za následek špatně čitelný kód, posouzení, co je už příliš dlouhé, záleží většinou na estetickém cítění. Otrocké lpění na fixním počtu znaků na řádek z důvodu utišení checkpatche je zjevně vnímáno jako problém.

Pro některé je kvůli tomu checkpatch téměř zbytečný, někdy jeho výsledky hraničí s ohrožením čitelnosti kódu. Linus prohlásil, že už několikrát zvažoval jeho odstranění z hlavního stromu jádra. Pro opravu chyb hlášených checkpatchem je potřeba lidského faktoru, a právě toho se občas nedostává. Na druhou stranu, Ingo Molnár tento nástroj vehementně brání:

Díky zkušenostem z první ruky se můj názor na checkpatch radikálně změnil: teď věřím, že pro dlouhodobě kvalitní vývoj jádra je téměř stejně důležitý jako BitKeeper/Git. Kdybych jej měl přestat používat, byl by to pro mě stejně špatný krok zpět, jako kdybychom měli migrovat správu kódu jádra na CVS.

Ingo pokračoval popisem plusů a mínusů, z nichž všechny jsou v prudkém kontrastu s jeho dřívějšími stížnostmi na tento nástroj.

Pro většinu ovladačů se cesta do jádra stala mnohem jednodušší. To se snad projeví rychlejším dodáním funkčních (nebo téměř funkčních) ovladačů do rukou uživatelů. Co je ještě důležitější, také se kód mnohem rychleji dostane do rukou komunity kolem jádra. Pravděpodobným výsledkem bude funkční, čistě napsaný ovladač rychleji než kdy předtím. Už tak dost rychlý vzestup podpory hardwaru v Linuxu se právě možná ještě zrychlil.

Sledování memory-mapped I/O operací

Ovladače zařízení obvykle dělají v konečném důsledku jednu věc: komunikují s hardwarem prostřednictvím sady memory-mapped I/O (MMIO) registrů. Když se snažíte zjistit, co ovladač dělá - například pro účely ladění - je často zajímavé podívat se na sekvence MMIO operací, které provádí. A pokud se pokoušíte rozlousknout [reverse-engineer] ovladač dostupný pouze v binární podobě, sledování jeho manipulace s MMIO registry může být jediným způsobem, jak zjistit, jak daný hardware funguje. Z tohoto důvodu vyvinuli vývojáři projektu Noveau nástroj zvaný "mmiotrace", který jim pomáhá sledovat, co se děje s memory-mapped I/O. Nyní je tento nástroj vylepšován a protlačován do hlavního stromu.

Ovladače získávají přístup k MMIO oblastem pomocí ioremap() (nebo pomocí jedné z funkcí vyšší úrovně jako pci_iomap()), to je tedy logicky místo, kam umístit sledovací infrastrukturu. Proto přidává současný mmiotrace patch nové varianty ioremap():

 void __iomem *ioremap_cache_trace(unsigned long offset, unsigned long size);
 void __iomem *ioremap_nocache_trace(unsigned long offset, unsigned long size);
 void iounmap_trace(volatile void __iomem *addr);

Tyto funkce vrací (stejně jako ioremap() a ioremap_nocache()) ukazatel na I/O paměť, díky kterému se ovladač může dostat k MMIO prostoru. Ale uvnitř se děje něco trochu jiného.

Na x86 architektuře (stejně jako na většině ostatních) je k I/O paměťovému prostoru přistupováno pomocí paměťových operací přes tabulky stránek obvyklým způsobem, takže ioremap() zkrátka vrátí adresu, která mapuje na požadovanou fyzickou oblast. Sledovací verze ale přidává krok navíc - označí stránky v I/O oblasti jako nepřítomné v systému. Kdykoli se pak kód pokusí přistoupit k dané oblasti, výsledkem bude vygenerování výpadku stránky [page fault].

Za normálních okolností způsobí výpadky stránek vyvolané při běhu v jaderném módu kernel oops. Existují ale výjimky, například funkce kopírující data mezi uživatelským a jaderným prostorem. Patch mmiotrace přidává další výjimku, která porovnává výpadkové adresy se sledovanými MMIO oblastmi. Pokud bude adresa ukazovat, že jde o pokus o MMIO přístup, provede mmiotrace kód následující:

1. Označí příslušnou stránku zpět jako přítomnou v paměti.
2. Ve stavové masce procesoru vypadávajícího vlákna nastaví TF (sledovací) bit.
3. Vyvolá "pre" handler poskytovaný sledovacím kódem vyšší úrovně.
4. Označí chybu jako zpracovanou a vrátí kontrolu vypadávajícímu kódu.

Po provedení těchto kroků proběhne původní instrukce, která způsobila výpadek stránky, znovu, nyní úspěšně. Nastavení sledovacího bitu ale způsobí novou past procesoru [processor trap] po vykonání instrukce. V tu chvíli je stránka ještě jednou označena jako nedostupná, sledovací bit je resetován (pokud nebyl nastaven jinde), zavolá se "poštovní" agent sledovací vrstvy a pak jde život dál, dokud se nevyskytne další výpadek.

Sledovací vrstva má v podstatě pouze jednu úlohu: přijít na to, co se kód snaží v MMIO prostoru provést, prostřednictvím předávacího [relay] rozhraní akce logovat. Přijít na to znamená dozvědět se dostatek informací o instrukci, která způsobila výpadek stránky, aby šlo určit, ke které adrese se přistupovalo, jestli to byl zápis nebo čtení, velikost přenášených dat a vlastní hodnotu, která byla čtena nebo zapisována. Kvůli tomu je obsaženo jisté množství na architektuře závislého kódu prohledávajícího instrukce, který je v nynější podobě patche poskytován jen pro x86 stroje.

Protože se sledování aktivuje voláním speciální verze ioremap(), není možné sledovat ovladač bez editace jeho zdrojového kódu a rekompilace. To může pro nástroj určený pro pomoc (mimo jiné) s reverzním inženýrstvím vypadat jako zvláštní požadavek, ale ovladač zkoumaný projektem Nouveau používá GPL mezivrstvu slinkovanou s jádrem, takže modifikace kódu nebyla v tomto případě nic těžkého. Pro ovladače bez této "lepící" vrstvy bude zřejmě nutné najít obecnější řešení.

Kromě toho pravděpodobně patch projde před začleněním do hlavního jádra ještě několika změnami. Při kontrole kódu bylo objeveno dost věcí, které je nutné opravit, a v kódu je až příliš mnoho míst, kde komentáře říkají (doslovně): "když se stane tohle, rozpoutá se peklo na zemi". Navíc se zdá pravděpodobné, že mmiotrace bude začleněn s nedávno zaslaným sledovacím mechanismem ftrace. Na dokončení práce je před otevřením začleňovacího okna pro 2.6.26 ještě čas, ale hackeři mmiotrace budou ve vývoji muset pokračovat.

       

Komentáře

[trekker.dk]

zdůrazňuje maintainer Infiband stromu Roland Dreier

jako část rozhrání jádra.

[Filip Jirsák]

• Časné začleňování ovladačů: se zkompilují se a vypadají funkčně
• Sledování memory-mapped I/O operací: Ale uvnitř se ale děje něco trochu jiného.

Díky za Jaderné noviny.

[Fantomas]

Ale no tak, je mladej a cestinu se jeste douci

[melkors]

Stromek nutno ohybak, dokud je jeste mlady

[hydrandt]

Myslíš přesunout tebou vytučněná slova na druhou pozici? Minimálně u toho prvního si za tím stojím ;) protože je to prakticky rozdělená věta "... jsou ty, které se zkompilují a vypadají funkčně."

Druhý bod: to je pravidlo? Přiznávám, zní to líp, ale příjde mi to spíše jako záležitost citu. Rád se poučím.

[Robert Krátký]

Myslíš přesunout tebou vytučněná slova na druhou pozici?

Ne. Ta zvýrazněná slova tam byla dvakrát (je však možné, že to mám na svědomí já), ale já už to mezitím opravil.

[David Jaša]

kontrolery kódu {code checkers}

Slovo "kontroler" (nebo "kontrolér") je v tomto významu podle mě nevhodné, protože už před mnoha desítkami let se dostalo do češtiny jako termín pro zařízení, které řídí elektrické stroje (počeštěný "controller"). Změnil bych to na "kontrolor" nebo ještě něco jiného, co mě teď nenapadá.

[hydrandt]

Kontroloři kódu? Nevím... : ) Nějaký další nápad?

[trekker.dk]

To už radši kontroler než kontrolor... to druhé zní blbě.

[Jan Grmela]

Ověřovače kódu? Aplikace pro kontrolu kódu?

[Jakub Lucký]

Tak se konečně dočítám, co to moje jádro vlastně umí :) Každopádně děkuji překladatelům, ačkoliv přichází s článkem po kompilaci ;)

[Lukáš Helebrandt ( CL CITY)]

Zdravím autora .. jmenuju se stejně jménem i přímením muj email je : primerouno@seznam.cz