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í
×

včera 14:33 | Zajímavý projekt

Blender Animation Studio zveřejnilo první epizodu z připravovaného animovaného seriálu The Daily Dweebs o domácím mazlíčkovi jménem Dixey. Ke zhlédnutí také ve 3D s rozlišením 8K.

Ladislav Hagara | Komentářů: 0
včera 12:34 | Komunita

Aktualizovanou počítačovou hru Warhammer 40,000: Dawn of War III v ceně 39,99 eur běžící také na Linuxu lze o víkendu na Steamu hrát zdarma a případně ještě v pondělí koupit s 50% slevou. Do soboty 19:00 lze na Humble Bundle získat zdarma Steam klíč k počítačové hře Sid Meier's Civilization® III v ceně 4,99 eur běžící také ve Wine.

Ladislav Hagara | Komentářů: 0
včera 00:22 | Nasazení Linuxu

Společnost Samsung oznámila, že skrze dokovací stanici DeX a aplikaci Linux on Galaxy bude možno na Samsung Galaxy S8 a S8+ a Galaxy Note 8 provozovat Linux. Distribuce nebyly blíže upřesněny.

Phantom Alien | Komentářů: 10
19.10. 23:55 | Komunita

Společnost Purism na svém blogu oznámila, že její notebooky Librem jsou nově dodávány se zrušeným (neutralized and disabled) Intel Management Engine (ME). Aktualizací corebootu na již prodaných noteboocích lze Management Engine také zrušit. Více v podrobném článku.

Ladislav Hagara | Komentářů: 0
19.10. 21:44 | Nová verze

Organizace Apache Software Foundation (ASF) na svém blogu slaví páté výročí kancelářského balíku Apache OpenOffice jako jejího Top-Level projektu. Při této příležitosti byl vydán Apache OpenOffice 4.1.4 (AOO 4.1.4). Podrobnosti v poznámkách k vydání. Dlouhé čekání na novou verzi tak skončilo.

Ladislav Hagara | Komentářů: 6
19.10. 19:22 | Pozvánky

Již příští týden - 26. a 27. října se v Praze v hotelu Olšanka odehraje OpenWRT Summit. Na webu konference naleznete program a možnost zakoupení lístků - ty stojí 55 dolarů. Čtvrtek bude přednáškový a v pátek se budou odehrávat převážně workshopy a meetingy.

Miška | Komentářů: 1
19.10. 13:44 | Nová verze

Bylo vydáno Ubuntu 17.10 s kódovým názvem Artful Aardvark. Ke stažení jsou Ubuntu Desktop a Server, Ubuntu Cloud Images, Ubuntu Netboot, Kubuntu, Lubuntu a Lubuntu Alternate, Lubuntu Next, Ubuntu Budgie, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio a Xubuntu. Podrobnosti v poznámkách k vydání.

Ladislav Hagara | Komentářů: 22
19.10. 13:00 | Komunita

MojeFedora.cz informuje, že Fedora 27 dostane podporu pro AAC. Podpora multimediálních formátů je ve výchozí instalaci Fedory tradičně limitovaná kvůli softwarovým patentům, ale desktopový tým Red Hatu se ji i tak snaží v poslední době co nejvíce rozšířit. Už nějaký čas obsahuje kodeky pro MP3, H.264, AC3 a nyní byl přidán také kodek pro další velmi rozšířený zvukový formát – AAC.

Ladislav Hagara | Komentářů: 2
18.10. 23:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 145. brněnský sraz, který proběhne v pátek 20. října od 18:00 hodin v restauraci Time Out na adrese Novoměstská 2 v Řečkovicích. Jedná se o poslední sraz před konferencí OpenAlt 2017, jež proběhne o víkendu 4. a 5. listopadu 2017 na FIT VUT v Brně. Běží registrace účastníků.

Ladislav Hagara | Komentářů: 0
18.10. 21:44 | Nová verze

Byla vydána verze 5.2.0 multiplatformního virtualizačního nástroje Oracle VM VirtualBox. Jedná se o první stabilní verzi z nové větve 5.2. Z novinek lze zmínit například možnost exportování VM do Oracle Cloudu, bezobslužnou instalaci hostovaného systému nebo vylepšené GUI. Podrobnosti v seznamu změn. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 2
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (10%)
 (1%)
 (1%)
 (1%)
 (75%)
 (12%)
Celkem 145 hlasů
 Komentářů: 7, poslední 19.10. 23:06
    Rozcestník

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

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

    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.