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 01:33 | Nová verze

Po šesti letech od vydání verze 1.0 byla vydána verze 2.0 multiplatformního editoru tagů MusicBrainz Picard (Wikipedie). Přehled novinek, vylepšení a oprav v changelogu.

Ladislav Hagara | Komentářů: 0
včera 16:22 | Nová verze Ladislav Hagara | Komentářů: 6
včera 15:00 | Komunita

Dnes končí podpora Ubuntu 17.10 Artful Aardvark. Uživatelům je doporučen přechod na Ubuntu 18.04 Bionic Beaver s prodlouženou podporou do roku 2023. Podpora standardních verzí Ubuntu je 9 měsíců. Verze 17.10 byla vydána 19. října 2017.

Ladislav Hagara | Komentářů: 11
včera 13:33 | Bezpečnostní upozornění

Společnost Oracle vydala čtvrtletní bezpečnostní aktualizaci svých softwarových produktů (CPU, Critical Patch Update). Opraveno bylo celkově 334 bezpečnostních chyb. V Oracle Java SE je například opraveno 8 bezpečnostních chyb. Všechny jsou vzdáleně zneužitelné bez autentizace. V Oracle MySQL je opraveno 31 bezpečnostních chyb. Vzdáleně zneužitelných bez autentizace je 7 z nich.

Ladislav Hagara | Komentářů: 0
včera 13:11 | Zajímavý software

Nick Clifton zveřejnil na blogu společnosti Red Hat věnujícímu se počítačové bezpečnosti nástroj, pomocí kterého lze ověřit, zda jsou binární spustitelné soubory odolné vůči variantě 1 bezpečnostní chyby Spectre v procesorech.

Ladislav Hagara | Komentářů: 0
včera 03:00 | Nová verze

Po více než roce vývoje od vydání verze 1.12 byla vydána nová verze 1.13 Java edice počítačové hry Minecraft (Wikipedie). Kódový název nejnovější verze je Update Aquatic. Přehled novinek v oficiálním oznámení o vydání. Detailní přehled novinek na Gamepedii a na YouTube.

Ladislav Hagara | Komentářů: 4
18.7. 23:55 | Nová verze

Společnost Epic Games vydala verzi 4.20 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Přehled novinek i s celou řadou obrázků a videi v oznámení na blogu.

Ladislav Hagara | Komentářů: 0
18.7. 15:55 | IT novinky

Evropská komise uložila (pdf) společnosti Google pokutu ve výši 4,34 miliardy eur za porušení antimonopolních předpisů EU. Společnost Google ukládala od roku 2011 výrobcům zařízení Android a provozovatelům mobilních sítí protiprávní omezení, aby upevnila dominantní postavení svých produktů zaměřených na všeobecné vyhledávání na internetu.

Ladislav Hagara | Komentářů: 25
18.7. 13:55 | Zajímavý software

Byl vydán REAPER (Wikipedie) ve verzi 5.93. Jedná se o proprietární digitální pracovní stanici pro práci s audiem (DAW). Novinkou je experimentální linuxový port [reddit].

Ladislav Hagara | Komentářů: 2
18.7. 13:11 | Zajímavý software

Příspěvek na blogu Qt informuje, že Qt pro Python aneb modul PySide2 je již k dispozici v PyPI (Python Package Index). PySide2 je portací PySide na Qt 5 [Hacker News].

Ladislav Hagara | Komentářů: 2
Jak čtete delší texty z webových stránek?
 (77%)
 (20%)
 (5%)
 (7%)
 (2%)
 (10%)
Celkem 370 hlasů
 Komentářů: 40, poslední 29.6. 10:21
    Rozcestník

    Jaderné noviny - 10. 11. 2016: Nebezpečí printk()

    25. 11. 2016 | Redakce | Jaderné noviny | 2587×

    Stavy vydání jádra. Nebezpečí printk().

    Stav vydání jádra

    Současný vývojový kernel je 4.9-rc4 vydaný 5. listopadu. Linus k tomu řekl: „Nebudu vám lhát. Tohle není malé rc a byl bych raději, kdyby tomu bylo jinak. Ale ani to (pro tak velké) vydání není nepřiměřeně velké, takže bych si neměl začít dělat starosti. Zatím stále doufám, že skončíme s obvyklými sedmi kandidáty na vydání, tedy za předpokladu, že se věci zklidní. Uvidíme, jak to půjde, až se přiblížíme datu vydání.“

    Seznam z 6. listopadu obsahuje 17 známých regresí v jádře 4.9.

    Stabilní aktualizace: tento týden žádné nebyly vydány. Verze 4.8.7 a 4.4.31 byly v době psaní tohoto článku v procesu revidování, dostupné jsou od 10. listopadu.

    Nebezpečí printk()

    Někdo by mohl být v pokušení si myslet, že se toho o jaderné funkci printk() mnoho říct nedá. Vše, co dělá, koneckonců je, že dá řádek textu na výstup do konzole. Jenže printk() má své problémy. Během své přednášky na Kernel Summitu Sergej Senožatský řekl, že printk() ve stávající podobě prostě nemůže používat. Dodal však dobrou zprávu, že ona funkce není neopravitelná, ba dokonce je řešení problémů v plánu.

    Zamknutí systému prostřednictvím printk()

    Jedním z největších problémů spojených s printk() je deadlock, ke kterému může dojít vícero způsoby. Jedním z nich jsou reentrantní volání. Uvažujme vyvolání printk(), kterému zabrání nemaskovatelné přerušení (non-maskable interrupt, NMI). Obsluha tohoto NMI bude dost možná chtít něco vytisknout na výstup. NMI ostatně přísluší k mimořádným událostem. Jestliže první volání printk() drží nezbytný zámek, způsobí druhé volání při pokusu o získání stejného zámku deadlock. To je právě ten druh nepříjemnosti, kterému se vývojáři operačních systémů snaží zdaleka vyhnout.

    Tento konkrétní problém se podařilo vyřešit. printk() nyní má speciální buffer pro každé CPU, který se používá pro volání v kontextu NMI. Výstup přechází do tohoto bufferu a po skončení NMI je vymazán, čímž odpadá nutnost zabrat zámky, které volání printk() obvykle potřebuje.

    Tím ale výčet příležitostí k deadlocku printk() bohužel nekončí. Ukazuje se, že volání printk() mohou být rekurzivní, obvyklému zákazu rekurze v jádře navzdory. K rekurzivním voláním může dojít v důsledku varování vynořivších se z hlubin jádra. Ladění zámků bylo také zmíněno jako způsob, jak vytvořit volání printk() v nevhodnou dobu. Pokud dojde k volání printk() v nesprávnou dobu, výsledkem je rekurzivní volání, které může vyústit v deadlock způsobem analogickým tomu v případě zabraných volání.

    Tento problém vypadá podobně jako NMI, takže by nemělo být překvapením, že i řešení je podobné. Sergej přišel s návrhem rozšířit myšlenku řešení NMI, a sice vytvořit pro výstup printk() větší počet bufferů pro každé CPU. Kdykoli se printk() dostane do té části kódu, kde by mohlo k rekurzi dojít, výstup ze všech rekurzivních volání půjde do těchto bufferů, aby je šlo vyprázdnit, až to bude bezpečné. Nebezpečné oblasti jsou označeny novými funkcemi printk_safe_enter() a print_safe_exit(). Možná trochu matoucí je, že printk_safe_enter() neoznačuje bezpečnou oblast, nýbrž místo, kde má být použit „bezpečný“ kód pro výstup.

    Jelikož požadavek na buffery vyhrazené pro každé CPU vzniká ve stále více situacích, Peter Zijlstru zajímalo, zda by printk() neměl používat buffer pro určité CPU úplně vždycky. Sergej na to odpověděl, že se o tom uvažuje.

    Hannes Reinecke řekl, že část problému vyplývá ze dvou odlišných případů použití printk(): „pokec“ a „systém každou chvíli spadne.“ První případ může přijít na řadu kdykoli, zatímco ten druhý je urgentní. Při nedostatku lepších informací musí printk() předpokládat, že naléhavé je všechno, ačkoliv spousta problémů by se dala vyřešit pouhým odložením výstupů, které nejsou urgentní, na bezpečnější chvíli. Linus Torvalds poukázal na to, že argument úrovně logování by měl indikovat, kdy se jedná o naléhavý výstup, ale Peter opáčil, že odkládání nekritických výstupů má ke konečnému řešení daleko. Skutečný problém je podle něj v ovladačích konzole. Na toto téma znovu přišlo později.

    Jedním z problémů s odkládáním neurgentních výstupů je podle Sergeje skutečnost, že se může změnit pořadí zpráv, které později může být těžké znovu seřadit. Peter naznačil, že to není až tak velký problém, a Hannes poměrně důrazně prohlásil, že výstupy printk() na sobě mají časová razítka, takže jejich opětovné seřazení nebylo složité. Podle Linuse je problém v tom, že časová razítka se nemusí shodovat na různých CPU, tudíž pokud dojde k přesunu vlákna, pořadí zpráv může být chybné.

    Petr Mládek, který se k Sergejovi při přednášení připojil, řekl, že je tu problém s buffery pro každé CPU: v podstatě nutně budou menší než jediný globální buffer, což může omezit objem hromaděných dat k výstupu. Takže je pravděpodobnější, že systém s buffery pro každé CPU bude ztrácet zprávy. Bylo poukázáno, že subsystém ftrace tento problém už dávno vyřešil, ale za cenu spousty komplikovaného kódu pro cyklické buffery. Linus řekl, že jedna záležitost, se kterou je třeba zacházet opatrně, jsou zprávy oops, které jsou výsledkem pádu jádra – ty musí okamžitě jít do konzole.

    Sergej pokračoval tím, že deadlocků printk(), které je třeba vyřešit, je o poznání více. Dosud se debata týkala „vnitřních“ zámků, které jsou součástí printk(). Ovšem printk() musí často zabírat další zámky „venku“, v jiných částech jádra. Nejproblémovější oblastí se jeví posílání výstupu do konzole. V různých ovladačích sériových konzolí jsou zámky a související problémy, které mohou rovněž vést k deadlocku. Na rozdíl od vnitřních zámků ty externí printk() neovládá, takže tento problém je složitější na vyřešení.

    Jádro již má funkci printk_deferred(), která dělá vše pro to, aby se vyhnula externím zámkům a znovu odkládala výstupy na bezpečnější chvíle. Sergej navrhuje, aby se printk() vždy chovalo jako printk_deferred(), čímž by se mezi nimi setřel rozdíl a časem by šlo printk_deferred() odstranit. Jedinou výjimkou by byly nouzové výstupy, které by šly vždy přímo do konzole. Linus navrhl jít ještě dál, a odkládat i nouzové případy, ale vyprázdnit vyrovnávací paměti bezprostředně poté.

    Potíže s konzolí a další

    Nicméně zámky nejsou jediným problémem s printk(). Toto volání musí při vytisknutí příslušných zpráv zavolat ovladače konzole a nakonec také zavolat console_unlock(), čímž se krom jiného na konzoli pošle všechen zbývající výstup. Háček je v několika nešťastných vlastnostech této funkce: může se zacyklit, nemusí být možné jí zabránit v běhu a případná prodleva závisí na rychlosti konzole, která nemusí být vůbec rychlá. V důsledku tedy nikdo neví, kolik času vlastně volání printk() zabere, takže v řadě situací – namátkou atomický kontext, kritické sekce RCU, kontext přerušení aj. – ani není zcela bezpečné ho provádět.

    Jan Kára navrhl tento problém obejít tak, že printk() bude zcela asynchronní. Výstup by opět byl směřován do bufferu a do konzole odeslán později, ale v tomto případě by samotný zápis do konzole probíhal ve vyhrazeném jaderném vlákně. Volání printk() by prostě uložilo zprávu a pak použilo mechanismus irq_work k nastartování onoho vlákna. Tento návrh prošel prakticky bez námitek účastníků diskuze.

    Dále je tu problém s pr_cont(), což je varianta printk(), která se používá k vytisknutí jednoho řádku pomocí vícero volání. Tato funkce na SMP systémech není bezpečná – výsledek výstupu může být rozsypaný a poškozený. Bylo by sice velmi žádoucí zbavit se typu výstupu s „pokračováním řádky“, leč počet volání pr_cont() v jádře prudce roste, jak upozornil Sergej. Linus poukázal na to, že problém spočívá v absenci jiného pohodlného způsobu, jak z jádra vytisknout řádky s proměnlivou délkou. Je možné upravit pr_cont() například tak, aby byly využívány buffery pro každé CPU, ale hodilo by se k tomu důkladně promyslet a navrhnout pomocnou funkci. Pak by snad mohla být použití pr_cont() snadno opravena skriptem Coccinelle.

    Ted Ts'o se dotázal, jak velký problém proházený výstup skutečně tvoří – na produkčních systémech. Zdálo se, že panovala shoda na tom, že jde o problém vzácný. Linus řekl, že občas vídá škaredý výstup oops v důsledku pokračujících řádek. Andy Lutomirski s úšklebkem prohlásil, že jeho postup, jak se vypořádat se zpřeházenými řádkami, spočívá v tom, že počká, až mu je Linus srovná. Na tomto řešení se kolektiv jednohlasně shodl, a tak se nezdá, že by byla v nejbližší době v plánu nějaká práce v tomto směru.

    Poslední téma, na které už mnoho času nezbylo, představoval semafor console_sem. Tento semafor řeší přístup ke všem konzolím v systému, takže je to globální úzké hrdlo, kde dochází k bránění v přístupu. Existují ovšem způsoby, jak zabrat console_sem, aniž by bylo potřeba upravovat seznam konzolí či zapisovat do konzole. Kupříkladu prosté čtení /proc/consoles z uživatelského prostoru zabere inkriminovaný semafor, což může vést k nepříjemným prodlevám týkajícím se i samotného printk(). Následné uvolnění tohoto semaforu opět vede k volání console_unlock(), se kterým jsou spojené stejné problémy.

    Sergej navrhl, že console_sem by se mohl změnit v zámek čtenářů/písařů. Pak by způsoby použití, které nepřistupují k seznamu konzolí, mohly zámek získat v režimu čtenáře, čímž by se zvětšilo využití paralelizace. Nepomohlo by to však s přímými voláními console_unlock(), která by se stále zasekávala na vyprazdňování výstupu na zařízení. Pro tento případ přišla řeč na rozdělení console_unlock() na dvě varianty: synchronní a asynchronní. Ta druhá by mohla jednoduše probudit vlákno printk(), místo aby se sama zabývala zbývajícím výstupem do konzole. Nezdá se však, že by v tomto směru byla práce nějak urgentní.

    Pak už přidělený čas vypršel a setkání skončilo. Pokud máte zájem, Sergejova prezentace je k dispozici na webu.

           

    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ář

    27.11.2016 00:51 Jiri Kosina
    Rozbalit Rozbalit vše Re: Jaderné noviny - 10. 11. 2016: Nebezpečí printk()
    "zámek čtenářů/písařů" zní jak když si literární kroužek vyjede v létě na výlet na Karlštejn.
    27.11.2016 19:42 pev
    Rozbalit Rozbalit vše Re: Jaderné noviny - 10. 11. 2016: Nebezpečí printk()
    "zámek čtenářů/písařů" zní jak když si literární kroužek vyjede v létě na výlet na Karlštejn.
    :-)

    A také: Ukazuje se, že volání printk() mohou být rekurzivní, obvyklému zákazu rekurze v jádře navzdory. => navzdory obvyklému zákazu rekurze v jádře.

    Díky za překlad!
    28.11.2016 16:37 Sten
    Rozbalit Rozbalit vše Re: Jaderné noviny - 10. 11. 2016: Nebezpečí printk()
    29.11.2016 01:07 Jiri Kosina
    Rozbalit Rozbalit vše Re: Jaderné noviny - 10. 11. 2016: Nebezpečí printk()
    Tak určitě. Čistonosoplena je taky oficiálně zdokumentována.
    29.11.2016 07:32 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny - 10. 11. 2016: Nebezpečí printk()
    Nebo SŘBD, abychom zůstali v oboru…

    Založit nové vláknoNahoru

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