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:44 | Bezpečnostní upozornění

    Nejnovější X.Org X server 21.1.17 a Xwayland 24.1.7 řeší 6 bezpečnostních chyb: CVE-2025-49175, CVE-2025-49176, CVE-2025-49177, CVE-2025-49178, CVE-2025-49179 a CVE-2025-49180. Nils Emmerich je nalezl koncem března a dnes publikoval detaily.

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

    Desktopové prostředí KDE Plasma bylo vydáno ve verzi 6.4 (Mastodon). Přehled novinek i s videi a se snímky obrazovek v oficiálním oznámení. Podrobný přehled v seznamu změn.

    Ladislav Hagara | Komentářů: 0
    dnes 10:11 | Komunita

    UN Open Source Week 2025 probíhá tento týden v sídle Organizace spojených národů v New Yorku. Středeční a čtvrteční jednání bude možné sledovat na UN Web TV.

    Ladislav Hagara | Komentářů: 0
    dnes 03:55 | Nová verze

    Byla vydána nová verze 2.50.0 distribuovaného systému správy verzí Git. Přispělo 98 vývojářů, z toho 35 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání.

    Ladislav Hagara | Komentářů: 0
    včera 21:55 | Zajímavý článek

    Infrastrukturu pro chatovací aplikaci Telegram provozuje člověk s vazbami na ruské zpravodajské služby. Upozorňují na to investigativní novináři z redakce iStories. „Vedneev dodává služby ruskému státu včetně jeho jaderného institutu nebo zpravodajské službě FSB,“ říká v podcastu Antivirus novinář Jan Cibulka. Uživatelům, kteří si chtějí své informace chránit, doporučuje Telegram vůbec nepoužívat, a raději zvolit jednu z alternativ, WhatsApp nebo Signal.

    Ladislav Hagara | Komentářů: 22
    včera 18:33 | IT novinky

    The Trump Organization spustila ve Spojených státech mobilní síť Trump Mobile s neomezeným tarifem The 47 Plan za 47,45 dolarů měsíčně a představila vlastní značku telefonů The T1 Phone s Androidem za 499 dolarů.

    Ladislav Hagara | Komentářů: 17
    včera 15:00 | Zajímavý článek

    Vývojáři KiCadu se na svém blogu rozepsali o problémech KiCadu v desktopových prostředích nad Waylandem. KiCad běží, ale s významnými omezeními a problémy, které podstatně zhoršují uživatelský komfort a vývojáři je nedokážou vyřešit na úrovni KiCadu. Pro profesionální používání doporučují desktopová prostředí nad X11.

    Ladislav Hagara | Komentářů: 6
    15.6. 15:00 | Zajímavý článek

    Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.

    Ladislav Hagara | Komentářů: 0
    13.6. 17:33 | Nová verze

    Byla vydána (𝕏) nová verze 2025.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení na blogu.

    Ladislav Hagara | Komentářů: 0
    13.6. 10:33 | Komunita

    Dánské ministerstvo pro digitální záležitosti má v plánu přejít na Linux a LibreOffice [It's FOSS News].

    Ladislav Hagara | Komentářů: 30
    Jaký je váš oblíbený skriptovací jazyk?
     (56%)
     (30%)
     (7%)
     (2%)
     (0%)
     (1%)
     (3%)
    Celkem 273 hlasů
     Komentářů: 16, poslední 8.6. 21:05
    Rozcestník

    Jaderné noviny - 30. 6. 2016: Virtuálně mapované zásobníky podruhé

    10. 7. 2016 | Redakce | Jaderné noviny | 2636×

    Stav vydání jádra. Citát týdne: Tom Herbert. Shrnutí Summitu na Glungezeru. WireGuard. Virtuálně mapované zásobníky 2: thread_info vrací úder.

    Stav vydání jádra

    Současný vývojový kernel nese označení 4.7-rc5, vydán byl 26. června. Linus řekl: „Myslím, že se věci uklidňují, i když to podle dvou třetin commitů, které přišly od pátečního rána, moc nevypadá – moje pátky jsou většinou velmi rušné. Ale když se dívám na čísla, jsme zhruba tam, kde normálně s rc vydáními býváme.“

    Stabilní aktualizace: 4.6.3, 4.4.14 a 3.14.73 byly vydány 24. června. Kromě jiného obsahují důležitou bezpečnostní opravu.

    Citát týdne

    Není žádné „jádro jedna“, je mnoho různých klientských jader, v Internetu je mnoho konfigurací, mnoho implementací TCP. Některé jsou bídně navržené, roky pozadu i jinak zoufale nebezpečné. Také jsou lidé, kteří stále používají Windows 95, proboha! Nemůžeme jádrům prostě věřit, že dělají, co dělat mají. Také to od nás nikdo nevyžaduje, v žádném internetovém standardu nenajdete požadavek na implementaci TCP v jádře. Stejné je to u middleboxů a firewallů, existuje spousta implementací, řada z nich nedodržuje standardy a problémy s aktualizací software/firmware představují pro Internet možnou katastrofu. Není to od nás vyžadováno a nikdy nemůžeme předpokládat, že naše pakety půjdou přes dostatečně robustní firewall.

    Sečteno a podtrženo: Pokud vyvíjíte aplikaci v Internetu, která je kritická pro vaše podnikání, nemůžete předpokládat, že operační systémy nebo sítě poskytnou dostatečné zabezpečení; musíte vzít zodpovědnost za svou aplikaci do vlastních rukou. TOU je krok správným směrem.

    -Tom Herbert

    Shrnutí Glungezer realtime summitu

    Daniel Wagner se podělil o shrnutí z realtime summitu, který se nedávno konal na odlehlém místě v Alpách. „Christoph [Hellwig] a já jsme se rozhodli, že zorganizujeme malou konferenci na horách. Díky Christophově znalosti okolí Innsbrucku jsme vybrali chatu na Glungezeru. Nachází se téměř na vrcholu, kam se nedá dojet autem ani lanovkou. John Kacur vyslovil podezření, že Christoph chtěl skrytě podpořit fyzičku real-time vývojářů tím, že je nechá pochodovat skrze rakouské Alpy. Jak se ukázalo, měl pravdu.“

    WireGuard: nový VPN tunel

    Jason Donenfeld oznámil dostupnost „WireGuard“ pro linuxové jádro. „WireGuard je velmi jednoduchá a přitom rychlá a moderní VPN, která používá nejmodernější šifrování. Jejím cílem je být rychlejší, jednodušší, lehčí a použitelnější než IPSec, a to bez bolestí hlavy. Současně je cílem být mnohem výkonnější než OpenVPN.“ Kód je v raném stádiu a komunita jej předtím nikdy neviděla, dokonce se ani neobjevil jako patch. Takže možná bude ještě trvat, než se dostane do hlavního vydání. Zatím je možné kód a další informace najít na wireguard.io.

    Celý článek na LWN.

    Virtuálně mapované zásobníky 2: thread_info vrací úder

    V minulém dílu jste se mohli dočíst o sadě patchů Andyho Lutomirského, která přesunovala jaderné zásobníky do rozsahu vmalloc(). To má spoustu výhod, mezi nimi také eliminaci některých alokací paměti vyššího řádu, vylepšení bezpečnosti a lepší diagnostický výstup při přetečení zásobníku. Jenže je tu jeden drobný háček, a sice 1,5 µs navíc při vytváření nového procesu – cena, se kterou se Linus nebyl ochoten smířit. První pokus o řešení narazil na obskurní datovou strukturu v jádře, ale nakonec se díky tomu povedlo podstatně pročistit část jádra, která se stará o informace o procesech.

    Za výkonnostní regresí stojí využití vmalloc() k alokaci jaderných zásobníků; vmalloc() představuje poměrně nákladný způsob, jak alokovat paměť, a nedostalo se mu stejné pozornosti při optimalizaci, jako například slab alokátorům. Jedním z návrhů bylo kešovat několik jaderných zásobníků, což by umožnilo rychlé opětovné využití ještě teplých zásobníků po ukončení procesu. Věřilo se, že když budou odstraněna volání vmalloc(), kód obecně zrychlí.

    Zbytečná cache

    Andy se dal do realizace této myšlenky a referoval odrazující výsledek: „Implementoval jsem cache pro každé CPU, a je to k ničemu.“ Problém, stručně řečeno, spočívá v tom, že zdroje procesu (včetně jaderného zásobníku) nejsou uklizeny bezprostředně po ukončení procesu. Místo toho se mechanismus RCU (read-copy-update) postará o to, aby na tyto zdroje před uvolněním nezůstaly žádné odkazy. Takže (1) uvolnění jaderného zásobníku se zpozdí až do konce dalšího cyklu RCU (grace period); (2) zdroje všech procesů, které skončily během tohoto cyklu, budou uvolněny naráz. Tím pádem bude cache jaderných zásobníků téměř neustále prázdná, potom se najednou zaplní velkým počtem uvolněných zásobníků, jenže většina z nich se tam nevejde, a proto bude prostě uvolněna. Jinými slovy, četnost cache hit bude blízká nule – zvláště při zátěži bohaté na vytváření nových procesů.

    Teoreticky by jaderný zásobník po skončení procesu neměl být potřeba, takže by se mohlo zdát, že by k uvolnění zásobníku mohlo dojít okamžitě, a to i když je zapotřebí zachovat ostatní datové struktury. Problém je v tom, že základní informace, které si jádro o procesech udržuje, se nacházejí na dvou různých místech:

    • Velká struktura task_struct se nachází v <linux/sched.h>. Tato struktura, která je (až na znepokojivé množství bloků #ifdef) nezávislá na architektuře, obsahuje většinu informací, které jádro potřebuje o běžícím procesu vědět.
    • Malá struktura thread_info, jejíž podoba závisí na architektuře.

    Struktura task_struct se nachází na haldě – jako většina ostatních datových struktur jádra. Avšak struktura thread_info pobývá ve spodní části jaderného zásobníku, čímž znemožňuje opětovné využití tohoto zásobníku, dokud na ni něco může odkazovat. Toho času Linus usiloval o změny, které by umožnily rychlé uvolnění struktury thread_info, zatímco struktura task_struct by přetrvávala, leč brzy se ukázalo, že tudy cesta k jednoduchému řešení nevede. K některým informacím v thread_info, zvláště se to týká pole příznaků (flags), může být přistupováno vcelku nepředvídatelně, tudíž tyto informace musí zůstat dostupné, dokud má jádro jakékoli informace o přidružených procesech.

    Existence těchto dvou struktur je v podstatě historický artefakt. V počátcích Linuxu existovala pouze task_struct a nacházela se na jaderném zásobníku. Jenže časem zásobník přerostla, ačkoliv její umístění na jaderném zásobníku mělo velkou výhodu: strukturu bylo snadné nalézt zamaskováním některých bitů z ukazatele na zásobník, tzn. k udržování její polohy nebylo potřeba ztrácet vzácné místo v registrech. V případě některých často používaných polí šlo o výhodu, o kterou jaderní vývojáři nechtěli přijít. Takže když došlo k přesunu task_struct z jaderného zásobníku, hrstka jejích důležitých částí zůstala v nově vytvořené struktuře thread_info. Výsledné řešení o dvou strukturách se používá i v současných jádrech, ovšem do budoucna tomu tak být nemusí.

    Jak se zbavit thread_info

    Jádro vcelku nedávno přešlo na ukládání různých typů často potřebných informací do proměnných specifických pro dílčí CPU. Plánovač některé zásadní informace o aktuálně běžících procesech ukládá do oblasti vyhrazené dílčím CPU. Ukazuje se, že to je rychlejší než přístup na dno jaderného zásobníku. Tím pádem se zmenšil objem užitečných dat v thread_info, a tak je nasnadě otázka: nemohli bychom tu strukturu odstranit úplně? Nejedná se dokonce ani o novou otázku. Přesun struktury pryč ze zásobníku byl jedním z Andyho cílů od samého počátku. Ovšem problematika výkonu dodává tomuto problému na naléhavosti.

    Linus rychle přišel na to, že někteří uživatelé thread_info vlastně nepotřebují, a to dokonce aniž by byly nutné další změny. Typické použití spočívá v nalezení struktury task_struct, leč ukazatel na ni je obvykle již k dispozici. Linus tyto případy vyřešil a výsledek připravil pro vydání 4.7-rc5. Tento typ změny se možná nedá považovat za opravu chyby, pro něž je pozdní cyklus běžně určen, ale Linus dal jasně najevo, že změny považuje za přijatelné: „Toto jsou přesně ty ‚ryze historické důvody pro špatnou volací konvenci‘ a souhlasím s tím ve fázi rc vydání, abych to lidem, kteří si s nimi budou hrát, zjednodušil.“

    Posunul práce dále, a to tak, že bylo možné (poněkud redukovanou) strukturu thread_info odsunout ze zásobníku a zahrnout ji do task_struct. Dostal se až do stavu, kdy šlo upravené jádro zavést na testovacím systému. Pak se věci chopil Andy a změny integroval do své větší řady patchů.

    V době psaní tohoto článku byla řada patchů ve čtvrté revizi. Mnoho polí thread_info je přesunuto do task_struct, přičemž je také upravován kód, který k těmto polím přistupuje. Nakonec se do task_struct přesune i samotná struktura thread_info, která už obsahuje pouze pole příznaků. To vyžaduje řadu změn nízkoúrovňového kódu jednotlivých architektur, takže momentálně se změny dotýkají pouze architektury x86. Vypadá to, že další architektury budou následovat. I bez ostatních prací představuje eliminace samostatných struktur thread_info užitečný úklid a vylepšení zabezpečení.

    S ohledem na skutečný cíl sady patchů (přesun jaderných zásobníků do rozsahu vmalloc()) odstranění struktury thread_info umožní uvolnění jaderného zásobníku, jakmile skončí příslušný proces – bez potřeby cyklu RCU. To zase umožní přidat malé cache pro dílčí CPU, které udrží až dva volné jaderné zásobníky. Díky této cache se podle Andyho stane z 1,5µs výkonnostní regrese 0,5-1µs nárůst výkonu.

    Takže v této fázi má Andy řadu patchů, které zjednodušují část ústředního kódu jádra, poskytují okamžitou detekci přetečení jaderných zásobníků, poskytují lepší diagnostiku, když už k přetečení dojde, vylepšují bezpečnost jádra a dokonce i zrychlují jeho běh. Není tedy překvapením, že už je těžké najít další námitky. Jednou zbývající otázkou může být, kdy tento kód začlenit, a odpovědí se zdá být začleňovací okno 4.8. Dá se říct, že protože jde o fundamentální změny a nepochybně se objeví ještě jedna nebo dvě nepříjemnosti, jedná se o agresivní přístup. Na jednom překvapení se ostatně v době psaní článku pracovalo. Nicméně vývojový cyklus 4.8 by měl poskytnout dostatek času pro práci na takových překvapeních a ve finále půjde o výsledek, který bude stát za to.

           

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

    11.7.2016 00:55 pc2005 | skóre: 38 | blog: GardenOfEdenConfiguration | liberec
    Rozbalit Rozbalit vše Re: Jaderné noviny - 30. 6. 2016: Virtuálně mapované zásobníky podruhé
    Linus rychle přišel na to, že někteří uživatelé thread_info vlastně nepotřebují, a to dokonce aniž by byly nutné další změny. Typické použití spočívá v nalezení struktury task_struct, leč ukazatel na ni je obvykle již k dispozici.
    No nevím, tohle se tuším na arch/microblaze řešilo jako globální proměnná (ukazatel) na aktuálně běžící task a byla sranda to správně vyměnit s přepínáním úlohy v assembleru (například i při vyjímce paměti a nebo přerušení).

    Akorát bude problém rychle přiřadit stack neběžící úloze k té struktuře (prohledávání nějakého seznamu, řekl bych).
    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.