Jaderné noviny - 29. 11. 2006

27. 12. 2006 | Robert Krátký | Jaderné noviny | 5166×

Aktuální verze jádra: 2.6.19. Citát týdne: Michael Tiemann. Přepracování pracovních front. Jak předejít - a napravit - fragmentaci paměti. Souborové kvalifikace.

Aktuální verze jádra: 2.6.19

Aktuální stabilní jádro je 2.6.19, vydané 29. listopadu. Linus o něm napsal:

Je to jedno z těch vzácných "dokonalých" jader. Takže pokud se vám ho náhodou s vaší konfigurací nepodaří zkompilovat (nebo se zkompiluje, ale pak začne provádět nehorázné perverzity s vaším jezevčíkem), buďte klidní, neb si můžete být jisti, že je to všechno vaše chyba, a měli byste se nad sebou zamyslet.

Pokud jste nesledovali dění, tak vězte, že uživatelsky zajímavé změny v 2.6.19 jsou: subsystém pro ovladače paralelního ATA, souborové systémy GFS2 a ext4, hodně nových ovladačů, eCryptfs a další. Seznam interních změn API najdete na LWN kernel API page a KernelNewbies 2.6.19 page, kde je spousta podrobností.

Aktuální verze -mm stromu je 2.6.19-rc6-mm2. Mezi nedávné změny patří vyladění ovladačového jádra, podpora uspávání/probouzení v několika ovladačích PATA, patch s kvalifikacemi u souborů (vizte níže) a počítání I/O u jednotlivých úloh.

Co se týče starších jader řady 2.6: aktuální 2.6.18 jádro je 2.6.18.4, vydané 29. listopadu. Obsahuje jedinou opravu: přetečení bufferu v kódu síťových mostů.

Adrian Bunk vydal 2.6.16.33 a 2.6.16.34 s několika opravami a pár novými ovladači (v .34).

Citát týdne: Michael Tiemann

Mám za to, že důvodem tak úžasného vývoje u věcí jako je třeba linuxové jádro je, kromě jiného, průhlednost a jednoduchost způsobu vedení.

-- Michael Tiemann

Přepracování pracovních front

Mechanismus pracovních front jadernému kódu umožňuje odložit zpracovávání na později. Pracovní fronty charakterizuje existence jednoho nebo více dedikovaných procesů, které úlohy z fronty spouštějí; a protože je práce vykonávána v kontextu procesu, může spát. Pracovní fronty také dokáží pozdržet spuštění určitých úloh po dobu určenou volajícím. Používají se v mnoha částech jádra.

David Howells si při nedávném pohledu na pracovní fronty povšiml, že struktura work_struct, která popisuje úlohu, jež má být spuštěna, je dost velká. Na 64bitových strojích to může být až 96 bajtů. Na struktury, kterých může být velké množství, je to docela dost. Takže se rozhodl nalézt způsob, jak strukturu zmenšit. To se povedlo, ale za cenu několika změn v API pracovních front.

Příčiny té přílišné velikosti struct work_struct jsou:

• Struktura časovače vestavěná v každé z nich. Mnoho uživatelů používá pracovní fronty, ale často nepotřebují funkci pozdržení. Každá úloha ve frontě si však s sebou pro jistotu nese strukturu timer_list.
• Ukazatel na soukromá data, který je předáván vlastní pracovní funkci. Mnohé pracovní funkce ten ukazatel používají, ale často jej lze vypočítat z ukazatele work_struct pomocí container_of().
• Na uložení jediného bitu je používáno celé slovo [word]: příznak "čekající", který značí, že work_struct je právě ve frontě a čeká na spuštění.

David se věnoval každému z těchto problémů. Výsledkem jsou dva nové typy pracovních struktur (struct work_struct a struct delayed_work); z té první byl odstraněn časovač. Pryč je také ukazatel na soukromá data; pracovní funkce místo toho dostanou ukazatel na příslušnou strukturu work_struct (nebo delayed_work). Na odstranění slova držícího bit "čekající" bylo použito pár interních triků.

Díky tomu se změnilo skoro celé API. Položka v pracovní frontě může být nově deklarována dvěma způsoby:

    typedef void (*work_func_t)(struct work_struct *work);

    DECLARE_WORK(name, func);
    DECLARE_DELAYED_WORK(name, func);

Změnil se prototyp pracovní funkce; teď je to ukazatel na příslušnou položku v pracovní frontě. Všimněte si, že ukazatel work_struct je předáván vždy, dokonce i v případě pozdržené úlohy. Vypadá to, jako by se měl programátor spolehnout na skutečnost, že struct work_struct je prvním polem struct delayed_work, takže container_of() byl měl fungovat podle očekávání. Alespoň dokud nikdo nezpřehází struct delayed_work.

U pracovních struktur, které musí být nastaveny na začátku, vypadají teď inicializační makra takto:

    INIT_WORK(struct work_struct work, work_func_t func);
    PREPARE_WORK(struct work_struct work, work_func_t func);
    INIT_DELAYED_WORK(struct delayed_work work, work_func_t func);
    PREPARE_DELAYED_WORK(struct delayed_work work, work_func_t func);

Verze INIT_* inicializují celou strukturu; musí být použity, když je struktura poprvé inicializována. Pak už mohou být používány mírně rychlejší verze PREPARE_*.

Funkce pro přidávání (a odebírání) položek do front teď vypadají takto:

    int queue_work(struct workqueue_struct *queue,
                   struct work_struct *work);
    int queue_delayed_work(struct workqueue_struct *queue,
                           struct delayed_work *work);
    int queue_delayed_work_on(int cpu,
                              struct workqueue_struct *queue,
                   	      struct delayed_work *work);
    int cancel_delayed_work(struct delayed_work *work);
    int cancel_rearming_delayed_work(struct delayed_work *work);

Zajímavé je, že David přidal další varianty deklarace pracovních front a inicializačních maker:

    DECLARE_WORK_NAR(name, func);
    DECLARE_DELAYED_WORK_NAR(name, func);
    INIT_WORK_NAR(name, func);
    INIT_DELAYED_WORK_NAR(name, func);
    PREPARE_WORK_NAR(name, func);
    PREPARE_DELAYED_WORK_NAR(name, func);

"NAR" znamená "non-auto-release [neuvolnit automaticky]." Za běžných okolností resetuje subsystém pracovních front příznak "čekající" před zavoláním pracovní funkce; to, mimo jiné, umožňuje, aby se funkce znovu vložila do fronty, kdyby to bylo třeba. Je-li však položka inicializována pomocí jednoho z uvedených maker, reset neproběhne a pracovní funkce pak musí příznak resetovat sama (zavoláním work_release()). Uváděným účelem je zabránění položce ve frontě, aby se uvolnila před tím, než je s ní pracovní funkce hotova - ale reset bitu "čekající" neobsahuje nic, co by takové uvolnění způsobilo. To bude také důvod, proč varianty _NAR nic nepoužívá.

Všechny tyto změny vyžadují hodně oprav v celém stromě jádra; to se nelíbilo Andrew Mortonovi, kterému se nedařilo všechny změny sladit s dalším zástupem patchů přichystaných pro začátek práce na 2.6.20. Andrew navrhl, aby byly patche týkající se pracovních front zařazeny až po vydání 2.6.20-rc1 - podobně, jako to bylo provedeno s prototypem funkcí zpracovávače přerušení v 2.6.19. Jenže Linus, kterému se patche s pracovní frontou líbí, by je raději zařadil dříve:

Já bych byl spíše pro zařazení před -rc1, protože si myslím, že minule dopadlo začleňování po -rc1 dost špatně (celá ta věc se zpracováváním IRQ parametrů). Odhalilo to příliš mnoho problémů příliš pozdě ve vývojovém cyklu. Raději bych o těch problémech věděl už ve chvíli vydání -rc1 a zachoval tak postup "všechny velké a ošklivé změny jsme provedli už před -rc1".

Takže to vypadá, že bude nalezen způsob, jak všechny kousky poskládat dohromady, a API pracovních front bude změněno už v -rc1.

Jak předejít - a napravit - fragmentaci paměti

Fragmentace paměti je linuxový programátorský problém s dlouhou historií. Při běhu systému jsou pro různé úkoly alokovány stránky, což po čase způsobuje fragmentaci. Vytížený systém s dlouhým uptimem může mít velmi málo fyzicky souvislých bloků stránek. Protože je Linux systém s virtuální pamětí, nepředstavuje fragmentace obyčejně žádný problém; fyzicky rozdrobená paměť může být virtuálně souvislá díky tabulkám stránek.

Ale existuje několik situací, při kterých je fyzicky souvislá paměť naprosto nutná. Patří k nim velké jaderné datové struktury (kromě těch, které byly vytvořeny pomocí vmalloc()) a jakákoliv paměť, která se musí jako souvislá jevit periferním zařízením. Klasickým příkladem jsou DMA buffery levných zařízení (těch, která neprovádějí scatter/gather I/O [rozhodit/posbírat]). Není-li k dispozici velký blok paměti ("high order"), když je ho třeba, dojde k chybě a další uživatel začne uvažovat o přechodu na BSD.

Během let se uvažovalo o mnoha přístupech k problému fragmentace, ale začleněn nebyl žádný. Přidávání jakékoliv režie k hlavnímu kódu správy paměti se těžko prosazuje. Ale tento odpor neznamená, že by to lidi vzdali. Jedním z nejvytrvalejších v této oblasti je Mel Gorman, který na anti-fragmentačním kódu pracuje již několik let. Teď se vrací s 27. verzí svého patche, který byl přejmenován na "seskupování stránek" [page clustering]. Tato verze vzbudila pozornost a do hlavního jádra by se mohla dostat.

Hlavním postřehem v Melově práci zůstává skutečnost, že některé druhy paměti je snazší získat zpět než jiné. Například stránka, která je uložena někde na disku, může být klidně vyhozena a použita znovu, kdežto stránka se strukturou úlohy procesu se nemůže hnout. Jedna tvrdohlavá stránka stačí k tomu, aby celý velký blok paměti nemohl být zkonsolidován a znovu využit coby fyzicky souvislý celek. Ale kdyby bylo možné udržet všechny snadno získatelné stránky pohromadě a nedotknutelné stránky ponechat v samostatné oblasti paměti, bylo by mnohem jednodušší vytvořit velké bloky volné paměti.

Takže Melův patch rozděluje každou zónu paměti na tři typy bloků: nezískatelný, snadno získatelný a přesunutelný. "Přesunutelný" typ je novou funkcí tohoto patche; používá se pro stránky, které mohou být snadno přesunuty na jiné místo pomocí jaderného mechanismu pro migraci stránek. V mnoha případech může být snazší stránku přesunout než získat zpět, protože není nutné využívat zálohovací zařízení. Seskupování stránek tímto způsobem by také mělo zajistit, že se velké bloky vytvoří samy, když je proces migrován z jednoho NUMA uzlu na druhý.

V této verzi patche tedy přesunutelné stránky (ty, které jsou označeny __GFP_MOVABLE) obyčejně náleží uživatelským procesům. Přesunutí uživatelské stránky je otázka pouhého zkopírování dat a změnění záznamu tabulky stránek, takže je to relativně jednoduché. Získatelné stránky (__GFP_RECLAIMABLE) naproti tomu většinou náleží jádru. Jde buď o alokace, u kterých se neočekává dlouhé trvání (například některé druhy DMA bufferů, které existují pouze po dobu I/O operace), nebo mohou být zahozeny, je-li to nutné (různé druhy keší). U všeho ostatního se předpokládá, že bude těžké to získat zpět.

Jednoduchým seskupováním různých druhů alokací se Melovi podařilo dosáhnout docela dobrých výsledků:

Při výkonnostních a zátěžových testech jsme zjistili, že ke konci testu je k dispozici 80 % v souvislých blocích. Pro srovnání, standardní jádro má na desktopu méně než 1 % paměti jako velké souvislé bloky a kolem 8 - 12 % paměti jako velké stránky na konci zátěžových testů.

Linus byl v minulosti obecně spíše proti snahám o snížení fragmentace paměti. Tentokrát však byly jeho komentáře mnohem podrobnější: měly by být alokace v základním nastavení považovány za přesunutelné nebo nepřesunutelné? Odpověď se zdá být "nepřesunutelné", protože se někdo musí pokaždé ujistit, jestli danou alokaci přesunout lze. Ale protože se teď diskuze odehrává na této úrovni, mohla by si nějaká forma předcházení fragmentaci do jádra najít cestu.

Související přístup k fragmentaci je mechanismus pro uvolňování stránek po kusech [lumpy reclaim mechanism] od Andyho Whitcrofta, který původně napsal Peter Zijlstra. Uvolňování stránek se v Linuxu normálně provádí pomocí seznamu LRU (least-recently-used = nejméně čerstvé použití); když už musí být stránka vyhozena, použije se taková, která v poslední době nebyla používána, což minimalizuje možnost, že by byla brzy potřeba. Tento mechanismus uvolňuje stránky náhodně rozmístěné ve fyzickém adresním prostoru, což ztěžuje vytváření větších bloků volné paměti.

Patch pro uvolňování po kusech se tento problém pokouší řešit mírnou úpravou LRU algoritmu. Když je potřeba paměť, vybere se další oběť z LRU seznamu jako obvykle. Uvolňovací kód se pak ale podívá na okolní stránky (dost na vytvoření většího bloku) a pokusí se je také získat. Pokud uspěje, vytvoří se rychle větší volný blok, ačkoliv bude uvolněn jen malý počet stránek.

Tento přístup by zcela zjevně lépe fungoval, kdyby okolní stránky mohly být uvolňovány. Proto by se dobře doplňoval se seskupovacím mechanismem - třeba s tím od Mela Gormana. Narušení LRU přístupu by mohlo mít výkonnostní následky, protože okolní stránky mohou být vytíženy, když se o ně uvolňovací kód pokouší. Pokusem o minimalizaci tohoto efektu je použití kouskového uvolňování pouze tehdy, když má jádro potíže s uspokojením požadavku na větší blok paměti.

Jestli - a kdy - budou tyto patche začleněny, to teprve uvidíme. Na patche ovlivňující jádro správy paměti je obvykle nahlíženo velmi opatrně; při vystavení reálným podmínkám mohou snadno způsobit spoustu zmatků. Problém se však sám nevyřeší, takže dříve či později se pravděpodobně něco v tomto směru stane.

Souborové kvalifikace

Model kvalifikací je docela dost lákavý. Nahrazuje bezpečnostní model "všechno nebo nic" (vyplývající z účtu roota) pomocí jemně rozlišených práv přesně popisujících, co může daný proces dělat. Linux už kvalifikace podporuje řadu let, ale z několika důvodů není tato funkcionalita moc využívána; vizte článek Pokus o vzkříšení kvalifikací v Linuxu.

Fakt, že nejsou kvalifikace příliš používány, neodradil vývojáře od snahy je vylepšit. Posledním pokusem jsou souborové kvalifikace od Serge Hallyna. Tento patch umožňuje administrátorovi systému přidávat specifické kvalifikace ke spustitelným souborům; když je soubor spuštěn, nastaví se kvalifikační masky procesu podle kvalifikací souboru. Funguje to tedy trochu jako setuid bit, ale s podrobnějšími možnostmi.

Na straně jádra jsou souborové kvalifikace řešeny pomocí mechanismu rozšířených atributů. K souboru se kvalifikace připojí nastavením atributu pojmenovaného security.capability; hodnotou atributu bude tato struktura:

    struct vfs_cap_data_disk {
	__le32 version;
	__le32 effective;
	__le32 permitted;
	__le32 inheritable;
    };

Pole version obsahuje aktuální verzi kvalifikace; ostatní tři očekávané masky kvalifikací.

Tato implementace má několik zajímavých vlastností:

• Lze se ptát, co by uživateli bránilo v nastavení rozšířeného atributu a získání kvalifikací, jaké jen by se mu zlíbily. Ačkoliv nastavování rozšířených atributů není privilegovaná operace, nastavování atributů, jejichž jméno začíná na "security.", ano. Takže pokud uživatel nemá práva roota, nebude schopen atributy kvalifikací nastavit. (Pro ty zvědavé: další vyhrazené atributy jsou trusted.*, které může zjišťovat nebo měnit pouze root, a user.*, které mohou být v některých situacích měněny pouze vlastníkem souboru).
• Kvalifikační masky uložené se souborem zcela přepíší aktuální kvalifikace procesu. Takže pokud root spustí soubor se sadou kvalifikací, může běžet s méně kvalifikacemi než obvykle.
• Nastavování kvalifikací je prováděno mimo kontrolu, jestli byly souborové systémy připojeny s parametrem nosuid. To by pravděpodobně mohlo systém otevřít útokům přes výměnný souborový systém vytvořený na jiném systému.

Pro práci se souborovými kvalifikacemi existuje sada uživatelských nástrojů; vizte filesystem capabilities page, kde najdete downloady, dokumentaci a příklady.

Než začnete oslavovat příchod souborových kvalifikací, stojí za to se zeptat, jestli administrátoři systémů opravdu potřebují dalších 31 (při posledním sčítání) bitů s právy - vynásobeno třemi samostatnými kvalifikačními maskami - ke správě každého spustitelného souboru v systému. Někdy může být obtížné udržet pořádek v právech souborů i bez kvalifikací. Systém plně založený na kvalifikacích by se komplexností blížil SELinuxu, takže by jej možná ani většina lidí spravovat neuměla. Dalo by se to však použít k nastavení omezených práv programům, které teď běží jako setuid root. V mnoha případech jsou práva roota nutná pouze k navázání na soket s nízkým číslem, upravení systémového času nebo provedení hrubého I/O. Omezení takového programu přiřazením pouze vyžadovaných kvalifikací by snížilo možnost, že bude použit k něčemu neočekávanému.

       

Komentáře