Jaderné noviny - 42/2007

23. 11. 2007 | Jirka Bourek | Jaderné noviny | 3685×

Dohledání chyb při začleňování pomocí gitu. Omezení spotřeby paměti schedstatu. Signalizace nedostatku paměti. Stínové adresáře. Linux Security Modules bez modulů. Udržování ovladačů mimo jádro. Vyvažování realtimových (RT) vláken.

Obsah

• Dohledání chyb při začleňování pomocí gitu
• Omezení spotřeby paměti schedstatu
• Signalizace nedostatku paměti
• Stínové adresáře
• Linux Security Modules bez modulů
• Udržování ovladačů mimo jádro
• Vyvažování realtimových (RT) vláken

Následující obsah je © KernelTrap.

Dohledání chyb při začleňování pomocí gitu

16. říjen, originál

V krátké diskuzi o patchi nazvaném oprava chybného začlenění abhid si Al Viro všiml potíží při dohledávání, která sada změn [changeset] tento problém způsobila. Linusi, jaký je správný způsob, jak dohledávat takové záležitosti? Linus Torvalds, původní autor gitu, odpověděl: Obávám se, že obecně není jednoduché chyby vzniklé při začleňování odhalit. Následně navrhl několik obecných tipů, jak takové chyby dohledávat, s poznámkou, že jestliže někdo přijde s lepším způsobem, jak špatné začlenění odhalit, velmi rád si to poslechnu. V souvislosti s tímto konkrétním případem vysvětlil:

'-c' je pro obvyklé kombinované začlenění - každý soubor, který byl modifikován u obou předků, se změní na kombinaci diffů na obou stranách, zatímco soubor, který byl vzat ve své "celistvosti", je ignorován.

V tomto případě je to přesně to, co jsi chtěl. Je to však příliš ukecané na to, aby to bylo implicitní chování, a stejně může v tichosti dojít k chybnému začlenění, pokud si začleňovatel vybral pouze jednu stranu.

Obecně mám dojem, že '-c' je často dobré zkusit, pokud nemůžeš najít důvod nějaké změny v běžném commitu a máš podezření na chybu začlenění.

Omezení spotřeby paměti schedstatu

17. říjen, originál

Ve vlákně nazvaném schedstat potřebuje dietu nabídl Ken Chen patch, který omezuje spotřebu paměti. Řekl k němu, že schedstat je užitečný pro zkoumání chování plánovače CPU. Myslím si, že je výhodné mít ho zapnutý nepřetržitě, nicméně cena za jeho běh na produkčním systému je poněkud vysoká, hlavně kvůli počtu událostí, které sbírá, a také kvůli velké spotřebě paměti. Jeho patch změnil mnoho proměnných typu unsigned long na unsigned int s tím, že většina polí nepotřebuje plných 64 bitů na 64bitových architekturách. Přetečení po 4 miliardách událostí většinou nastane až za dlouhý čas a uživatelské nástroje můžou být udělány tak, aby se tomu přizpůsobily.

Ingo Molnár patch začlenil do svého vývojářského stromu plánovače s tím, že by mohly být udělány další změny - všimněte si, že současný -git má celou spoustu nových polí v /proc/sched, která se dají využít ke sledování přesného chování při vyvažování úloh [balancing of tasks]. Soubor může být vyčištěn zapsáním 0 pomocí echo, takže přetečení není problém. Většina těchto polí by také měla být unsigned int. (Teď jsou u64.)

Signalizace nedostatku paměti

19. říjen, originál

Marcelo Tossati, předchozí správce jádra 2.4, oživil diskuzi o přidání podpory pro upozorňování na nedostatek paměti do linuxového jádra: AIX obsahuje signál SIGDANGER, který aplikace upozorňuje, aby uvolnily část nepoužívané cachované paměti. Proběhlo několik diskuzí o implementaci něčeho takového do Linuxu, ale ničeho konkrétního dosaženo nebylo. V následné výzvě k diskuzi Marcelo dodal: Na straně kernelu Rik navrhl dva body upozornění - "bude se swapovat" ["about to swap"] pro desktopy a "dojde k OOM" ["about to OOM"] pro embedded zařízení. Rik van Riel pojmy vysvětlil:

První hranice - "chystáme se swapovat" - znamená, že aplikace uvolní paměť, kterou může. Například glibc vrátí kernelu uvolněnou [free()d] paměť, JVM spustí garbage collector, atd.

Druhá hranice - "došla nám paměť" - znamená, že první přístup selhal a systém potřebuje udělat něco dalšího. Na embedded systému bych očekával, že se některé aplikace ukončí nebo třeba restartují.

Stínové adresáře

19. říjen, originál

Jaroslav Sýkora zaslal sérii pěti patchů, které zajišťují jadernou část toho, co popsal jako stínové adresáře. Ukázal příklad, ve kterém použil FUSE k přístupu do komprimovaného souboru z příkazové řádky. Jeho první ukázka byla cat hello.zip^/hello.c, o které řekl: Znak "^" je únikový [escape] znak, který počítači řekne, aby se souborem zacházel jako s adresářem. Patch implementuje pouze přesměrování požadavku do jiného adresáře ("stínového adresáře"), do kterého musí být připojen FUSE server. Dekomprimace archivu je provedena zcela v uživatelském prostoru. Víc informací obsahuje dokumentační patch.

Byl ale upozorněn na četné problémy. Jan Engelhardt poznamenal: Špatné je, že znak ^ je platný znak pro jméno "souboru". Všechny znaky kromě "\0" a "/" jsou platné. V konečném důsledku není žádný kontrolní znak, který bys mohl použít. Později byl ve vlákně citován starší článek na lwn.net: Další větev, kterou vede Al Viro, se obává záležitostí kolem zamykání v tomto konceptu. Stejně jako většina unixových systémů, Linux nikdy nedovolil hard linky na adresáře, a to z mnoha důvodů. Článek se týkal diskuze o Reiser4, který se soubory zachází jako s adresáři. V současné diskuzi Al Viro dodal: Co se zaslaného patche týká, jak to vidím já, je práce s .. v takových adresářích úplně na houby. Navíc: jak budeš tento stínový strom udržovat synchronizovaný s hlavním, pokud někdo začne v tom druhém přejmenovávat? Nebo spustí mount --move nebo ...

Linux Security Modules bez modulů

20. říjen, originál

V krátkém pokračování dřívější diskuze o zásuvné bezpečnosti [pluggable security] se Thomas Fricaccia zamyslel nad důsledky pro různé bezpečnostní frameworky. Všiml jsem si návrhu Jamese Morrise odstranit LSM ve snaze ustanovit SELinux jako jediný bezpečnostní framework navěky amen, následovaný Linusovým konečným rozhodnutím, že LSM zůstane. Poté komentoval nedávno začleněný patch bránící načtení bezpečnostních modulů do běžícího kernelu: Pak jsem si ale všiml, že ačkoliv LSM zůstane, je uzavíráno bezpečnostním frameworkům mimo strom [out-of-tree]. Jaj! Od té doby sleduji uspěchané snahy zařadit SMACK, TOMOYO a AppArmor "do stromu". Linus Torvalds odpověděl:

Jo, to jsme řešili. Když mi to Andrew posílal. Říkal, že pro lidi ze SuSE je to v pořádku (AppArmor), ale souhlasím s tebou. Aplikoval jsem to, ale také jsem ochoten to klidně odstranit, pokud tu budou uživatelé mimo strom, které lidi tlačí k nezačleňování. Takže si v žádném případě nemyslím, že tohle je vyřešeno - prosím, pokračujte v diskuzi a připomínání. Rozhodně nepatřím do tábora, který si myslí, že LSM je potřeba mít "pod kontrolou", ale na druhou stranu se také nechystám vzít ten commit zpět, dokud pro to nebudou dobré reálné argumenty (ne jenom ty teoretické).

Například chápu tvrzení, že "skutečný" bezpečnostní model by měl chtít být zakompilován, aby nešel jen tak přebít z modulu. Samozřejmě, já osobně se snažím nepoužívat moduly vůbec, takže jsem divný a vůbec. Skutečná nasazení LSM modulů, prosím ozvěte se!

Udržování ovladačů mimo jádro

20. říjen, originál

Snažím se udržet některé ovladače aktuální s jádrem a první dva týdny po vydání jsou pro mě nejhorší. Není způsob, jak rozlišit současné git jádro od nejnovějšího vydání. Pouze po vydání rc1 mohu použít preprocesor ke kontrole LINUX_VERSION_CODE, popisoval Pavel Roskin svoji snahu udržovat ovladač MadWifi, který není v hlavním stromu, synchronní s nejnověji uvolněným jádrem. Rik Van Riel navrhl:

Považuj to za podnět k zaslání svého kódu pro začlenění s upstream jádrem. To, že jsou všechny běžné ovladače integrované do hlavní řady jádra, zjednodušuje uživatelům použití jejich hardwaru. Externí ovladače nejsou potíž jenom pro vývojáře.

To Pavel potvrdil: Pro MadWifi tenhle podnět už zafungoval, ovladač je začleněn v repozitáři wireless-2.6 pod jménem "ath5k". Stále na něm ale zbývá spousta práce a některé vlastnosti se v ovladači v jádře jen tak neobjeví, protože částečně závisí na vlastnostech čipové sady, které je třeba ještě odhalit reverse engineeringem. V odpovědi na Pavlovu původní otázku Dave Jones poznamenal, že ve Fedoře se vývoj mezi uvolněním nové verze a prvním rc další verze označuje jako "rc0".

Vyvažování realtimových (RT) vláken

20. říjen, originál

V součastnosti je vyvažování několika RT vláken (balancing of threads) v hlavní řadě jádra vcelku nefunkční - vlákno s vysokou prioritou, které je plánováno na CPU s vláknem o vyšší prioritě, může zbytečně čekat, zatímco by klidně mohlo běžet na CPU, které zpracovává vlákno o nižší prioritě, začal Steven Rostedt, když popisoval svoji sadu patchů, které zavádějí vylepšené vyvažování realtimeových úloh.

Vyvažování (nebo migrace) úloh je obecně umění. Je nutné počítat se spoustou záležitostí - cache line, NUMA a dalšími. To platí u obecných procesů, které očekávají vysokou propustnost, a migraci lze provést dávkově. Nicméně, když dojde na RT úlohy, skutečně je potřebujeme dostat na CPU, na kterém poběží, tak brzy, jak je to jen možné, i když by to znamenalo nějaké vyprazdňování cache-line. V současnosti může RT úloha čekat několik milisekund, než je naplánována pro běh, možná i déle. Vlákno migration není dost rychlé na to, aby se o RT úlohy staralo.

Steven popsal své testovací případy a četné problémy, kterých si všiml v současném vyvažovacím kódu: Abych tuhle záležitost vyřešil, změnil jsem vyvažování RT úloh z pasivní metody (vlákno migration) na aktivní. Tato metoda spočívá v protlačení nebo přerušení RT úloh, když jsou probuzeny nebo naplánovány.

       

Komentáře

[Jan Včelák]

Chybka: Stínové adresáře - poslední věta by měla být také označena jako citace. Mám pravdu?

[Prcek]

Jedna je take hned v prvni vete: oprava chybného začlení abhid

[trekker.dk]

Jo, máš pravdu. Za tím odkazem, kterým ta citace končí, je jeden </span>, který tam být ještě nemá.

[KofolaMaster]

Linux Security Modules bez modulů... Linux Torvalds odpověděl

Dakujem(e) za preklad! :)

[daviud]

AIX ne AIC

[rastos]

Skutečná nasazení LSM modulů, prosím ozvěte se!

Sákriš. Mám doma na disku článok, ktorý som mal v pláne tu publikovať a ktorý hovorí o tom ako sa pohrabať v zdrojákoch jadra a upraviť si LSM ...

[trekker.dk]

AFAIK Linus ten commit nakonec vzal zpátky. Mám ten pocit, že se to píše v Jaderných novinách od Roberta a bude to i v překladech z kerneltrapu

Robertovy JN jsou časově totiž o něco napřed, než překlady zt kerneltrapu - tenhle článek konekrétně je měsíc starý.

[Robert Krátký]

tenhle článek konekrétně je měsíc starý.

Podotýkám, že to není Jirkova chyba - jen bylo nahromaděno několik dalších překladů z kerneltrap, které bylo nutné vydat dříve, aby to vyšlo chronologicky.