Portál AbcLinuxu, 25. dubna 2024 21:42
Stav vydání jádra. Živé opravy jádra chystané do verze 3.20. Pravidlo alokace paměti „příliš malé na selhání“.
Aktuální vývojové jádro je 3.19-rc1, vydané dne 20. prosince – o jeden den dříve, než se dalo očekávat.
Stabilní aktualizace: minulý týden nebyly vydány žádné stabilní aktualizace.
Uživatelé citliví na vypínání systému se už dlouho zajímají o možnost používání oprav do běžícího jádra bez nutnosti restartovat systém. K dispozici je několik řešení této funkce mimo hlavní strom; bylo jasné, že se do hlavního stromu nedostanou všechna. Podle nedávného požadavku od Jiřího Kosiny, aby byl strom oprav v reálném čase přidán do stromu linux-next, se zdá, že na této frontě došlo k jistému pokroku. Spolupracují zejména vývojáři kpatch a kGraft.
Základní funkcionalita (která je samostatná) nyní funguje a byla zkontrolována/schválena oběma zúčastněnými stranami (tedy lidmi pracujícími na kPatch a kGraft). Padla dohoda, že se stane společným základem, na kterém bude stavět další vývoj.
Nyní je v plánu pokusit se zahrnout toto společné jádro během začleňovacího okna verze 3.20. Potom snad konečně budeme mít podporu živých oprav jádra v hlavní větvi.
Podle obvyklé praxe mělo začleňovací okno verze 3.19 skončit 21. prosince, dva týdny po jeho otevření. Ale oslava slunovratu verzí 3.19-rc1 se nekonala; Linus se rozhodl uzavřít začleňovací okno o jeden den dříve. Mimo jiné argumentoval tím, že už dorazilo tolik práce, že vůbec nemělo smysl čekat na další.
Vzhledem k tomu, kolik toho dorazilo na samém konci, nechci už čekat na nikoho, kdo to nechává opravdu na poslední chvíli. Podle toho by se dalo říct, že už žádní další opozdilci nejsou – a soudě podle velikosti rc1, určitě už jich moc být nemohlo.
Jde opravdu o velmi rušný vývojový cyklus, během začleňovacího okna bylo zahrnuto 11 408 změnových sad. To je víc než během celého vývojového cyklu verze 3.18, kde bylo před konečným vydáním začleněno 11 379 změnových sad.
Od souhrnu z minulého týdne bylo převzato asi 1 000 změnových sad; některé zajímavější změny viditelné pro uživatele v této sadě jsou:
Mezi změny viditelné pro vývojáře jádra patří:
Pokud bude dodržen původní plán, finální verzi vydání jádra 3.19 lze očekávat někdy kolem poloviny března. Mezitím je ale potřeba zařídit spoustu testování a opravování – 11 400 nových změn určitě přineslo nějakou tu chybu. Podle všeho to nyní vypadá, že 3.19-rc1 je na tak rané vydání relativně stabilní, takže to nakonec i přes velký objem oprav může být další rychlý cyklus.
Vývojáři jádra jsou už dlouho upozorňováni, na to, že pokusy o alokaci paměti mohou – až na několik výjimek – selhat, pokud systém nemá dostatek prostředků. V důsledku toho provází každé volání funkcí jako kmalloc(), vmalloc() nebo __get_free_pages() doprovází důkladně promyšlený kód pro zpracování chyb. Ukazuje se ale, že chování skutečně zavedené do subsystému správy paměti se trochu liší od toho, co je napsáno v brožuře. Tento rozdíl může vést k nešťastnému chování při spuštění, ale oprava by mohla být ještě horší.
Diskuse na téma začala, když Tetsuo Handa zaslal dotaz, jak zpracovat konkrétní problém, na který narazil. Sled událostí vypadal nějak takto:
Proces alokace tedy nemůže pokračovat, protože čeká na výsledek svého volání alokace. Toto volání nemůže nic vrátit, dokud není uvolněna paměť, což vyžaduje ukončení procesu oběti. OOM killer bude také čekat na ukončení oběti, než se (možná) pokusí ukončit jiný proces. Ale proces oběti nelze ukončit, protože je pro něj nutné držet zámky od alokujícího procesu. Systém zamrzne a majitel systému začne vážně uvažovat o přechodu na nějakou verzi BSD.
Když se na tento problém zeptali správce XFS Dava Chinnera, hned se podivil, proč se kód pro správu paměti uchyluje k OOM killeru, místo aby prostě vyvolal selhání problematického přidělení paměti. Podle něj je kód XFS dobře připraven na řešení selhání alokace; domnívá se, že takový kód je lepší než ukončení náhodně vybraných procesů a blokování celého systému. Tehdy správce správy paměti Michal Hocko vypustil bombu prohlášením:
Bylo nepsaným pravidlem, že alokace GFP_KERNEL pro nejnižší (<=PAGE_ALLOC_COSTLY_ORDER) nikdy neselže. Jde už o dávné rozhodnutí, které by teď bylo obtížné opravit, aniž by se potichu narušilo spoustu kódu. Smutné...
Výsledná exploze zazněla v Daveově nevěřícně odpovědi:
Vždycky nám říkali, že přidělení paměti nemá zaručen úspěch, pokud není nastaveno __GFP_NOFAIL, ale to se už nepoužívá a nikdo nemá právo to dál používat.
Spousta závisí na tom, jestli se alokace paměti podaří nebo selže v případě nedostatku paměti. Patří mezi ně vyrovnávací paměť, takto závislé jsou tedy i všechny souborové systémy. Nepožadujeme výslovně, aby alokace paměti selhala, ale čekáme, že v případě nedostatku k nějakým selháním alokace paměti dojde. S tímhle na paměti jsme navrhovali a psali kód posledních 15 let.
Pravidlo alokace „příliš malé na selhání“ se u většiny jader týká jedné z osmi souvislých stránek nebo méně – což je docela dost. Nikdo si vlastně ani nepamatuje, kdy se pravidlo, že by tyto alokace neměly selhat, dostalo do jádra; vzniklo ještě před érou Gitu. Jak vysvětlil Johannes Weiner, předpokládalo se, že pokud by takové malé alokace paměti nemohly být uspokojeny, systém bude stejně tak nepoužitelný, že nebude možné stejně použít žádnou praktickou alternativu k vyvolání OOM killeru. Může tomu tak být, ale uzamčení systému v případě, kde je jádro připraveno vyřešit selhání alokace, také může způsobit nepoužitelnost systému.
Jednou alternativou, na kterou přišla řeč v diskusi, bylo přidat ke zvláštním žádostem o alokaci příznak __GFP_NORETRY. Tento příznak způsobí selhání žádosti i o malou alokaci, pokud nejsou k dispozici zdroje. Ale jak poznamenal Dave, snažit se opravit potenciálně vzájemně blokované požadavky pomocí __GFP_NORETRY je vytloukání klínu klínem; klínů stále přibývá a nakonec zvítězí.
Alternativou by bylo zbavit se pravidla „příliš malé na selhání“ a zařídit, aby alokační funkce pracovaly tak, jak od nich většina vývojářů jádra čeká. Johannesova zpráva obsahovala opravu posunující všechno tímto směrem; způsobuje ukončení nekonečných smyček o opětovné získání paměti (a selhání žádosti o alokaci), pokud se pokusům o přímé opětovné získání nepodaří skutečně uvolnit žádnou paměť. Ale poznamenal, že „pomyšlení na selhávání alokací po tak dlouhé době je děsivé.“
Je to děsivé z několika důvodů. Například ne všichni vývojáři jádra jsou natolik pilní, aby kontrolovali každou alokaci paměti a mysleli na náležitý postup obnovení. To ale není všechno – protože malé alokace neselhávají, neprovádí se nyní v jádře téměř žádný z tisíců postupů pro obnovu po chybě. Měly by se testovat, pokud by vývojáři používali platformu pro přidávání chyb jádra fault injection framework), ale v praxi se ukazuje, že to dodržuje jen hrstka vývojářů. Tyto postupy obnovy po chybě se tedy nejen nepoužívají a pomalu vyhnívají; navíc to vypadá, že nepříjemně velká část z nich zjevně nebyla ani nikdy vyzkoušena.
Pokud má být nepsané pravidlo „příliš malé na selhání“ zrušeno, začnou se všechny tyto postupy obnovy po chybě vůbec poprvé aktivně používat. V jádře by tak přibyly tisíce řádků netestovaného kódu, který se spouští jen za výjimečných okolností, kdy už se tak jako tak něco pokazilo. Nemůže být pochyb o tom, že se vynoří spousta skrytých chyb a potenciálních bezpečnostních problémů.
Tím se vývojáři správy paměti ocitnou v trochu prekérní situaci. Pokud zajistí, aby se funkce alokace paměti chovaly podle proklamací, zcela jistě tím v jádru způsobí řadu obtížně dohledatelných chyb. Stávající situace ale má také svoje stinné stránky, které se můžou zhoršovat s tím, jak bude zamykání jádra stále složitější. Také to významně plýtvá časem potřebným na vývoj kódu obnov po chybách, který nikdy nebude spuštěn. Zavedení chyb alokace při nedostatku paměti v tak pozdní fázi vývoje může být natolik děsivé, že se o ně ani nikdo nepokusí, i když by z dlouhodobého hlediska zaručilo lepší jádro.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.