abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 22:22 | Komunita

Společnost Purism představila kryptografický token Librem Key. Koupit jej lze za 59 dolarů. Token byl vyvinut ve spolupráci se společností Nitrokey a poskytuje jak OpenPGP čipovou kartu, tak zabezpečení bootování notebooků Librem a také dalších notebooků s open source firmwarem Heads.

Ladislav Hagara | Komentářů: 0
dnes 20:33 | Nová verze

Společnost NVIDIA oficiálně vydala verzi 10.0 toolkitu CUDA (Wikipedie) umožňujícího vývoj aplikací běžících na jejich grafických kartách. Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
dnes 20:00 | Upozornění

Příspěvek Jak přežít plánovanou údržbu DNS na blogu zaměstnanců CZ.NIC upozorňuje na historicky poprvé podepsání DNS root zóny novým klíčem dne 11. října 2018 v 18:00. Software, který nebude po tomto okamžiku obsahovat nový DNSSEC root klíč, nebude schopen resolvovat žádná data. Druhým důležitým datem je 1. února 2019, kdy významní výrobci DNS softwaru, také historicky poprvé, přestanou podporovat servery, které porušují DNS standard

… více »
Ladislav Hagara | Komentářů: 0
dnes 15:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 156. brněnský sraz, který proběhne v pátek 21. září od 18:00 v restauraci Na Purkyňce na adrese Purkyňova 80.

Ladislav Hagara | Komentářů: 0
dnes 13:22 | Nová verze

Alan Griffiths z Canonicalu oznámil vydání verze 1.0.0 display serveru Mir (GitHub, Wikipedie). Mir byl představen v březnu 2013 jako náhrada X serveru a alternativa k Waylandu. Dnes Mir běží nad Waylandem a cílen je na internet věcí (IoT).

Ladislav Hagara | Komentářů: 0
včera 22:00 | Nasazení Linuxu
Stabilní aktualizace Chrome OS 69 (resp. Chromium OS), konkrétně 69.0.3497.95, přináší mj. podporu linuxových aplikací. Implementována je pomocí virtualizace, a proto je tato funkce také omezena na zařízení s dostatkem paměti a podporou hardwarové akcelerace, tudíž nejsou podporovány chromebooky s 32bitovými architekturami ARM, či Intel Bay Trail (tzn. bez Intel VT-x).
Fluttershy, yay! | Komentářů: 5
včera 21:32 | Zajímavý projekt
Došlo k uvolnění linuxové distribuce CLIP OS, vyvíjené francouzským úřadem pro kybernetickou bezpečnost ANSSI, jako open source. Vznikla za účelem nasazení v úřadech, kde je potřeba omezit přístup k důvěrným datům. Je založená na Gentoo.
Fluttershy, yay! | Komentářů: 1
včera 16:00 | Komerce

Zjistěte více o bezpečné a flexibilní architektuře v cloudu! IBM Cloud poskytuje bezpečné úložiště pro Vaše obchodní data s možností škálovatelnosti a flexibilitou ukládání dat. Zároveň nabízí prostředky pro jejich analýzu, vizualizaci, reporting a podporu rozhodování.

… více »
Fluttershy, yay! | Komentářů: 12
včera 12:22 | Nová verze

V dubnu letošního roku Mozilla představila webový prohlížeč pro rozšířenou a virtuální realitu Firefox Reality (GitHub). V úterý oznámila vydání verze 1.0. Ukázka na YouTube. Firefox Reality je k dispozici pro Viveport, Oculus a Daydream.

Ladislav Hagara | Komentářů: 2
včera 12:00 | Komunita

V srpnu loňského roku společnost Oracle oznámila, že Java EE (Enterprise Edition) bude uvolněna jako open source. O měsíc později bylo rozhodnuto, že tato open source Java EE bude přejmenována a předána Eclipse Foundation. Nové jméno bylo oznámeno v únoru letošního roku. Z Java EE se stala Jakarta EE. Eclipse Foundation včera oznámila dosažení dalšího milníku. Zdrojové kódy aplikačního serveru GlassFish jsou již k dispozici v git repozitářích Eclipse Foundation (GitHub).

Ladislav Hagara | Komentářů: 0
Na optické médium (CD, DVD, BD aj.) jsem naposledy vypaloval(a) data před méně než
 (13%)
 (14%)
 (21%)
 (23%)
 (25%)
 (4%)
 (1%)
Celkem 384 hlasů
 Komentářů: 33, poslední 16.9. 11:55
Rozcestník

Jaderné noviny – 24. 12. 2014: Dokončení začleňovacího okna verze 3.19

9. 3. 2015 | Tadeáš Pelech | Jaderné noviny | 3599×

Stav vydání jádra. Živé opravy jádra chystané do verze 3.20. Pravidlo alokace paměti „příliš malé na selhání“.

Obsah

Stav vydání jádra

link

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.

Živé opravy jádra chystané do verze 3.20

link

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.

Dokončení začleňovacího okna 3.19

link

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:

  • Zpracování systémového volání setgroups() v uživatelském jmenném prostoru bylo změněno tak, že potenciálně hrozilo poškození některých aplikací, další informace najdete v tomto článku.
  • Souborový systém Ceph nyní podporuje inline data, což zvyšuje výkon u malých souborů. Ceph také podporuje podepisování zpráv k ověřování mezi klienty a servery.
  • Byla odebrána podpora virtualizace KVM pro architekturu Itanium (ia64). Nebyla udržována a pravděpodobně ji už nikdo nepoužívá.
  • Vrstva InfiniBand získala podporu pro vyžádané stránkování. Tato funkce umožňuje nastavit a naplnit oblast RDMA prostřednictvím chyb stránek ve chvíli skutečného použití paměti, čímž odpadne nutnost zabírání velkého objemu paměti, která nemusí být nikdy potřeba.
  • Podpora nového hardwaru zahrnuje:
    • Vstup: Trackpady ELAN I2C/SMbus, dotykové displeje Goodix I2C a Elan eKTH I2C.
    • Různé: Flash NAND s SoC Allwinner, řadiče pulsně šířkového modulátoru (PWM) Broadcom BCM2835 a řadiče PWM Atmel HLCDC.
    • Tepelné: Podpora obecného chlazení zařízení prostřednictvím úprav frekvence časovače, tepelných řídicích systémů NVIDIA Tegra SOCTHERM a Rockchip.

Mezi změny viditelné pro vývojáře jádra patří:

  • Kód odstraňování modulů byl přepracován, aby se eliminovala volání hodně problematické funkce stop_machine(). V rámci toho došlo k mírnému zpomalení počítání odkazů na moduly, předpokládá se ale, že nikdo si nehraje s počty odkazů tak často, aby byl tento rozdíl znatelný.
  • Z jádra byl konečně odstraněn konfigurační symbol CONFIG_PM_RUNTIME, nyní se používá výhradně CONFIG_PM.
  • Makra READ_ONCE() a ASSIGN_ONCE() (popsána v tomto článku) byla zahrnuta v posledná dávce před uzavřením začleňovacího okna. Tato makra vynucují používání neskalárních typů, což nás doufejme zbaví problémů se záludnými chybami kompilátoru.

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.

Pravidlo alokace paměti „příliš malé na selhání“

link

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:

  1. Proces, který aktuálně používá relativně málo paměti, vyvolá operaci souborového systému XFS, která zase k pokračování musí provést alokaci.
  2. Subsystém řízení paměti se tuto alokaci snaží uspokojit, ale zjistí, že není k dispozici žádná paměť. Zareaguje tak, že se nejprve pokusí o přímé opětovné získání (přinutí stránky opustit paměť, aby je uvolnil), pak, pokud tím nezíská potřebnou paměť, vrací se k procesu ukončování z důvodu nedostatku paměti (OOM killer).
  3. OOM killer si vybere oběť a pokusí se ji ukončit.
  4. Aby mohla být tato oběť ukončena, musí provést některé operace ve stejném souborovém systému XFS. To v tomto případě znamená získání zámku, který v současné době drží proces provádějící onu problematickou alokaci paměti. Všechno se zastaví.

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.

       

Hodnocení: 100 %

        špatnédobré        

Nástroje: Tisk bez diskuse

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

10.3.2015 06:59 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Uživatelský obor názvů
Někdo by čekal, že se překladatel začervená a příště si dá pozor. Přesto ani tentokrát jsme nebyli ochuzeni o „uživatelský obor názvů“ (user namespace).
10.3.2015 14:47 Jindřich Makovička | skóre: 15
Rozbalit Rozbalit vše Re: Uživatelský obor názvů
Já bych překladatele pochválil za zlepšení, tohle vydání už na rozdíl od minulého není write-only.
10.3.2015 18:03 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Uživatelský obor názvů
Oproti minulému dílu to je rozhodně velké zlepšení, jen tak dál.
11.3.2015 22:21 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Uživatelský obor názvů
To ano. Výrazně zlepšení lze pozorovat.
Otto Šabart avatar 13.3.2015 20:06 Otto Šabart | skóre: 13 | blog: KatiePC blog | Rychnov nad Kněžnou | Brno
Rozbalit Rozbalit vše Re: Jaderné noviny – 24. 12. 2014: Dokončení začleňovacího okna verze 3.19
Chválím překladatele a děkuji :). I když se jedná pouze o překlad, tak jaderné noviny jsou jedna z mála věcí co přidává tomuto portálu informační hodnotu...
*´¨)¸.·´¨)¸.·***·>>> www.seberm.com

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.