Portál AbcLinuxu, 6. května 2025 20:16
Aktuální verze vývojového jádra: 3.18-rc3. Podpora hybridních disků SSD. Podpora atomického nastavování režimu pro ovladače KMS. Pokračování podpory Linuxu 3.16.y.z. Podpora hybridních disků SSD. Příznaky open(): O_TMPFILE a O_BENEATH.
Aktuální vývojové jádro je 3.18-rc3, vydané 2. listopadu (oznámení). Linus si postěžoval, že se situace nezklidňuje, jak by si přál, ale že mu to nedělá příliš starosti:
To znamená, že si nemyslím, že by snad docházelo k něčemu obzvlášť hroznému. Spousty a spousty drobností, většinou jde o ovladače (jak v počtu zápisů, tak v počtu řádků), ale objevuje se i něco kolem sítí a jádra. Nic nijak zvlášť nevyčnívá.
S tímto prepatchem se kódové jméno vydání změnilo na „Diseased Newt“.
Stabilní aktualizace: Aktualizace verzí 3.17.2, 3.16.7, 3.14.23, a 3.10.59 byly vydány dne 30. října.
Pro ty, kdo si libují v nechutných podrobnostech o zprovoznění nových operací atomického nastavování režimu pracujících s existujícími ovladači grafických adaptérů, má Daniel Vetter exkluzivní zprávu:
Tak jsem jen znovu zveřejnil svůj seriál o pomocníku atomického nastavování režimu, a protože hlavním cílem celé té práce bylo zajistit hladký a jednoduchý přechod stávajících ovladačů do země zaslíbené atomickému zpracování, je na čase trochu to rozvést. Velkým problémem je, že stávající pomocné knihovny a zpětná volání do backendů řadičů příliš neodpovídají nové sémantice, takže bylo provést několik úprav, abychom předešli dlouhodobým problémům. Pokud programujete ovladače a chcete se dozvědět podrobnosti, přečtěte si, co musíte udělat pro podporu atomických aktualizací nastavení režimu pomocí těchto nových pomocných knihoven.
Jaderný tým Ubuntu oznámil, že bude poskytovat prodlouženou podporu jádra řady 3.16. Tým naváže tam, kde přestal Greg Kroah-Hartman, u verze 3.16.7, a bude poskytovat podporu až do dubna 2016.
V posledních letech jsme byli svědky přidání řady subsystémů do jádra, které poskytují vysokorychlostní mezipaměť pro data na (relativně) pomalých jednotkách; patří mezi ně bcache nebo dm-cache. Ale výrobcům disků nebrání nic v tom, aby do svých výrobků přímo vestavěli tento způsob ukládání do mezipaměti. Výsledkem takového spojení jsou „hybridní disky SSD“ – rotační disky, které obsahují také nějaké úložiště typu flash. Pokud se taková paměť správně používá, může zrychlit přístup k často používaným datům. Ale ukazuje se, že „správně si zvyknout“ není tak jednoduché, jak by si člověk mohl myslet.
Samozřejmě můžete všechno nechat na vlastní jednotce. Pokud disk ponecháte jeho osudu (tak říkajíc), bude sledovat, ke kterým blokům se často přistupuje, a bude se snažit ukládat je do rychlého úložiště. Ale operační systém – nebo programy v něm spuštěné – mají často lepší představu o tom, která data bude potřebovat v budoucnu. Pokud tyto informace předává jednotkám, výsledkem by mělo být lepší využití rychlého ukládání, a tedy lepší výkon.
Umožnění této komunikace je cílem této sady oprav, předložené Jasonem Akersem. Z reakce na tuto sadu oprav od komunity jádra je ale jasné, že je stále ještě potřeba zapracovat na zjištění nejlepšího způsobu, jak z takových jednotek získat nejlepší možný výkon.
Tato sada záplat používá hodnotu priority podle procesu I/O jako způsob signální informace o využití mezipaměti. Tuto prioritu je možné nastavit pomocí příkazu ionice. Pomocí pár bitů pole priorita může uživatel zadat jednu z řady zásad (zde uvedeny v symbolické podobě):
Tato sada oprav nebude v současném stavu do jádra v dohledné době začleněna hned z několika důvodů. Jedním z nich je, jak upozornilo několik vývojářů, že sdružuje vstupně-výstupní zásady ukládání do mezipaměti s procesem poněkud nezvykle. Jednotlivé procesy mohou vyžadovat různé zásady ukládání do mezipaměti pro různé soubory se kterými pracují; dokonce mohou vyžadovat různé zásady pro různé části jednoho souboru. Kvůli vytvoření jediné zásady na proces je tento způsob použití téměř nemožný.
Kromě toho, jak poukázal Dave Chinner, proces, který generuje vstupně-výstupní operace v uživatelském prostoru, nemusí být shodný s procesem, který odešle I/O do blokového subsystému. Mnoho souborových systémů používá k provádění skutečného odeslání pracovní podprocesy. Tím se přeruší vazba s procesem, který vstupně-výstupní operaci původně vytvořil. Souborové systémy také mohou chtít upravit zásady ukládání do mezipaměti – nabízí se například možnost, že budou dávat vyšší prioritu pro ukládání do mezipaměti metadatům než datům. Skutečnost je taková, že souborový systém má možnost upravit hodnotu priority I/O u jednotlivých požadavků, ale není to nejelegantnější API.
Z těchto důvodů někteří vývojáři navrhují, aby zásady ukládání do mezipaměti byly nastavovány na úrovni souboru v systémovém volání jako fadvise(), a nikoli na úrovni procesů. Ještě lepší by bylo, jak poznamenal Jens Axboe, přidat mechanismus, který by procesům umožnil poskytnout doporučení na úrovni operací. Tento přístup použitý v návrhu neblokovaného čtení z vyrovnávací paměti může být vhodný pro tento typ využití.
S touto sadou oprav je ale ještě jeden problém: typy „poradenství“, které lze poskytovat, jsou pevně vázané na specifikace způsobu práce současné generace hybridních disků. Nabízí pouze nízkoúrovňové kontrolu nad jedinou úrovní mezipaměti. Budoucí disky mohou pracovat jinými způsoby, které výše popsaným operacím nemusí vyhovovat. Hybridní disky navíc nejsou jediným místem, kde může být k dispozici tento druh poradenství; může být také užitečné pro NFS 4.2, zařízení s perzistentní pamětí nebo nastupující „značkovací deskriptory logických bloků“ T10/T13. Obecně platí, že je nejlepší vyhnout se začleňování takových řešení, která fungují jen s jedním druhem současné technologie, které ale nebudou mít žádný význam pro jiné technologie.
Martin Petersen věnoval docela dost času hledání optimálního způsobu, jak poskytovat poradenství zařízením obecně. Jeho přístupem je vyhnout se konkrétním instrukcím („vyloučit tato data z mezipaměti“) a spíše popisovat, proč se daná operace I/O provádí. Své výsledky popsal jako „obrovskou pokroucenou spleť tabulky s poníky různých velikostí“, ve skutečnosti to ale zase tak složité není.
Tato tabulka obsahuje sadu tříd I/O a důsledky na výkon každé třídy. Uvádí třídu „transakce“ s přísnými požadavky na čas dokončení a latenci a vysokou pravděpodobností, že data budou přístupná opět v blízké budoucnosti. Třída „streamování“ také chce rychle dokončení příkazů, ale pravděpodobnost opětovného přístupu k datům je poměrně nízká. Následují třídy „metadata“ (jako transakce, ale s nižší pravděpodobností opětovné potřeby dat), „stránkování“, „data“ a „pozadí“ (která má nízkou naléhavost a nepotřebuje ukládání do mezipaměti).
V případě (nespecifikovaného) rozhraní API používajícího tyto třídy I/O může kód nízkoúrovňového ovladače namapovat třídu jakékoli konkrétní vstupně-výstupní operace na řádné doporučení pro hardware. Toto mapování může být ale trochu složitější, než by se zdálo, protože hardware je složitější. Navíc je tu problém konzistence přes různá zařízení; kdyby ovladače tyto třídy interpretovaly různě, může to způsobit významné rozdíly ve výkonu, a tím i vyvolat nespokojenost uživatelů.
Tyto problémy se ale musí vyřešit, pokud mají linuxové systémy řídit hybridní zařízení v jiném než výchozím režimu řízením samotným zařízením. Pokud bude vhodné API pro jádro a uživatelský prostor, přístup založený na třídách se zdá být dostatečně pružný pro co nejlepší využití možností hardwaru blízké budoucnosti. Potom to ale znamená, že se autoři oprav pro současné hybridní disky se budou muset vrátit a začít znovu.
V linuxovém systému se téměř nic neděje bez volání funkce open() nebo některé z jejích variant. Neexistuje žádný jiný způsob vytvoření nového nebo přístupu k existujícímu souboru. Z toho tedy vyplývá, že různé příznaky, které řídí chování open(), mají významný vliv na funkčnost systému jako celku. Podíváme se na dva konkrétní příznaky volání open(); jeden z nich byl do jádra přidán poměrně nedávno, zatímco druhý je stále ještě ve fázi návrhu.
Příznak O_TMPFILE se na těchto stránkách probíral několikrát; protože byl přidán poměrně ve spěchu, neprošel důkladnou revizí a došlo u něj k řadě problémů po začlenění. Koncept tohoto příznaku je celkem jednoduchý: požaduje vytvoření souboru bez přidružené položky adresáře. Je tedy určen pro dočasné soubory, které nebude otevírat jiný proces.
Eric Rannaud se nedávno zeptal: Co by se mělo stát, když proces provede následující volání:
int fd = open("/tmp", O_TMPFILE | O_RDWR, 0);
Příznaky požadují vytvoření dočasného souboru pro zápis, ale třetí argument (režim souboru) říká, že není žádný přístup (čtení nebo zápisu) povolen. Pokud k tomu dojde, POSIX se staví zcela jasně k případům, kdy je vytvořen soubor s běžným, příznakem O_CREAT: zadaný režim platí pouze po vytvoření souboru. Tedy, i když proces může vytvořit soubor, ke kterému nemůže obecně přímo přistupovat, může přesto získat funkční popisovač souboru při samotném vytvoření.
Vypadá to ale, že vytvoření souboru s příznakem O_TMPFILE takto nefunguje; režim souboru se aplikuje od začátku, takže volání open() uvedené výše selže. Takové chování se obecně považuje za chybu a Ericova oprava byla začleněna do verze 3.18-rc3. Objevilo se ale pár zajímavých poznámek, na které je dobré se podívat.
Podle jedné toto volání:
int fd = open("/tmp", O_TMPFILE | O_RDONLY, 0666);
se stejně nezdaří. Když byla implementována funkce O_TMPFILE, zdálo se, že není žádný případ použití dočasného souboru, do kterého nelze zapisovat, proto byl tento případ (O_TMPFILE s O_RDONLY) výslovně zakázán. Ale ukazuje se, že pro tento typ souboru existuje případ použití: atomické vytvoření prázdného souboru s konkrétní sadou rozšířených atributů. Volání open() bude následovat jeden nebo více volání fsetxattr(); když bude všechno připraveno, lze použít linkat() k zviditelnění souboru v souborovém systému. Linus zpočátku souhlasil, že by tento případ použití měl být podporován, ale později si to rozmyslel. Takže soubory O_TMPFILE jen pro čtení nejsou nadále podporovány.
Zajímavé na tom je, že původní chyba byla objevena při průzkumu související chyby glibc. Zdá se, že když se použije O_TMPFILE, argument režimu není do jádra vůbec předán. V případě open() u počítačů s architekturou x86-64 všechno funguje díky velké dávce štěstí: argument režimu je čirou náhodou umístěn ve správném registru, když glibc provádí volání do jádra. Volání openat() ale tak dobře nefunguje. Důsledkem je, že v aktuálních instalacích glibc nelze O_TMPFILE s openat() vůbec použít. Tato chyba je dobře srozumitelná a měla být brzy odstraněna.
Když vývojář provede volání openat(), obvykle očekává, že se otvíraný nebo vytvářený soubor bude nacházet v zadaném adresáři. Jak se ovšem často stává, překvapení nepřejí nepřipraveným. Potíže mohou pocházet z překvapivého symbolického odkazu nebo záměrně škodlivého vstupu; v každém případě to může vést k vytváření nebo otvírání souborů tam, kde by být neměly.
David Drysdale má řešení v podobě příznaku O_BENEATH pro openat(). Pokud je tento příznak součástí volání, soubor, k němuž se přistupuje, musí existovat v daném adresáři nebo v některém z jeho podadresářů. Uplatňování tohoto pravidla je vcelku jednoduché: zadaná cesta je omezena tak, aby nezačinala znakem „/“ ani neobsahovala znak „../“. Stejné podmínky musí splňovat všechny symbolické odkazy procházené při zjišťování cesty.
Tato funkce byla implementována v rámci sady oprav omezení přístupu souborového systému Capsicum. Ukazuje se, že však existují další potenciální uživatelé. Konkrétně při kombinaci s filtrem, bezpečných výpočtů (dále jen „seccomp“) lze O_BENEATH použít k bezpečnému poskytnutí adresáře, ve kterém může pracovat proces v sandboxu.
První námitky proti této opravě byly vyřešeny v aktuální verzi. Jedná se o poměrně jednoduchou a neinvazivní opravu, takže je reálná šance, že se dočkáme jejího zavedení do hlavního stromu v rámci některého z následujících začleňovacích oken.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.