Jaderné noviny – 3. 2. 2010

24. 2. 2010 | Jirka Bourek | Jaderné noviny | 2795×

Aktuální verze jádra: 2.6.33-rc6. Citáty týdne: Alan Cox, Ingo Molnár, Chris DiBona. Zlepšování dopředného čtení. DOS díra v x86_64.

Obsah

• Aktuální verze jádra: 2.6.33-rc6
• Citáty týdne: Alan Cox, Ingo Molnár, Chris DiBona
• Zlepšování dopředného čtení
• DOS díra v x86_64

Aktuální verze jádra: 2.6.33-rc6

Současné vývojové jádro je 2.6.33-rc6 vydané 29. ledna. Zkuste ho. Snad jsme opravili mnoho regresí a dostáváme se do té fáze vývojového cyklu, kde by věci z větší části měly ,prostě fungovat‘ a kdy by lidé, kteří stále pozorují regrese, měli začít hlasitě křičet. Všechny detaily lze nalézt v kompletním changelogu

Stabilní aktualizace: Jádra 2.6.32.7 a 2.6.27.45 byla vydána 28. ledna. Aktualizace 2.6.32.7 je poměrně velká, skládá se z 98 patchů, což Greg Kroah-Hartman vysvětlil takto: Toto vydání vám přináší jaderné týmy Debianu, Novellu a Gentoo, které strávily spoustu času tím, aby mi předaly patche ze svých stromů, a jejichž snahu velmi oceňuji. Obzvláštní poděkování si zaslouží Ben Hutchings, který odvedl spoustu této práce. Poznámka pod čarou v oznámení o revizi 2.6.32.7 dává jasně najevo, že Greg byl odpovědným členem jaderných týmů Gentoo a Novellu.

Prastará jádra: Jádro 2.4.37.8 bylo vydáno 31. ledna; obsahuje bezpečnostní opravu e1000 a několik dalších. 2.4.37.9 následovalo den poté s opravou opravy e1000.

Citáty týdne: Alan Cox, Ingo Molnár, Chris DiBona

Je to opravdu velice jednoduché: S vypnutým overcommit musíš mít dostatek RAM a swapu, abys mohl uložit data všech požadovaných alokací. Se zapnutým – nemusíš mít tolik paměti, ale pokud použiješ víc, než je na systému k dispozici, něco bude muset jít.

Je to jako bankovnictví: S vypnutým overcommit je to správné bankovnictví, zapnutý overcommit je moderní západní bankovnictví.

-- Alan Cox

Zvaž fakt, že dostávám tisíckrát víc hlášení o chybách, u kterých asistovalo strace, které má tisíckrát větší režii než ten nejpomalejší přístup usond.

Tento jednoduchý fakt nám říká, že i když na výkonnosti záleží, nelze ji moc využít, pokud chybí užitečnost a čistý návrh. (Ve skutečnosti rozumný a čistý návrh téměř automaticky vyústí v dobrou výkonnost, ale to odbočuji.) Rychlé svinstvo je pořád svinstvo.

-- Ingo Molnár

Forky nejsou vždycky skvělé, ale upřímně je nepovažuji za špatnou věc a v Googlu jsem se pokusil tuto etiku vštěpovat.

Dokonce bych řekl, že různé forky Linuxu a to, jak správci některé forky přitáhli zpátky (a jiné nechali dělat si svoje), jsou důvodem, proč je linuxové jádro skvělé, a není to jenom zamíchané BSD.

-- Chris DiBona

Zlepšování dopředného čtení

Jonathan Corbet, 3. února 2010

Dopředné čtení [readahead] je proces spekulativního načítání dat ze souboru s nadějí, že budou aplikaci v blízké budoucnosti užitečná. Když funguje dobře, může významně zlepšit výkonnost aplikací omezených výkonem I/O, protože aplikace nemusí čekat na data a také se zvyšuje celkový objem I/O přenosů. Na druhou stranu se tím riskuje i zhoršení výkonnosti: Pokud dopředné čtení hádá špatně, jsou vzácná paměť a I/O propustnost vyplýtvány na datech, která se nikdy nepoužijí. Takže stejně jako u správy paměti obecně jsou i algoritmy pro dopředné čtení kritické pro výkonnost a velmi závislé na heuristice.

Jak je také obvykle u takového kódu pravidlem, jenom málo lidí se odváží zabrousit do logiky dopředného čtení; bývá citlivá a rychle se rozzlobí. Jedním z těch, kdo mají dost odvahy, je Wu Fengguang, který na dopředném čtení během let několikrát pracoval. Jeho nejnovějším příspěvkem je tato sada patchů, která se snaží vylepšit výkonnost dopředného čtení v obecném případě, ale také zrychlit odezvu v situacích, kdy je málo paměti.

Nejvýraznější vlastností této sady patchů je zvýšení maximálního objemu dopředu načítaných dat ze 128 kB na 512 kB. Vzhledem k velikosti dnešních souborů a úložných zařízení se i 512 kB může zdát málo, ale dopředné čtení má své náklady, včetně spotřeby paměti, která je potřeba k uložení dat, a I/O propustnosti zařízení, ze kterého se čtou. Jestliže rozsáhlejší dopředné čtení způsobí, že jsou vytěsněny užitečné stránky, může celková výkonnost utrpět, i když se ukáže, že dopředné čtení samo o sobě bylo užitečné. Rozsáhlejší operace dopředného čtení zaberou úložné zařízení na delší dobu, takže vzrostou latence I/O. A je potřeba nezapomínat na to, že s každým otevřeným popisovačem souboru – kterých v systému mohou být tisíce – je spojen jeden buffer pro dopředné čtení. I malé zvětšení může mít obrovský dopad na chování systému.

K číslu 512k došel Wu rozsáhlými sériemi benchmarků, které běžely jak na rotujících úložných zařízeních, tak na zařízeních bez rotujících částí [solid state]. U rotujících disků zvýšení velikosti na 512 kB téměř ztrojnásobilo propustnost I/O a přiměřeně zvýšilo I/O latenci; další zvětšování, i když opět zvýšilo propustnost, způsobilo nárůst latence, který již nebyl považován za akceptovatelný. Na zařízeních bez rotujících částí bylo zvýšení propustnosti menší (vyjádřeno v procentech), ale stále významné.

Tato čísla ale platí pro zařízení s rozumnou výkonností. Typický USB flash disk, který není zařízení s rozumnou výkonností, může se zvětšením rozsahu dopředného čtení narazit na problémy. Jako řešení problému patch stanovuje pro malá zařízení omezení okna dopředného čtení. Pro zařízení o velikosti 2 M (za předpokladu, že je něco takového ještě k nalezení), je dopředné čtení omezeno na 4 kB; pro 2GB disk je limit 128 kB. Teprve při 32 GB se kompletní 512 kB velké okno uplatní.

Tato heuristika není perfektní. Jens Axboe protestoval, že jsou některá zařízení bez rotujících částí relativně malá, co se kapacity týče, ale mohou být poměrně rychlá. Taková zařízení se nebudou chovat tak dobře, jak by při větším rozsahu dopředného čtení mohla.

Další částí patche je kód „kontextového dopředného čtení“ [context readahead], který se snaží zabránit systému načítat víc, než může zvládnout paměť. U typického souboru bez soupeření o paměť lze obsah cache stránek zobrazit (s omezenými kreslířskými schopnostmi autora článku) nějak takto:

Zde se díváme na reprezentaci proudu stránek, které obsahují data souboru; zelené stránky jsou ty, které jsou aktuálně v cache stránek. Několik nedávno použitých stránek za aktuální pozicí [offset] ještě nebylo odstraněno a data o velikosti celého okna přednačítání čekají na to, až je aplikace použije.

Když ale dochází paměť, můžeme zjistit, že situace vypadá spíše takto:

Protože systém hledá paměť, kde může, byl mnohem agresivnější tím, že odstranil stránky souboru z cache stránek. K dispozici je méně použitých stránek, ale, což je důležitější, mnoho stránek načtených dopředným čtením bylo vytlačeno pryč dřív, než je byla aplikace schopna použít. Toto chování, kdy se části systému tlučou mezi sebou, škodí výkonnosti; dopředné čtení obsadilo paměť, když ji bylo potřeba jinde, a data bude potřeba v blízké budoucnosti přečíst ještě jednou. Je zjevné, že když je pozorováno takovéto chování, systém by měl dopředné čtení omezit.

Takovou situaci je snadné odhalit; jestliže stránky, které již byly načteny pomocí dopředného čtení, nejsou k dispozici, když se je aplikace pokouší použít, něco je špatně. Když k tomu dojde, kód odhadne množství paměti, které může použít, spočítáním stránek v historii (těch, které aplikace již použila), jež ještě zůstaly v cache stránek. Pokud je nějaká historie k dispozici, počet takových stránek je použit k odhadu toho, jak velké by okno dopředného čtení mělo být.

Pokud není k dispozici vůbec žádná historie, je velikost dopředného čtení zkrácena na polovinu. V takovém případě také kód dopředného čtení opatrně posune všechny předem načtené stránky, které jsou stále v paměti, na začátek seznamu LRU [least recently used, nejdéle nepoužité], aby se snížila pravděpodobnost, že budou odstraněny těsně před použitím. Popisovač souboru je označen jako „omlácený“ [thrashed], takže jádro v budoucnu dál používá velikost historie jako vodítko toho, jak velké by mělo být okno dopředného čtení. To následně způsobí, že se okno prodlužuje a zkracuje podle toho, jak se mění podmínky v paměti.

Změny v dopředném čtení bývá obtížné dostat do hlavní řady. Heuristika může být záludná a, jak poznamenal Linus, může být snadné optimalizovat jenom pro podmnožinu pracovních zátěží:

Problém je v tom, že je často jednodušší testovat/ladit „dobré“ případy, tj. případy, kdy chceme, aby docházelo k dopřednému čtení. To s vysokou pravděpodobností znamená, že máme tendenci k příliš agresivnímu dopřednému čtení, protože u takových případů se lidé mohou nejsnáze podívat a říct „jo, tohle zvyšuje propustnost ,dd bs=8192‘“.

Stanoveným cílem této sady patchů je agresivnější dopředné čtení zvýšením maximální velikosti okna. Popravdě jde ale mnoho snahy jiným směrem, a to je omezení mechanismu dopředného čtení v situaci, když příliš dopředného čtení může škodit. Jestli tyto nové heuristiky výkonnost ovlivní spolehlivě, nebude známo, dokud se to neotestuje na mnoha benchmarcích.

DOS díra v x86_64

Jonathan Corbet, 2. února 2010

V době psaní tohoto článku žádný distributor nevydal opravu pro slabinu, která bude známa jako CVE-2010-0307. Tato konkrétní chyba (pokud autor článku ví) neumožňuje kompletní převzetí systému, ale lze ji použít pro útoky odepření služby nebo v situaci, kdy útočník s neprivilegovaným lokálním účtem chce vynutit reboot. Je to také příklad toho, jaká rizika se mohou skrývat ve starém a záludném kódu.

Mathias Krause problém ohlásil koncem ledna. Podle všeho lze na x86_64 systému vyvolat kernel panic (neúspěšným) pokusem o spuštění – exec() – 64bitového programu v 32bitovém režimu a následném vyvolání core dump. Nezdá se, že by existoval způsob, jak chybu zneužít ke spuštění libovolného kódu – ale ti, kteří chtějí přebírat kontrolu nad počítačovými systémy, v takových situacích projevují poměrně velkou kreativitu, takže si člověk nemůže být jistý. I tak ale možnost shodit libovolný 64bitový x86 systém není dobrá věc. Postižena jsou jak současná, tak starší jádra; autor článku si není vědom, že by někdo věnoval čas zjišťování, kdy se problém objevil poprvé, ale Mathias ukázal, že jádra 2.6.26 chybu obsahují.

Systémové volání execve() je způsob, jakým proces zastaví vykonávání jednoho programu a místo něj spustí jiný. Toto volání musí vynulovat většinu (ale ne všechny) stavových informací spojených se starým programem a vyresetovat je pro nový. Během tohoto procesu se překračuje „bod, odkud není návratu“ – místo, kde systémové volání musí změnu dokončit a nemůže se vrátit. Před tímto bodem by jakékoliv selhání mělo vést k návratu ze systémového volání s chybou (od tohoto volání se návrat neočekává); poté už je jedinou možností proces zabít.

Kousek za bodem, odkud není návratu, musí execve() upravit „charakter“ [personality] procesu, aby odpovídal spustitelnému obrazu. Například 64bitový proces, který se přepíná na 32bitový obraz, musí přejít do 32bitového režimu. V minulosti byly charaktery využívány k emulaci jiných operačních prostředí – například ke spouštění binárek SYSV. Charakter mění mnoho aspektů prostředí, ve kterém program běží, ačkoliv, jak uvidíme, méně než dříve.

V minulosti změny charakteru zahrnovaly i změny jmenných prostorů souborového systému. To bylo nutné, protože proces nastartování nového spustitelného souboru mohl vyžadovat dohledání dalších obrazů, například obraz interpreteru, který nový program spustí. Toto vyhledání muselo proběhnout před bodem, odkud není návratu; pokud selhalo, mělo selhat i systémové volání. Některé aspekty prostředí nového obrazu tedy musely být přítomny, i když ještě proces běžel v kontextu obrazu starého.

V té době bylo řešením přidat několik brutálních hacků do nízkoúrovňového makra SET_PERSONALITY(). Úkolem tohoto makra je přepnout proces na nový charakter, ale po tomto hacku to již nedělalo. Místo toho provedlo pouze změny jmenných prostorů a většinu prostředí nechalo beze změny s tím, že byl úloze nastaven zvláštní příznak TIF_ABI_PENDING, který jádru připomínal, že je později potřeba změnu charakteru dokončit. Postupem času byly změny jmenných prostorů z jádra vyňaty, ale tento dvoukrokový mechanismus změny charakteru zůstal.

Tyto triky umožnily zavolat SET_PERSONALITY() před bodem, odkud není návratu, aniž by se narušil proces odstranění starého obrazu. Co ale chybělo, byl nějaký mechanismus, který by plně obnovil starý charakter, pokud by se věci po volání SET_PERSONALITY() změnily. Efektivně se z tohoto volání stal skutečný bod, odkud není návratu, protože po něm jádro už nemělo způsob, jak se vrátit k předchozímu stavu.

Není mnoho způsobů, jak by execve() mohlo mezi voláním SET_PERSONALITY() a oficiálním bodem, odkud není návratu, selhat. Jeden ale stačí a jeden snadno přístupný způsob selhání je neschopnost najít pro nový obraz interpreter. Interpreter nemusí být spustitelný soubor, ve skutečnosti se jedná o prostředí pro běh jako celek. 32bitový proces přitom nemá žádnou možnost, jak spustit 64bitový obraz; pokus to udělat vede k selhání přesně ve špatné části volání execve(). Řízení se vrátí volajícímu programu, ale nastavení charakteru je zčásti narušené.

Nejčastější reakce na selhání execve() bývá informování uživatele a ukončení; volající program neočekával, že by běžel dál, takže se obvykle prostě ukončí – pravděpodobně si tedy nikdo nevšimne toho, že chvíli běžel se schizofrenním charakterem. Jestliže ale místo toho volající program přijme signál, který vyvolá core dump, zmatené informace o charakteru vedou k odpovídajícím způsobem zmatenému jádru a panice.

Když to shrneme, máme zde kombinaci záludného kódu zhoršenou záležitostmi ohledně kompatibility mezi architekturami, jenž implementuje chování, které již není zapotřebí – a dělá to špatně. A aby to bylo zábavnější, problém byl nahlášen v prosinci, ale nikdo si ho nevšiml a zůstal bez opravy.

První řešení navržené Linusem bylo jednoduše odebrat brzké volání SET_PERSONALITY(). Po nějaké diskuzi se ale Linus a H. Peter Anvin shodli, že bude lepší kód skutečně opravit. Výsledkem je dvojice patchů, první dělí flush_old_exec() (která hluboko uvnitř obsahuje bod, odkud není návratu) na dvě funkce, jež mají být spuštěny před a za tímto bodem. Tento patch se také zbavuje brzkého volání SET_PERSONALITY(). Druhý patch poté eliminuje hack TIF_ABI_PENDING a jednoduše provádí kompletní změnu charakteru v bodě, odkud není návratu.

Tyto změny byly začleněny těsně před vydáním 2.6.33-rc6. Jedná se o poměrně významné patche na to, aby byly vloženy v takto pozdním stádiu vývojového cyklu 2.6.33. A skutečně způsobily určité problémy, obzvláště na ne-x86 architekturách. Distributoři, kteří budou chtít tuto opravu portovat na starší jádra, možná budou hledat způsob, jak je zjednodušit. Bezpečnostní opravy jsou ale důležité a opravy, které se zbavují kódu opředeného pavučinami, jenž může skrývat další problémy, jsou ještě lepší. Zbývající problémy by měly být brzy vyřešeny a jádro 2.6.33 bude o to lepší.

       

Komentáře

[Michal Ludvig]

Citáty mi dneska daly zabrat... V jednom se mluví o nějakém "usond" a teprve po několikátém přečtení mi došlo že je to uprobe. No dobře, takže přepínám na fanaticky-ultra-český mód abych zbytku jaderných novin porozumněl a čtu dál. "Forky nejsou vždycky skvělé, ale upřímně je nepovažuji za špatnou věc a v Googlu jsem se pokusil tuto etiku vštěpovat." Sakra jaký fórky? Vzpomněl jsem si na "printer on fire" a podobné srandičky ale co s tím zase má společného google?! Čtu to podruhý, potřetí, AHA! Jsou to forky a ne fórky!!

Když musíme mít usondy tak si pro příště místo forků vyprošuju vidličky.

[Robert Krátký]

O usondách vs. uprobes se mluvilo pod předminulým dílem.

[guest]

a co tak pisat za prekladom (napr. do zatvorky, kurzivou) anglicky original? ci uz pre lepsie pochopenie alebo lepsie hladanie... :)

[Robert Krátký]

Tak to také ve většině případů je. Tentokrát to vypadlo asi právě kvůli tomu, jak se to probíralo minule.

[Robert Krátký]

Dal jsem tam místo toho odkaz.

[neaktivni]

Primlouvam se za original v zavorce. Precejenom je to prehlednejsi a rozhodne je to jednodussi a prijemnejsi, nez se ucit kazdy termin jeste v cestine (a v pripade jineho prekladatele navic v ruznych tvarech).

[Roger]

A já si vyprošuju shodu podmětu s přísudkem - "jak správci některé forky přitáhli zpátky (a jiné nechaly dělat si svoje)". Dík :)

[zulu]

správcy, neasi :)

[frr]

K tomu read-aheadu, ona to v Linuxu skutečně není žádná sláva. A mám pocit, že než aby vývojáři vymýšleli principiálně nedosažitelný univerzální algoritmus, který by fungoval od SD karty po špičkový externí RAID, měli by přihodit hrst laditelných proměnných do sysfs - třeba per block device nebo per mountpoint. On by si to pak každý mohl doladit podle svého, nějakou lepší chytristiku by mohl přihodit třeba UDEV apod. Než vyrábět v kernelu složitou heuristiku, která by se to snažila "odvodit z charakteristik protékající zátěže", proč nedat možnost uživateli, aby si řekl přesně, kterým směrem optimalizovat?
V debatě zásadně postrádám nuance jako zarovnání read-ahead transakcí na hranice strajpů u RAIDů (námět na jednu laditelnou proměnnou) nebo zmínku o tom, že při sekvenčním čtení skrz filesystém je potřeba jiný read-ahead na payload souboru a jiný na metadata (takže jediná hodnota udaná pro blokové zařízení je v principu blbě), a že pro optimální rychlost sekvenčního čtení by měl být k dispozici filesystém, který bude generovat minimum "nesekvenčních" seeků pro načítání metadat... optimální FS by musel mít metadata buď sekvenčně prokládaná v payloadu (snad BTRFS?), nebo by je musel mít v nějaké tabulce bokem (FAT64/EXFAT?) která se drží v RAM.
Pokud Linus osobně opakovaně tvrdí, že jeho benchmarkovou platformou je desktop na něčím pecku, a řeší se Window Manager, který dokolečka přepisuje maličký konfigurační soubor, tak těžko může být VM+FS+IOsched zároveň dobře optimalizovaný pro průchodnost serveru, který streamuje stovky paralelních downloadů velkých sekvenčních souborů. (Další laditelná proměnná: přednačtená data, poté co je user-space proces přijme voláním read(), není třeba dále kešovat, a lze je ihned zahodit.) A pak ty hlášky o "složitosti patchů pro zlepšení read-aheadu, ze které jdou oči šejdrem" - možná je to jenom projev toho, že ten problém skutečně *je* složitý, jednoduché recepty "na bázi nedbalé elegance" na něj nezabírají, je třeba ho řešit úpravami několika subsystémů kernelu ve vzájemné koordinaci.

[x14]

Dopředné čtení je prima - držím palečky. Mám hafo nevyužité paměti, když se rozumně použije, bude to super. Ale hlavně ať to nedopadne jako SuperFetch ve Vistách, to se občas chová vyloženě tragicky.

[geebranz]

Responsible site

smallbusinessloansamarillo.com