Portál AbcLinuxu, 19. dubna 2024 03:12

Jaderné noviny - 6/2008

20. 2. 2008 | Jirka Bourek
Články - Jaderné noviny - 6/2008  

GIT 1.5.4, "neobvykle dlouhý cyklus". Tempo změn jádra. GCC 4.2.3, opravná verze. kgdb, začlenit či nezačlenit. Btrfs 0.12, zlepšení výkonnosti. Ladění pomocí kmemcheck. Kgdb light. 2.6.25-rc1, "pekelně velký". Patch pro CVE-2008-0600, chybu umožňující získání roota.

Obsah

Následující obsah je © KernelTrap.

GIT 1.5.4, "neobvykle dlouhý cyklus"

link

2. únor, originál

Nejnovější vydání GITu - 1.5.4 - je k dispozici na obvyklých místech, oznámil správce Gitu Junio Hamano. Byl to poněkud dlouhý vývojový cyklus, 5 měsíců od posledního vydání verze s novými vlastnostmi - 1.5.3 - je trochu mnoho. Doufám ale, že stálo za to si počkat. Děkuji všem, kteří pracovali na vylepšeních. Dodal, že se připojilo celkem 165 přispěvatelů, což vedlo ke 684 změněným souborům, což zahrnuje 70435 vložení a 28984 výmazů.

Distribuovaný systém správy verzí Git byl původně napsán Linusem Torvaldsem v dubnu 2005 jako dočasná náhrada BitKeeperu, který se používal ke správě zdrojových kódů jádra od února 2002. Junio Hamano převzal správcovství Gitu o pár měsíců později v červenci 2005 a nástroj jako takový je nyní vcelku oblíbený dokonce i mimo vývoj jádra. Co se nejnovější stabilní verze týče, Junio zdůraznil některé ze změn.

 

Citát: Stav brzké alfaverze

Před vydáním budu na HAMMERu pracovat tak dlouho, jak budu moci, ale stejně tohle vydání určitě bude ve stavu brzké alfaverze.

Matthew Dillon, zpráva z 1. února 2008 na DragonFlyBSD -user mailing list.

 

Tempo změn jádra

link

3. únor, originál

Jednoho dne jsem znovu udělal nějaké statistiky tempa vývoje jádra a zároveň změnil vzorec poté, co mě Andrew obvinil, že výsledné číslo je mnohem nižší, než by mělo být, psal Greg KH během diskuze o stabilitě jádra Linuxu během významných změn. Ukázalo se, že do vydání 2.6.24-rc8 jádra 2.6.24 jsme udělali: řádků přidáno za den: 4945; řádků odebráno za den: 2006; řádků modifikováno za den: 1702.

Podotýkám, že tohle jsou skutečné údaje, nezahrnují přejmenování nebo přesouvání souborů, protože git je do toho umí nezapočítat. To platí pro těch 99 dní, které uběhly, než jsme vydali 2.6.24-rc8 (je potřeba ty skripty spustit znovu, když je teď 2.6.24 vydáno). Je děsivě ohromující, že věci vůbec fungují... To bylo jen tak něco, abyste v noci dobře spali :).

 

Citát: Jsem ohromen, jak málo přestane fungovat.

Čas od času si všichni nosíme hnědý papírový pytlík, a proto když vezmu v potaz začleňovací maelström v každém začleňovacím okně, tak mě udivuje, jak málo věcí přestává fungovat.

Jeff Garzik, zpráva z 2. února 2008 na Linux kernel mailing list

 

GCC 4.2.3, opravná verze

link

4. únor, originál

Joseph Myers oznámil, že GCC 4.2.3 je k dispozici: GCC 4.2.3 je vydání, které opravuje chyby [bug-fix release], obsahuje opravy regresí verze 4.2.2 vzhledem k předchozím verzím GCC. Jako vždycky do tohoto vydání přispělo ohromné množství lidí -- příliš mnoho na to, aby jim bylo možné děkovat jednotlivě!

GCC je sada překladových nástrojů GNU (GNU Compiler Collection), která zahrnuje překladače pro C, C++, Objective-C, Fortran, Javu a Adu. GCC 4.2.3 můžete stáhnout z nejbližšího zrcadla gcc.gnu.org.

 

Citát: Hlášení chyb v Linuxu

LKML je ta správná mailová konference pro hlášení chyb v Linuxu. Trend, který jsem v poslední době viděl, je extrémně škodlivý: někteří vývojáři jádra z nějakého důvodu odklánějí tok hlášení o chybách pryč od LKML tím, že testerům naznačují, že LKML je tak nějak nevhodná pro hlášení chyb.

Ingo Molnár, zpráva z 28. ledna 2008 na Linux kernel mailing list

 

kgdb, začlenit či nezačlenit

link

5. únor, originál

Nedávno bylo poukázáno na to, že většina patchů pro architekturu x86 byla začleněna do hlavní řady jádra 2.6.25. Výjimkou byly pouze patche kgdb. Linus Torvalds odpověděl: O přetažení nebudu ani uvažovat do doby, dokud to nebude nabídnuto jako samostatný strom, ne smíchané s dalšími věcmi. V takovém případě bych se na to podíval.

Jinak řečeno, vysvětlil jsem Ingovi, proč mě to nějak obzvláště nezajímá. Myslím si, že ladění zaměřené na vývojáře není ani zdaleka náš problém. Osobně by mě mnohem víc zajímala infrastruktura, která by běžným uživatelům pomohla poskytovat lepší hlášení o chybách. A to kgdb ani zdaleka nedělá.

Takže bych v mžiku začlenil patch, který vypíše informace o oops (nebo celý výpis z konzole) v Intel Management záležitostech. Ten kód je pravděpodobně mnohem ubožejší, než kgdb kdy bude (Intel v tom rozhraní skutečně zkazil, co mohl, a udělal z toho šílenou XML záležitost), ale je také podstatně důležitější - pokud to bude znamenat, že nám budou moci běžní uživatelé dát hlášení o oopsu poté, co se jim stal v X (dneska pravděpodobně častěji během suspend/resume), a ten stroj prostě umřel.

 

Citát: Patche jako tenhle

Patche jako tenhle mě přímo děsí.

Andrew Morton, zpráva z 1. února 2008 na Linux kernel mailing list

 

Btrfs 0.12, zlepšení výkonnosti

link

6. únor, originál

Ještě jsem neměl v plánu uvolnit verzi 0.12, protože jsem chtěl, aby v ní byl základ podpory několika zařízení [multiple devices, MD]. Nicméně jsem udělal několik vylepšení ohledně výkonnosti a opravil nějaké menší chyby, takže to vydávám předtím, než dojde na (destabilizující) práci na MD, psal Chris Mason o vydání verze 0.12 jeho souborového systému btrfs. Btrfs (vizte také blog Linuxová konkurence ZFS od Oracle - Btrfs) byl poprvé oznámen v červnu 2007 jako souborový systém alfa-kvality, který mimo jiné nabízí kontrolní součty všech souborů a metadat, na rozsazích [extents] založené ukládání dat, efektivní ukládání malých souborů, dynamickou alokace inodů, zapisovatelné snapshoty, zrcadlení a striping na úrovni objektů a rychlé offline kontroly souborového systému.

Na webových stránkách projektu se píše: Linux má nepřeberné množství souborových systémů, ze kterých si lze vybrat, ale na velkých subsystémech, které jsou čím dál tím běžnější v dnešních datacentrech, čelíme mnoha potížím se škálováním. Souborové systémy potřebují škálovat svou schopnost adresovat a spravovat velká úložiště a také schopnost detekovat, opravovat a tolerovat chyby v datech uložených na disku.

Ohledně nejnovější verze Chris řekl: Tak tady je v0.12. Dodává se s nablýskaným nový formátem disku (sorry), ale zisk při náhodném zápisu do existujících souborů je značný. Při testování se fáze náhodného zápisu v tiobenchi zrychlila z 1 MB/s na 30 MB/s. Oprava spočívala ve změně způsobu, jakým se počítaly hashe zpětných referencí pro souborové rozsahy.

 

Citát: Rychlost paměti

V uživatelském prostoru si můžeš hrát, ale jsi naivní, pokud si myslíš, že to můžeš udělat i v jádře. A určitě jsi naivní, pokud věříš, že mmap() řeší problémy s výkonností. 'Bez kopírování' [zero-copy] se nerovná 'rychle'. Rychlost paměti může být menší než rychlost jádra CPU, ale ne nekonečně.

Linus Torvalds, zpráva ze 4. února 2008 na Linux kernel mailing list

 

Ladění pomocí kmemcheck

link

8. únor, originál

Během posledních několika týdnů se nám s pomocí Ingo Molnára a Pekky Enberga podařilo vytvořit novou verzi kmemcheck! oznámil Vegard Nossum. Současná verze patche nabootuje na reálném hardwaru, ale na některých strojích jsem ji viděl vytuhnout, takže ještě není perfektní (jinými slovy, tento patch je VELMI experimentální, používáte ho na svoje riziko atd.). K tomu přidal krátké shrnutí, co patch dělá.

Kmemcheck je patch do linuxového jádra, který detekuje používání neinicializované paměti. Toho dosahuje zachycením všech zápisů a čtení paměti, která byla alokována dynamicky (např. pomocí kmalloc()). Jestli je čteno z paměťové adresy, na kterou nebylo nic zapsáno, do jaderného logu se vypíše zpráva.

Ingo Molnár ukázal užitečnost patche tím, že už našel 4 chyby v jádře. Také napsal další podrobnosti ohledně toho, jak patch funguje a proč je užitečný: Mělo by být zdůrazněno, že nejenom že kmemcheck spotřebuje polovinu RAM, je také velmi, velmi pomalý, protože téměř každá instrukce z jaderného prostoru vygeneruje výpadek stránky [pagefault], načež je krokována, což vyžaduje také ladící výpadek [debug fault]. To je samozřejmě totálně šílené, ale je to také OK a je to důvod, proč je tato vlastnost tak zajímavá a výkonná.

 

Citát: Nepropadejte panice

Je to ascii obrázek, který jsem před dvanácti lety vzal z něčího podpisu. Má to být chlápek z obalu jedné z edicí Stopařova průvodce po galaxii od Douglase Adamse. Nepropadejte panice! :-)

David Miller, zpráva ze 6. února 2008 na Linux kernel mailing list

 

Kgdb light

link

9. únor, originál

I když tento den je pravděpodobně jeden z posledních dní začleňovacího okna, zvaž prosím ještě přetažení gitového stromu 'kgdb light', psal Ingo Molnár.

Tohle je zeštíhlená a pročištěná verze KGDB, kterou jsem vytvořil z původních patchů poslaných před dvěma týdny. S Thomasem jsme patche prošli, vyhodili jsme všechno, co se nám nelíbilo, a pročistili zbytek. KGDB je stále stejně funkční, jako bylo předtím (testoval jsem to na 32-bit i 64-bit x86) a jakékoliv schopnosti či problematičtější záležitosti navíc by měly být přidány jako rozdílová vylepšení, nikoliv v tomto počátečním začlenění.

Ingo poznamenal, že předchozí verze modifikovala 41 souborů, kdežto tento nový požadavek jich mění pouze 22. Ze změn upozornil zvláště na tyto:

Ingo to shrnul: Výsledkem je, že série patchů kgdb má zjevně na jádro nulový dopad, protože se prostě nedotýká žádné nebezpečné cesty v kódu [codepath]. Z toho stavu se KGDB může vyvíjet malými, dobře kontrolovanými dětskými krůčky stejně jako ostatní jaderný kód. Výsledné kgdb stále velmi dobře funguje; stále může přerušit běh jádra (pomocí SysRq-G), může zachytit pády, může krokovat atd. Už nyní je to použitelný první krok.

 

Citát: Když budeš pozorně naslouchat

Když budeš pozorně naslouchat, uslyšíš tucty vývojářů linuxového jádra, kteří kolektivně zadržují dech a myslí si 'Možná Linus konečně začlení kgdb'. Ano, hlášení o chybách od uživatelů jsou důležitá. Efektivita vývojářů je důležitá také.

Daniel Phillips, zpráva ze 7. února 2008 na Linux kernel mailing list

2.6.25-rc1, "pekelně velký"

link

10. únor, originál

Ok, tohle je pekelně velký -rc (ostatně, to byl i 24-rc1), pravděpodobně protože vývojový cyklus 2.6.24 se protáhl, takže lidé měli připravenou spoustu věcí, psal Linus Torvalds v oznámení jádra 2.6.25-rc1, kompletní diff je asi 11 MB velký a má 1,4 M lišících se řádek, z čehož většina jsou aktualizace architektur a ovladače.

Abych se trochu pobavil, udělal jsem jednoduché statistiky - z 1,4 M řádek je okolo 38 % - 530k řádek - v souborech týkajících se architektur (400k+ řádek v arch/, 100k+ řádek v include/asm-*). Další velký shluk je v ovladačích (včetně zvuku), má podíl 44 % - 610k řádek - změn. Zbytek je mnohem menší, viditelnější je ještě síťování (8 % - 110k řádek), souborové systémy se 4 % a dokumentace 2 %. Zbylé drobty jsou rozházeny hlavně v blokové vrstvě, crypto, jádře jádra [kernel core] a aktualizaci bezpečnostní vrstvy (tj. SElinux a smack). Linus upozornil na některé změny:

 

Citát: Nejošklivější patch v historii

Nebo bychom mohli napsat nejošklivější patch v historii, tedy

-#define pcibus_to_node(node)   (-1)
+#define pcibus_to_node(node)   ((int)(long)(node),-1)

Wow. To je tak ošklivé, že to skoro přetéká, přechází na druhou stranu a vypadá hezky.

Linus Torvalds, zpráva z 11. února 2008 na Linux kernel mailing list

Patch pro CVE-2008-0600, chybu umožňující získání roota

link

11. únor, originál

Patche pro chybu jádra Linuxu, která umožňovala lokálně získat práva roota, byly dnes vydány jako 2.6.24.2, 2.6.23.16 a 2.6.22.18. Nejnovější chyba značená jako CVE-2008-0600 byla do jádra 2.6 zanesena ve verzi 2.6.17 se systémovým voláním vmsplice(). Je to již třetí v sérii chyb umožňujících získání roota, které se tohoto systémového volání týkají. Dvě dřívější byly označeny CVE-2008-0009 a CVE-2008-0010. Pro staré CVE-2008-0010, které se týkalo jader 2.6.23 a 2.6.24, i pro nové CVE-2008-0600 existují snadné způsoby, jak chybu zneužít, což lokálnímu uživateli umožňuje získat oprávnění superuživatele.

Související články

Jaderné noviny - 4 a 5/2008
Jaderné noviny - 3/2008
Jaderné noviny - 1/2008
Jaderné noviny - 46 a 47/2007

Odkazy a zdroje

kerneltrap.org

Další články z této rubriky

Jaderné noviny – přehled za březen 2024
Jaderné noviny – přehled za únor 2024
Jaderné noviny – přehled za leden 2024
Jaderné noviny – přehled za prosinec 2023
Jaderné noviny – přehled za listopad 2023

ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.