IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
Evropský parlament dnes přijal směrnici týkající se tzv. práva spotřebitele na opravu. Poslanci ji podpořili 584 hlasy (3 bylo proti a 14 se zdrželo hlasování). Směrnice ujasňuje povinnosti výrobců opravovat zboží a motivovat spotřebitele k tomu, aby si výrobky nechávali opravit a prodloužili tak jejich životnost.
Bylo oznámeno (cs) vydání Fedora Linuxu 40. Přehled novinek ve Fedora Workstation 40 a Fedora KDE 40 na stránkách Fedora Magazinu. Současně byl oznámen notebook Slimbook Fedora 2.
ČTK (Česká tisková kancelář) upozorňuje (X), že na jejím zpravodajském webu České noviny byly dnes dopoledne neznámým útočníkem umístěny dva smyšlené texty, které nepocházejí z její produkce. Jde o text s titulkem „BIS zabránila pokusu o atentát na nově zvoleného slovenského prezidenta Petra Pelligriniho“ a o údajné mimořádné prohlášení ministra Lipavského k témuž. Tyto dezinformace byly útočníky zveřejněny i s příslušnými notifikacemi v mobilní aplikaci Českých novin. ČTK ve svém zpravodajském servisu žádnou informaci v tomto znění nevydala.
Aktuální verze jádra je i nadále 2.6.24-rc5; v minulém týdnu nevyšly žádné nové předverze. Do hlavního repozitáře však i nadále proudí opravy.
Aktuální verze -mm stromu je 2.6.24-rc5-mm1. Mezi nedávné změny patří výrazné změny modelu zařízení; kvůli konfliktům patchů bylo z této verze vynecháno dost stromů subsystémů.
Aktuální stabilní jádro řady 2.6 je 2.6.23.10 2.6.23.11 2.6.23.12. Velký patch 2.6.23.10, který vyšel 14. prosince, obsahoval několik desítek oprav. 2.6.23.11 (14. prosince) a 2.6.23.12 (18. prosince) obsahují malé opravy problémů způsobených verzí 2.6.23.10.
Starší jádra: 2.6.22.15 vyšlo 14. prosince se slušnou řádkou oprav.
2.4.36-rc1 bylo vydáno 17. prosince s několika bezpečnostními opravami. 2.4.35.5 obsahuje stejné opravy.
Pro představu... mám:
Což všechno znamená, že je trochu nevhodné uvažovat o nových funkcích, které vypadají, že budou mít velký dopad.
Takže mi to celé pošlete aplikovatelné na rc5-mm1 a já to tam vrazím - uvidíme, co přestane fungovat.
OK, a vzhledem k časovému posunu a ročnímu období si večer sednu a budu sledovat, jak padá sníh, a spokojeně snít o koťátkách s uzi samopaly s municí s nukleárními hroty, které loví super-elitní vývojáře bezdrátového síťování, aby do nich vtloukli trochu lidskosti a pochopení, OK?
-- Ingo Molnár
Významnou součástí práce vývojáře je stanovování priorit [triage]. Tak velký a používaný projekt jako jádro bude mít pořád více hlášení o chybách, než kolika by bylo reálně možné se v dostupném čase věnovat. Vývojáři tedy musí zjistit, které problémy stojí za to, aby jim věnovali svou pozornost. Někdy to rozhodování usnadní přítomnost naštvaného zákazníka. Jindy je však třeba uhádnout, které chyby se dotýkají největšího počtu uživatelů. A to se často pozná podle toho, kolik různých hlášení o daném problému přišlo.
Počítání hlášení však není nic jednoduchého - zvláště pokud nejsou na stejném místě. Ve snaze celý proces zjednodušit, Arjan van de Ven oznámil nové stránky kerneloops.org. Arjan dal dohromady software, který na určitých stránkách a konferencích vyhledává poslané výstupy jaderných oops; každý nalezený pád je nacpán do databáze. Pak se program pokusí propojit hlášení pomocí verze jádra a obsahu výpisu [call trace]; z toho lze pak vytvořit seznam nejoblíbenějších způsobů, jak shodit systém. V tuto chvíli to vypadá, že nejvíce v kurzu mezi oopsy vývojových jader je ieee80211_tx(). Kromě toho se ukládají i některé další informace; konkrétně je možné zjistit, která nejstarší verze jádra ještě daným oopsem trpí.
Je to nepochybně užitečný zdroj informací, ale je tu ještě pár problémů, které situaci komplikují. Jedním z nich je skutečnost, že konec výpisu nebývá nijak jednoznačně označen, takže skripty nevědí, kde přestat kopírovat text. Druhá potíž je v tom, že vícenásobná hlášení o stejném oopsu mohou uměle navýšit zaznamenávaný počet u daného pádu. Řešením obou problémů je umístění značky na konec výpisu, která by obsahovala náhodné UUID generované při bootu. Patche, které by to zařídily, jsou již v oběhu, i když se ukazuje, že dostat do výpisů to náhodné číslo je trochu obtížnější, než by se dalo čekat. U 2.6.24 může být "náhodné" číslo složeno ze samých nul, takže vyřešeno to nakonec bude asi až v 2.6.25.
Když se někdo aspoň chvilku šťourá v kódu jádra, tak si všimne mnoha proměnných deklarovaných následujcím způsobem:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
static int __read_mostly ignore_loglevel;
Atribut __read_mostly [většinou čteno] říká, že přístupy k dané proměnné jsou většinou (ale ne vždy) operace typu čtení. Nedávno se objevily dotazy o tom, proč se toto označování provádí. Odpověď je, že jde o důležitou optimalizaci, i když ne vždy má takový účinek, v jaký vývojáři doufali.
Jak je popsáno v What every programmer should know about memory, správné používání paměťové keše je pro optimální výkon klíčové. __read_mostly seskupuje proměnné, které jsou měněny jen výjimečně, aby mohly sdílet řádky keše [cache lines], které by nemusely na víceprocesorových systémech lítat mezi jednotlivými procesory. Dokud proměnnou označenou jako __read_mostly někdo nezmění, může klidně sedět ve sdíleném řádku keše s ostatními takovými proměnnými a být po ruce v keši na všech procesorech systému.
Atribut read-mostly obvykle funguje dobře a poskytuje měřitelné zlepšení výkonu. Existují však obavy, že by tato funkce mohla být využívána až příliš. Andrew Morton to vyjádřil takto:
Takže... až přeměníme všechny většinou čtené proměnné na __read_mostly, co nám zbude v bss? Všechny často zapisované proměnné. Všechny hezky namačkané pohromadě, aby se maximalizovalo sdílení řádků keše.
Kombinování často zapisovaných proměnných do sdílených řádků keše je dobrý způsob, jak maximalizovat přehazování těchto řádků mezi procesory - což by mělo na výkon špatný vliv. Příliš agresívní segregace read-mostly proměnných, aby se minimalizovalo přehazování řádků keše, může mít úplně opačný účinek: výkon jaderné keše by mohl poklesnout.
Podle Andrewa by bylo lepší vytvořit atribut "read often" [často čteno], který by se přiřazoval proměnným často využívaným v režimu pouze pro čtení. To by umožnilo, aby početné málo čtené proměnné vyplnily místo mezi často zapisovanými proměnnými. Zatím však tuto myšlenku nikdo nepřevedl do patche.
Mezi funkcemi, které jádro poskytuje pro přístup k I/O portům, jsou už verze, jež vkládají prodlevy. Ovladač by za normálních okolností přečetl bajt z portu pomocí inb(), ale pokud by po operaci bylo potřeba vložit krátkou prodlevu, může se použít inb_p(). Pohled na ovladače ve stromu jádra prozradí, že tyto přístupy s prodlevou jsou využívány docela často, i když k tomu v mnoha případech není důvod.
Prodleva je (na architekturách x86) implementována pomocí zápisu na I/O port 80. Na tomto portu většinou žádný hardware nenaslouchá, takže zápis pouze způsobí zdržení procesoru, zatímco se sběrnice marně snaží operaci provést. Tato operace má rozumně definovanou sémantiku a funguje už v Linuxu hodně let.
Až na to, že to teď vypadá, jako by tato technika na malé části x86_64 systémů nefungovala. Zápis na port 80 občas způsobí úplné zatuhnutí systému, což má za následek poněkud delší prodlevu, než bylo v plánu. Šlo by si představit komplikovaný mechanismus pro restartování I/O operací po té, co uživatel restartuje systém, ale vývojáři jádra se raději pustili do hledání jiných způsobů, jak implementovat I/O prodlevy.
Skoro ve všech ostatních případech poslouží jako alternativní způsob docílení prodlevy volání udelay(). Největší potíž je však v tom, že udelay() funguje jako smyčka; nemůže vědět, kolikrát se má smyčkou projít, dokud není kalibrována rychlost procesoru. K této kalibraci dochází poměrně záhy v rámci procesu bootování, ale předtím je ještě potřeba provést několik věcí - včetně operací s I/O porty. Problém je zatím obcházen odstraňováním operací s prodlevou z kódu, který je spouštěn příliš brzy, ale někteří vývojáři mají obavy, že se nikdy nepodaří je přesunout všechny. Padl návrh, že až do chvíle, kdy proběhne kalibrace, by jádro mohlo prostě předpokládat, že běží na nejrychlejším možném procesu. Ale kromě toho, že to není moc elegantní, tak by to mohlo výrazně snížit rychlost bootu na pomalejších strojích - které všechny se stávajícím kódem fungují dobře.
Skutečným řešením by bylo se prostě zbavit skoro všech těch operací s prodlevou. Jen velmi málo z nich bude pravděpodobně potřeba pro použití s hardwarem, který se ještě používá. V některých případech je navíc skutečným účelem prodlev kamuflování chyb v ovladačích. Pouhé odstranění prodlev by asi způsobilo nestabilitu na neočekávaných místech, čemuž by se vývojáři raději vyhnuli. Bude se to tedy muset provést opatrně a pomalu. V 2.6.24. zůstane využívání portu 80 asi beze změny.
Naposledy jsme se na patch revoke(), který napsal Pekka Enberg, dívali v červenci 2006. Účelem tohoto volání je kompletně odpojit všechny procesy od určitého souboru, což umožní nějakému novému procesu exkluzivní přístup. Taková funkčnost má mnoho možných uplatnění, například zajištění, že nově přihlášený uživatel bude mít jako jediný přístup ke zdrojům spojeným s konzolí - třeba ke zvukovému zařízení. Jsou také vývojáři jádra, kteří si čas od času výhružně bručí pod vousy o neopravitelných bezpečnostních problémech způsobených absencí možnosti zrušit otevřené popisovače souborů - i když nikdo neví, proč se nechtějí podělit o podrobnosti ohledně těchto chyb. Také jakákoliv opravdová aplikace pro hledání malwaru bude potřebovat mít možnost zrušit přístup k souborům, o kterých zjistí, že obsahují Zlé Věci.
Pekka nedávno poslal novou verzi patche, takže si ji prohlédneme. První věc, které si všimnete, je to, že systémové volání revoke() je pryč; místo toho vypadá nové volání takto:
int revokeat(int dir_fd, const char *filename);
Toto volání je tedy modelováno podle mnoha dalších, poměrně nových systémových volání typu *at(). V tomto případě je filename název souboru, k němuž má být zrušen přístup; pokud jde o absolutní cestu, pak je dir_fd ignorován. Jinak je dir_fd otevřený popisovač souboru ukazující na adresář, který se má použít jako počáteční bod při hledání filename. Hodnota AT_FDCWD určuje aktuální pracovní adresář volajícího procesu. Pokud je volání revokeat() úspěšně dokončeno, budou pro filename platné jen popisovače souborů, které byly vytvořeny až po volání.
Patch také přidává nového člena do file_operations:
int (*revoke)(struct file *filp);
Funkce má na starosti zajistit, aby byly dokončeny všechny zbývající I/O operace s daným souborem - je-li to potřeba, tak i s chybovým stavem. Zatím jediná implementace je obecná verze pro souborové systémy; celá vypadá takto:
int generic_file_revoke(struct file *file)
{
return do_fsync(file, 1);
}
Aby bylo volání revokeat() v budoucnu užitečné, bude potřebovat podporu alespoň v nějakých ovladačích.
Odpojení přístupu k obyčejným popisovačům souborů je poměrně jednoduché; systémové volání prostě prochází seznamem otevřených souborů na příslušném zařízení a nahrazuje strukturu file_operations novou sadou, která vrací EBADF za každý pokus o operaci (OK, skoro každý pokus - čtení ze soketů a souborů zařízení vrací místo toho nulu). Nepříjemné je pouze to, že seznamem souborů se musí projít vícekrát, než budou všechny otevřené soubory odstraněny; jinak by mohly nastat souběhy [race conditions] s jinými systémovými voláními, která vytvářejí nové popisovače souborů ve stejný okamžik, kdy jsou ty staré rušeny.
Složitější je to s mapovanou pamětí. Ve většině případů jde o nalezení všech oblastí virtuální paměti (VMA), které jsou se souborem spojeny. Pak se nastaví příznak VM_REVOKED a zavolá zap_page_range(), aby se pročistily příslušné záznamy v tabulce stránek. Příznak VM_REVOKED zajistí, že jakýkoliv pokus o vrácení stránek [fault pages back] vyústí v signál SIGBUS - to může být nepříjemné překvapení pro jakýkoliv proces, který by se pokoušel k té oblasti přistupovat.
Ještě horší je to v případě privátních copy-on-write (COW) [kopírování při zápisu] mapování, která mohou vzniknout, když se proces rozdělí [fork]. Obyčejné pročištění těchto mapování by mohlo být účinné, ale mohlo by to také způsobit konec procesů, které není potřeba zabíjet. Je však důležité si ohlídat, aby COW mapování nepředstavovalo způsob, jak ztrácet data zapsaná do souboru po volání revokeat(). COW mapování jsou tedy od sebe oddělena jednoduchým (ale nákladným) voláním get_user_pages(), které vytvoří privátní kopie všech relevantních stránek.
O patchi se zatím moc nediskutovalo - možná, že příslušní vývojáři už odjeli na vánoční dovolené a linux-kernel přestali sledovat. Jde však o důležitý patch s mnoha náročnými nízkoúrovňovými operacemi; to je částečně důvod, proč jeho příprava trvala tak dlouho. Než se bude uvažovat o začlenění do hlavního jádra, bude potřeba jej pečlivě zkontrolovat. Vzhledem k povaze problému by nebylo překvapivé, kdyby byly potřeba ještě jedna nebo dvě další verze.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
