Jaderné noviny - 5. 4. 2006

18. 4. 2006 | Robert Krátký | Jaderné noviny | 4816×

Aktuální verze jádra: 2.6.17-rc1. Citát týdne: Al Viro. Odvozování priorit v jádře. O bezpečnosti sysfs rozhraní. Dokumentování paměťových bariér. Konec přijímaní patchů do 2.6.17.

Aktuální verze jádra: 2.6.17-rc1

Aktuální předverze je 2.6.17-rc1. Linus ji vydal 2. dubna. Od minulého týdne byly začleněny patche obsahující systémová volání splice() a sync_file_range() (viz níže), podporu hotplug paměti pro User-mode Linux, subsystém LED, konverzi local_t na typ se znaménkem, základní podporu braillových zařízení pro vstupní vrstvu a ovladač "ipath" pro zařízení PathScale InfiniPath. Vizte shrnutí z minulého a předminulého týdne - v nich najdete podrobné seznamy změn v 2.6.17-rc1. Ještě více podrobností je v krátkém a dlouhém changelogu.

Od vydání 2.6.17-rc1 nebyly do hlavního stromu přijaty žádné patche.

Aktuální -mm strom je 2.6.17-rc1-mm1. Mezi nedávné změny patří velké množství oprav a nová verze debuggeru kgdb. Jinak nic zásadního.

Citát týdne: Al Viro.

Které části z "patche pro sysfs by mohli psát idioti - a většinou je píší" je tak těžké porozumět? Aha, moment. Už chápu... No dobře, tak to nic...

-- Al Viro je zpět.

Dvě nová systémová volání: splice() a sync_file_range()

Jádro 2.6.17 bude obsahovat dvě nová systémová volání, která zajímavým způsobem rozšiřují možnosti uživatelských programů. Tento článek se dívá na současnou podobu těchto nových rozhraní.

splice()

Systémové volání splice() má dlouhou historii. Jako první jej navrhl Larry McVoy v roce 1998; bralo se to jako způsob zlepšení I/O výkonu na serverových systémech. Přestože se o tom v následujících letech často mluvilo, nebyla žádná implementace splice() pro hlavní jádro napsána. To se však změnilo těsně před ukončením přijímání patchů pro 2.6.17, když byl s mnohými úpravami začleněn splice() patch od Jense Axboea.

V době psaní tohoto textu vypadalo rozhraní splice() takto:

    long splice(int fdin, int fdout, size_t len, unsigned int flags);

Volání splice() způsobí, že jádro přesune až len bajtů z datového zdroje fdin do fdout. Data se budou pohybovat pouze v rámci jádra, kopírování bude minimum. V současné implementaci musí alespoň jeden z těch dvou popisovačů souborů [file descriptors] ukazovat na rouru [pipe device]. Tato podmínka je omezením stávajícího kódu a mohla by být někdy v budoucnu odstraněna.

Parametr flags upravuje, jak je kopírování prováděno. Implementovány jsou následující možnosti:

• SPLICE_F_NONBLOCK: splice() operace nebudou blokovat. Volání splice() by i tak mohlo blokovat v případě, že by jeden z popisovačů souborů nebyl nastaven na neblokovací I/O.
• SPLICE_F_MORE: řekne jádru, že v dalším volání splice() přijde více dat.
• SPLICE_F_MOVE: je-li výstup soubor, řekne tento parametr jádru, že se má pokusit přesouvat stránky přímo ze vstupního bufferu roury do výstupního adresního prostoru, čímž se předejde kopírování.

Interně funguje splice() pomocí mechanismu rourového bufferu, který přidal Linus na počátku roku 2005 - proto se zatím vyžaduje, aby byla na jedné straně operace roura. Dva přírůstky přibyly do stále větší struktury file_operations pro zařízení a souborové systémy, které chtějí splice() podporovat:

    ssize_t (*splice_write)(struct inode *pipe, struct file *out, 
                            size_t len, unsigned int flags);
    ssize_t (*splice_read)(struct file *in, struct inode *pipe, 
                           size_t len, unsigned int flags);

Tyto nové operace by měly přesunout len bajtů mezi pipe a buď in nebo out, podle zadaných flags. Pro souborové systémy existují obecné implementace těchto operací, které lze použít; také je k dispozici generic_splice_sendpage(), která se používá pro umožnění "splicování" na socket. Zatím nejsou žádné implementace splice() pro ovladače zařízení, ale do budoucna tomu nic nebrání - alespoň pro znaková zařízení.

Diskuze v konferenci linux-kernel naznačují, že rozhraní splice() by mohlo ještě doznat změn předtím, než bude vytesáno do kamene v jádře 2.6.17. Andrew Tridgell požadoval přidání offsetového parametru, aby šlo určit, kde má kopírování začít - buď to, nebo by se mělo přidat samostatné psplice(). Vyskytly se také pochybnosti o způsobu, kterým jsou zpracovávány chyby; pokud volání splice() vrátí chybu, jak aplikace zjistí, jestli je problém se vstupem nebo výstupem? Vyřešení těchto otázek si možná během příštího měsíce vyžádá nějaké změny rozhraní.

sync_file_range()

Na začátku příprav 2.6.17 byly začleněny změny systémového volání posix_fadvise(). Ty nové - linuxové - volby mají za účel dát aplikacím lepší kontrolu nad tím, jak jsou data zapisovaná do souborů dávána na fyzická média. Zmíněné doplněné možnosti jsou potřeba, ale vyskytly se obavy z jakéhokoliv čistě linuxového rozšiřování POSIXové funkce. Výsledkem bylo, že Andrew Morton patch stáhl a nahradil ho novým systémovým voláním:

    long sync_file_range(int fd, loff_t offset, loff_t nbytes, int flags);

Toto volání sesynchronizuje data souboru na disk počínaje zadaným offset a bude pokračovat nbytes bajtů (nebo do konce souboru, bude-li nbytes nula). Způsob synchronizace je určen pomocí flags:

• SYNC_FILE_RANGE_WAIT_BEFORE blokuje volající proces, dokud nebude dokončeno jakékoliv již probíhající vypisování stránek (v daném rozsahu).
• SYNC_FILE_RANGE_WRITE začne vypisovat všechny nečisté stránky v daném rozsahu, u kterých už neprobíhá nějaký I/O.
• SYNC_FILE_RANGE_WAIT_AFTER blokuje volající proces, dokud neskončí nově iniciované zápisy.

Aplikace, která chce iniciovat writeback [zápis na disk] všech nečistých stránek, by měla poskytnout první dva parametry. Když poskytne všechny tři, je zaručeno, že ty stránky skutečně budou na disku, až volání skončí.

Nová implementace nemění systémové volání posix_fadvise(). Zároveň umožňuje provádění synchronizačních operací jediným voláním místo několikerých, která vyžadoval předchozí pokus. V budoucnu bude pravděpodobně možné přidat do seznamu flags další operace; možnost vyžadovat synchronizaci metadat bude asi první.

(Díky Michaelu Kerriskovi - který tuto změnu prosazoval - za poskytnutí bližších informací).

Odvozování priorit v jádře

Představte si systém se dvěma běžícími procesy, jeden s vysokou prioritou, druhý s o hodně nižší. Tyto procesy sdílejí zdroje chráněné zámky. V jednu chvíli se procesu s nižší prioritou podaří chvíli běžet a získat zámek jednoho ze zdrojů. Pokud se pak pokusí prioritní proces získat stejný zámek, bude muset počkat. Proces s nízkou prioritou tak vlastně přebil ten s vysokou - přinejmenším dokud bude držet ten požadovaný zámek.

A teď si představte třetí proces, který spotřebovává hodně procesorového času, a jehož priorita je někde mezi těmi dvěma. Začne-li tento proces makat, vytlačí ten s nízkou prioritou od CPU úplně. Výsledkem je, že třetí proces může ten proces s nejvyšší prioritou držet donekonečna v šachu.

Tato situace, která se nazývá "obrácení priority" [priority inversion], mívá většinou na svědomí selhání systému, otrávené uživatele a nezaměstnané inženýry. Existuje několik přístupů k boji s obrácením priority: systém bez zámků, pečlivě promyšlené zamykací postupy a technika známá jako odvozování priorit. Odvozování priorit má jednoduchý koncept: když proces drží zámek, měl by běžet alespoň s takovou prioritou, jako má proces s nejvyšší prioritou z těch, které na zámek čekají. Je-li zámek zachycen nízkoprioritním procesem, může být nutné jeho prioritu zvýšit až do chvíle, kdy bude zámek uvolněn.

Odvozování priorit může mít více podob. I jádro vlastně využívá velmi jednoduchou formu, když neumožňuje jadernému kódu preempci zatímco drží spinlock. Na některých systémech má každý zámek přiřazenou prioritu; vezme-li zámek proces, je jeho priorita zvýšena na prioritu zámku. Na jiných je procesu, který drží vyžadovaný zámek, priorita "odvozena" od priority procesu s vysokou prioritou. Většina způsobů odvozování priorit projevuje tendenci komplikovat a zpomalovat zamykací kód a dá se jich zneužít k zakamuflování mizerných designů aplikací. Takže jsou v mnoha kruzích neoblíbené. Linus se minulý prosinec o tématu vyjádřil celkem jasně:

"Kamarádi nenechají kamarády používat odvozování priorit".

Prostě to nedělejte. Pokud to skutečně potřebujete, máte tak jako tak vadný systém.

Pozn. "Kamarádi nenechají kamarády řídit v opilosti" ("Friends don't let friends drive drunk") je hlavním sloganem známé kampaně amerických úřadů, která má za cíl poučit lidi o nebezpečnosti řízení pod vlivem alkoholu.

Tváří v tvář takovému odporu by většina vývojářů potichu sbalila své plány na odvozování priorit zpátky do šuplíku a vrátila by se k něčemu jednoduššímu. Komunita vývojářů linuxového jádra má však jednoho člena, který proslul schopností prosadit svůj kód do jádra i přes podobné námitky: Ingo Molnar. Historie se možná bude opakovat, protože Ingo (ve spolupráci s Thomasem Gleixnerem) poslal implementaci futexů s odvozováním priorit s žádostí, aby byla začleněna do hlavního jádra. Ingo tvrdí, že navrhovaný přístup poskytuje užitečné funkce uživatelskému prostoru (nemá poskytovat základní jaderné funkce vzájemného vyloučení s odvozováním priorit [priority-inheriting kernel mutual exclusion primitives]), ale vyhýbá se problémům, se kterými se potýkaly jiné implementace.

Patch s PI-futex (PI - Priority Inheritence = odvozování priorit) přidává pár nových operací do systémového volání futex(): FUTEX_LOCK_PI a FUTEX_UNLOCK_PI. Když není více zájemců, může být PI-futex zabrán, aniž by se zapojovalo jádro - stejně jako v případě obyčejného futexu. Existuje-li více zájemců, je od jádra vyžádána operace FUTEX_LOCK_PI. Žádající proces je zařazen do speciální fronty a, je-li to nutné, propůjčí svou prioritu procesu, který požadovaný futex drží. Odvozování priorit je zřetězené, takže je-li proces, který drží zámek, blokován na dalším futexu, bude zvýšená priorita přenesena i na držitele toho dalšího futexu. Jakmile je futex uvolněn, veškerá přidaná přiorita je odebrána.

Podobně jako u běžných futexů je to tak, že jádro musí vědět jen o těch PI-futexech, na které je více zájemců. Takže počet futexů v systému může docela narůst, aniž by to představovalo velkou režii pro jádro.

V jádře je typ PI-futex implementován pomocí nové základní funkce nazývané rt_mutex. rt_mutex je na první pohled podobná běžným mutexům, ale je doplněna o možnost odvozování priorit. Jde však o zcela odlišný typ, s implementací mutexů nesdílí žádný kód. API však bude uživatelům mutexů povědomé; ve stručnosti:

    #include <linux/rtmutex.h>

    void rt_mutex_init(struct rt_mutex *lock);
    void rt_mutex_destroy(struct rt_mutex *lock);

    void rt_mutex_lock(struct rt_mutex *lock);
    int rt_mutex_lock_interruptible(struct rt_mutex *lock, 
                                    int detect_deadlock);
    int rt_mutex_timed_lock(struct rt_mutex *lock,
                            struct hrtimer_sleeper *timeout,
			    int detect_deadlock);
    int rt_mutex_trylock(struct rt_mutex *lock);
    void rt_mutex_unlock(struct rt_mutex *lock);
    int rt_mutex_is_locked(struct rt_mutex *lock);

Pozornému čtenáři možná neuniklo, že to vypadá podobně jako realtime mutex z patche pro realtime preempci. Ingo jednou řekl, že realtime patche se do jádra postupně dostanou; a tímhle to možná začíná. S tímto patchem by byl PI-futex kód jediným uživatelem nového typu rt_mutex, ale to se může časem změnit.

PI-futex patch také obsahuje nový druh seznamu tříděného podle priorit, který by mohl najít uplatnění i na jiných místech jádra.

Zatím se o tomto patchi příliš nediskutovalo; byl zařazen v posledních -mm stromech. Pro 2.6.17 je už pozdě, ale pokud si nenajde vážného odpůrce, mohl by se PI-futex kód dostat do další verze.

O bezpečnosti sysfs rozhraní

Jedním z patchů v 2.6.16.2 je oprava bezpečnostní chyby označené jako CVE-2006-1055. Jde o malou změnu v kódu, který implementuje možnost zapisovat do atributů sysfs. Změna omezuje maximální objem dat, který může být do atributu zapsán, na PAGE_SIZE-1 bajtů, neboli 4095 na většině systémů. Od minulého června byl limit prostě PAGE_SIZE, což umožňovalo zapsání celé stránky.

Protože před zaplněním je prostor vyplněn nulami, zajistí tato změna, že data přicházející z uživatelského prostoru budou při odeslání konkrétní sysfs store() funkci ukončena nulou. Bez této pojistky by funkce mohla vesele začít mimo konec toho jednostránkového bufferu a přistupovat k datům, která nepřišla z uživatelského prostoru, a případně i přepsat buffery jinde. Tato možnost stačila k tomu, aby to bylo považováno za bezpečnostní chybu, která si vyžaduje rychlou opravu.

Zajímavé na tom je, že prototyp funkce store() vypadá takto:

    ssize_t (*store)(struct kobject *kobj, struct attribute *attr,
                     const char *buffer, size_t size);

Parametr size je objem posílaných uživatelských dat. Takže by bylo možné se ptát, proč se otravovat s ukončováním bufferu nulami, když byla jeho velikost už poskytnuta kódu, který data přijímá. Někteří vývojáři, jejichž kód dostával prostřednictvím sysfs atributů data o 4096 bajtech, se takto skutečně ptali.

Odpověď je v jistém smyslu obsažena v citátu týdne. Diplomatičtěji by šlo říci, že bez ohledu na to, jak je rozhraní navrženo, množství implementací sysfs atributů bylo programováno na základě předpokladu, že příchozí data budou ukončena nulami. Takže se neobtěžují s kontrolou objemu dat a v případě absence očekávaného ukončení budou provádět nehezké věci.

V 2.6.16.2 je situace napravena a zmiňované implementace jsou opět bezpečné. Ale je těžké nebýt z toho alespoň trochu nervózní. Je-li v jádře nedbale psaný kód, mohly by s ním být další potíže a ukončení nulami by nijak nepomohlo. Bylo by lepší, kdyby existoval způsob, jak ověřit, že jsou rozhraní využívána korektně. Prozatím by si lidé, kteří píší sysfs rozhraní - z nichž každé je rozhraním k uživatelskému prostoru a možným cílem útoku - měli kód před odevzdáním lépe zkontrolovat.

---

Následující obsah je © KernelTrap

Dokumentování paměťových bariér

2. dub, originál

David Howells poslal do konference dokument o paměťových bariérách [memory barriers]. Paměťové bariéry představují způsob, jak uspořádat I/O přístupy jádra k zařízením. Dokument prošel mnoha revizemi na základě reakcí vývojářů. Výtažek:

... nezávislé operace s pamětí jsou prováděny v náhodném pořadí, což může být problém pro součinnost dvou a více CPU a I/O. Je potřeba nějakým způsobem zasáhnout a říci kompilátoru a procesoru, aby dodržovaly pořadí.

Paměťové bariéry jsou takovými zásahy. Zavádějí pomyslné dílčí řazení paměťových operací na obou stranách bariéry. Vyžadují, aby posloupnost generovaných událostí vypadala z pohledu zbytku systému jakoby byla bariéra na daném procesoru doopravdy.

Konec přijímaní patchů do 2.6.17

3. dub, originál

Linus Torvalds oznámil jádro 2.6.17-rc1: Od 2.6.16 uplynuly dva týdny, takže končí doba vymezená pro začleňování patchů. Zmiňovaná doba je součástí vývojového modelu od Summitu vývojářů linuxového jádra 2005, na kterém se rozhodlo, že všechny zásadní změny musí být začleněny během dvou týdnů od vydání hlavní verze, přičemž zbytek vývojového cyklu bude zaměřen na opravování chyb [viz Jaderné noviny 327: nová pravidla pro rychlejší vydávání nových verzí jádra].

K aktuální verzi Linus poznamenal: Jako obvykle je -rc1 patch zatraceně velký a dokonce i krátká verze changelogu se nevejde do limitu na velikost zpráv v konferenci. Ale mám takový dojem, že většina jsou věci jako nové ovladače a hodně je toho méně děsivého než první změny v 2.6.16. Nejnápadnější změnou bude pravděpodobně začlenění podpory architektury Niagara od Sunu, ale je tam toho ještě víc: reorganizace DVB, aktualizace nfs/knfsd, aktualizace x86-64/parisc/mips/powerpc, ALSA, SCSI, Infiniband... A zároveň je tu slušná várka běžných čistek (konverze BUG_ON, konverze semafor->mutex, pročištění bitops atd.).

       

Komentáře

[Wentasah]

Nejak se mi nezamlouva prekladat vyraz memory barrier jako hranice paměti. Pod pojmem hranice pameti si predstavim spis adresu, kde zacina ci konci nejaka specialeni oblast pameti. Napr. u jednocipu flash pamet ci RAM, nebo v pripade jadra OS hranice pametoveho prostoru jadra.

Az doposud jsem se bezne setkaval s prekladem pametova bariera nebo jen bariera a myslim si, ze tento preklad je vystiznejsi nez pouziti slova hranice.

[Robert Krátký]

Nejak se mi nezamlouva prekladat vyraz memory barrier jako hranice paměti.

Mně také ne. Dlouho jsem nad tím přemýšlel, ale nakonec jsem to zvolil jako nejmenší zlo. Trochu jsem doufal, že se v diskuzi někdo ozve s vhodnějším překladem.

Az doposud jsem se bezne setkaval s prekladem pametova bariera

Už jsem to tak měl dokonce napsané, ale pak jsem to zase změnil zpět na "hranici". Důvodem bylo, že mi to při použití "bariéra" znělo jakoby byla blokována celá paměť. Protože je však - jak říkáš - překlad "paměťová bariéra" v češtině ustálený, opravím to.

Dík.

[Ricardo]

Hezké, zajimavé, poučné. Ale když se tak dívám na některé překlady termínů, nebylo by od věci uvažovat o ponechání původního anglického slova? (A popřípadně pod článek uvést odkaž na slovník, ať si o daném výrazu udělá obraz každý sám.)

Uvedl bych příklad z literatury. Fantasy román Warcraft-Den draka od R.A.Knaaka (orig. Warcraft-Day of the Dragon). Jak uvádí překladatel v jedné poznámce k jménu Deathwing:

"*Death znamená ... Nebudu znásilňovat češtinu, pokud chcete, přeložte si jeho jméno sami, nebude však znít tak nádherně strašlivě. ..."

[Robert Krátký]

nebylo by od věci uvažovat o ponechání původního anglického slova?

Občas to tak dělám (buffer, scheduler, ...). Ale snažím se tomu vyhýbat a většinu termínů překládat. V angličtině ponechávám jen ty, které jsou opravdu dobře zažité.

(A popřípadně pod článek uvést odkaž na slovník, ať si o daném výrazu udělá obraz každý sám.)

Tak to určitě ne. Pokud někdo daný jazyk neumí, slovník mu ve většině případů příliš nepomůže. Překládání by pak ztratilo smysl - to by stačilo dát odkaz na původní text. Ale tak jako tak uvádím u mnoha termínů původní výraz v hranatých závorkách, aby byl text dobře čitelný i pro ty, kdo jsou zvyklí ta slova vídat spíše v angličtině.

Jak uvádí překladatel v jedné poznámce k jménu Deathwing:

"*Death znamená ... Nebudu znásilňovat češtinu, pokud chcete, přeložte si jeho jméno sami, nebude však znít tak nádherně strašlivě. ..."

S takovým přístupem se neztotožňuji (teď mluvím hlavně o beletrii). Jedná-li se o překlad, pak by měla být přeložena i vymyšlená vlastní jména. Dno pytle, Zeměplocha, ... Znásilňování češtiny se nekoná, je-li autor překladu sám dobrým spisovatelem, který si s tím umí poradit.

[trekker.dk]

Problém je v tom, že takové překladatele bys spočítal na prstech jedné ruky.