Jaderné noviny – 3. 12. 2014: 2. verze sady oprav kdbus

5. 1. 2015 | Tadeáš Pelech | Jaderné noviny | 2486×

Aktuální verze vývojového jádra: 3.18-rc7. Citáty týdne. Stupidní triky RCU: rcutorture zachytí chybu RCU. Odeslána 2. verze oprav kdbus. ACCESS_ONCE() a chyby překladače. 2. verze sady oprav kdbus.

Obsah

• Aktuální verze vývojového jádra: 3.18-rc7
• Citáty týdne
• Stupidní triky RCU: rcutorture zachytí chybu RCU
• Odeslána 2. verze oprav kdbus
• ACCESS_ONCE() a chyby překladače
• 2. verze sady oprav kdbus

Aktuální verze vývojového jádra: 3.18-rc7

Aktuální vývojové jádro je 3.18-rc7. Vývojové jádro 3.18-rc7 vyšlo dne 30. listopadu (oznámení). Zdá se, že Linus je celkem spokojen, navzdory přetrvávajícímu problému s uzamčením, který prozatím odolává všem pokusům o ladění. Linus k tomu řekl:

Zároveň se blíží svátky a tento problém není žádná regrese, domnívám se, že nakonec by se mi mohlo podařit vydat verzi 3.18 včas za týden, protože kdybych vydání odložil, buď by začleňovací okno kolidovalo se svátky, nebo bych ho musel hodně odložit.

Verze 3.18-rc6 byla vydána 23. listopadu (oznámení).

Stabilní aktualizace: Aktualizace verzí 3.17.4, 3.14.25 a 3.10.61 byly vydány dne 21. listopadu.

Citáty týdne

Tohle je těžké!!! Půjdeme radši programovat jednovlákově!

– Paul McKenney

Těšíme se na opravu, která z nás všech ve výchozím nastavení udělá lenochy.

– Chris Mason; člověk by mohl namítnout, že byla zavedena už před lety.

static inline void *
vymyslete_pro_to_nekdo_nazev(gfp_t gfp_mask, unsigned int order)
{
    return (void *)__get_free_pages(gfp, order);
}

– Design API, ve stylu Andrewa Mortona

Stupidní triky RCU: rcutorture zachytí chybu RCU

Paul McKenney na svém blogu zkoumá chybu v RCU (read-copy-update) při přípravě na začleňovací okno verze 3.19. „Samozřejmě, všichni máme konkrétní opravy, které podezříváme. Proto jsem v dalším kroku odvolal podezřelé opravy a snažil se všemožně tu chybu odhalit. Bohužel jsem rychle zjistil, že je ta chyba obtížně reprodukovatelná a vyžaduje asi 100 hodin soustředěného testování rcutorture. Bisekce na základě 100 hodin testů by si vyžádala zbytek roku 2014 a významnou část roku 2015, proto bylo potřeba vymyslet něco lepšího. Bylo ale potřeba udělat něco mnohem lepšího, protože chyb bylo tak málo, a proto předpokládaná doba na jejich zopakování by mohla dosáhnout 200 hodin nebo dokonce 300 hodin místo mého původního odhadu 100 hodin.“

Odeslána 2. verze oprav kdbus

Druhou verzi oprav kdbus odeslal do e-mailové konference linuxového jádra Greg Kroah-Hartman. Největší změnou oproti první sadě oprav (kterou jsme popisovali začátkem listopadu) je, že kdbus nyní poskytuje rozhraní v podobě souborovém systému (kdbusfs) místo rozhraní /dev/kdbus v podobě zařízení. Současně došlo k řadě dalších změn v reakci na komentáři k verzi 1. „kdbus je implementace IPC na úrovni jádra, která se zaměřuje na podobnost s vrstvou protokolu s existujícím uživatelským prostorem démona D-Bus a současně aktivuje některé funkce, které nemohly být dříve v uživatelském prostoru implementovány.“

ACCESS_ONCE() a chyby překladače

Makro ACCESS_ONCE() se používá v celém jádru proto, aby zajistilo, že kód generovaný překladačem bude přistupovat k uvedené proměnné jednou (a pouze jednou); podrobnosti o způsobu činnosti a případech, kdy je jejich použití nezbytné, viz tento článek. Když tento článek vznikal (2012), bylo v jádru 200 vyvolání ACCESS_ONCE(); nyní jich existuje více než 700. ACCESS_ONCE() se – jako mnoho nízkoúrovňových technik správy souběhu – opírá o trik, který je lepší příliš nerozebírat. A tyto techniky se můžou pokazit, pokud se změní chování překladače nebo, jak se stává v poslední době, obsahují chybu.

Již v listopadu Christian Borntraeger odeslal zprávu týkající se interakcí mezi ACCESS_ONCE() a jakousi nejasnou chybou GCC. Pro pochopení problému je vhodné podívat se na makro, které je definováno jednoduše v současných jádrech (v <linux/compiler.h>):

    #define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))

Stručně řečeno, ACCESS_ONCE() vynutí, aby byly proměnné považovány za typ volatile, i když tak (stejně jako téměř všechny proměnné v jádře) deklarovány nejsou. Problém ohlášený Christianem je, že GCC 4.6 a 4.7 odhodí modifikátor volatile, pokud proměnná předaná do něj není typu scalar. To funguje dobře, například pokud x je int, ale ne, pokud x je složitějšího typu. Například ACCESS_ONCE() se často používá s položkami stránkovací tabulky, které jsou definovány jako typ pte_t:

    typedef struct {
	unsigned long pte;
    } pte_t;

V tomto případě bude sémantika volatile ztracena v překladačích s chybami, což povede k jádrům s chybami. Christian začal hledat způsoby, jak tento problém obejít, potom se ale dozvěděl, že běžná praxe v jádru je vyhýbat se pokud možno obcházení chyb překladače; místo toho je vhodnější chybové verze v systému sestavení jádra zařadit na černou listinu. Ale verze 4.6 a 4.7 jsou nainstalované v řadě systémů a jejich zařazení na černou listinu by nadělalo problémy mnoha uživatelům. A jak poznamenal Linus, mohou existovat důvody pro jiné přístupy než černé listiny:

Proto souhlasím s Heikem, že obecně chyby překladače není vhodné obcházet, pokud je možné jim předejít. Někdy ale chyby překladače končí oznámením: „děláš něco hodně křehkého“. Možná bychom měli zkusit být tady méně křehcí.

Jeden ze způsobů méně křehkého přístupu by bylo změnit ovlivněná volání ACCESS_ONCE() tak, aby odkazovala na skalární části příslušných neskalárních typů. Pokud tedy program provede například něco jako:

    pte_t p = ACCESS_ONCE(pte);

Mohlo by se to změnit na něco jako:

    unsigned long p = ACCESS_ONCE(pte->pte);

Tento druh změny však vyžaduje auditování všech volání ACCESS_ONCE(), aby byla nalezena ta, která nepoužívají skalární typy; to by byl zdlouhavý proces náchylný na chyby, který by nezabránil vzniku nových chyb.

Jiný přístup k problému, který zkoumá Christian, by bylo odstranit řadu problematických volání ACCESS_ONCE() a jen nastavit překladači bariéry pomocí barrier(). V mnoha případech bariéra postačuje, v některých ovšem ne. Opět je vyžadován podrobný audit a nic nebrání tomu, aby se v kódu objevovala nová volání ACCESS_ONCE() s chybami.

A proto se Christian pustil do změn ACCESS_ONCE(), kterými by jednoduše mohl zcela zakázat používání neskalárních typů. V  nejnovější verzi sady oprav vypadá ACCESS_ONCE() takto:

    #define __ACCESS_ONCE(x) ({ \
	       __maybe_unused typeof(x) __var = 0; \
	       (volatile typeof(x) *)&(x); })
    #define ACCESS_ONCE(x) (*__ACCESS_ONCE(x))

Tato verze způsobí selhání překladu, pokud je do makra předán neskalární typ. Ale co případy, kdy je třeba použít neskalární typ? Pro tyto případy Christian zavedl dvě nové makra, READ_ONCE() a ASSIGN_ONCE(). Definice prvního vypadá takto:

    static __always_inline void __read_once_size(volatile void *p, void *res, int size)
    {
    	switch (size) {
    	case 1: *(u8 *)res = *(volatile u8 *)p; break;
    	case 2: *(u16 *)res = *(volatile u16 *)p; break;
    	case 4: *(u32 *)res = *(volatile u32 *)p; break;
    #ifdef CONFIG_64BIT
    	case 8: *(u64 *)res = *(volatile u64 *)p; break;
    #endif
        }
    }
   
    #define READ_ONCE(p) \
          ({ typeof(p) __val; __read_once_size(&p, &__val, sizeof(__val)); __val; })

V podstatě to funguje vynucením použití skalárních typů i v případě, kdy předávaná proměnná takového typu není. Vytvořit makro jednotného přístupu, které by fungovalo na obou stranách přiřazení, se ukázalo být mnohem složitější, proto byla pro případy na levé a pravé straně připravena samostatná makra ASSIGN_ONCE().

Christianova sada oprav nahrazuje volání ACCESS_ONCE() za READ_ONCE() nebo ASSIGN_ONCE() v případech, kdy je potřebné to druhé. Komentáře v kódu naznačují, že tato makra by měla mít v budoucnosti přednost před ACCESS_ONCE(), ale většina stávajících volání ACCESS_ONCE() nebyla změněna. Vývojáři používající ACCESS_ONCE() k přístupu k neskalárním typům však v budoucnu čeká od překladače nepříjemné překvapení.

Tato verze opravy se dočkala několika komentářů a pravděpodobně se v blízké budoucnosti dostane do hlavního stromu; na řadě jsou pravděpodobně i backporty do stabilních řad. Jsou chvíle, kdy je nejlepší jednoduše se zcela vyhnout verzím překladače se známými chybami. Ale jak je vidět zde, chyby překladače lze také vnímat jako signál, že lze v jádru najít lepší řešení, a tím dosáhnout celkově robustnějšího kódu.

2. verze sady oprav kdbus

Když koncem října dorazila do linuxového jádra dlouho očekávaná sada oprav kdbus, dočkala se od recenzentů řady kritických komentářů. Někteří vývojáři by se v beznaději vzdali a stěžovali by si na nepřátelské postoje komunity vývojářů jádra. Vývojáři kdbus ale takoví nejsou. To je patrné ve 2. odeslané verzi; kód se výrazně změnil v reakci na připomínky vznesené po zveřejněné první verze. Kdbus pravděpodobně stále není připraven na okamžité začlenění do hlavní struktury, ale zjevně se mu přibližuje.

Již žádné soubory zařízení

Jednou z největších stížností na první verzi bylo její používání souborů zařízení k řízení interakce se systémem. Zařízení musí být pojmenována; to si vyžádalo hierarchický globální systém názvů na doménách kdbus, které jinak ze své podstaty nebyly hierarchické. Globální obor názvů si vynutil oprávnění, takže pro neprivilegované uživatele je těžší vytvářet domény kdbus; současně přidal komplikace pro uživatele, kteří chtěli kontrolní bod a kontejnery obnovení.

Druhá verze odstraňuje abstrakci zařízení a nahrazuje ji virtuálním systémem souborů jménem „kdbusfs“. Tento systém souborů bude obvykle připojen pod /sys/fs/kdbus. K vytvoření nové domény kdbus (kontejneru, který obsahuje obor názvů pro jeden nebo více sběrnic) stačí jen připojit instanci tohoto systému souborů; doména bude zachována, dokud nebude systém souborů odpojen. K vytvoření nové domény nejsou potřebná žádná zvláštní oprávnění – ale připojení systému souborů stále vyžaduje vlastní oprávnění.

Nově vytvořená doména nebude na počátku obsahovat žádné sběrnice. Má soubor s názvem control; sběrnici lze vytvořit otevřením tohoto souboru a zadáním příkazu KDBUS_CMD_BUS_MAKE ioctl(). Taková sběrnice bude existovat, dokud bude otevřen popisovač souboru control. Pro jeden popisovač souboru control lze vytvořit jen jedna sběrnice, ale soubor control lze otevřít vícekrát a vytvořit více sběrnic. Soubor control lze také použít k vytvoření vlastních koncových bodů pro běžně používané služby.

Každá sběrnice je reprezentována vlastním adresářem pod adresářem domény; koncové body jsou reprezentovány jako soubory v adresáři sběrnice. K připojení k sběrnice stačí otevřít soubor kdbusfs odpovídající požadovanému koncovému bodu; pro většinu klientů to bude soubor s prostým názvem bus. Zprávy lze odesílat a přijímat pomocí příkazů ioctl() na výsledný popisovač souboru.

Jak je vidět, abstrakce zařízení zmizela, ale rozhraní stále poněkud připomíná zařízení tím, že je silně založené na voláních ioctl(). Došlo k menším diskusím o tom, zda by nedávalo větší smysl používat pro interakci s kdbus operace jako read() a write(), ale zdá se, že zájem o provedení takové změny (nebo přímo žádost o ni) je malý.

Problémy metadat

K významné změně došlo v oblasti bezpečnosti. V 1. verzi může příjemce zprávy určit sadu informací o pověření, které musí doprovázet zprávu. Tyto informace mohou zahrnovat cokoli od ID procesu po možnosti, informace příkazového řádku, informace o auditu, ID zabezpečení a další. Někteří recenzenti (zejména Andy Lutomirski) si stěžovali, že tento přístup by mohl vést k úniku informací a možná i horším bezpečnostním problémům; navrhují, aby místo toho měl mít kontrolu nad metadaty doprovázejícími zprávu odesílatel zprávy.

Aktualizovaná sada oprav obsahuje odpověď na tuto žádost změnou protokolu. Když se klient připojí k sběrnici, pomocí příkazu KDBUS_CMD_HELLO ioctl() nastaví řadu parametrů pro připojení; jeden z těchto parametrů je teď bitová maska popisující, která metadata lze odesílat se zprávami. Je ale možné, aby tvůrce sběrnice určil minimální sadu metadat provázejících zprávy; v takovém případě se klient, který daná metadata odmítne poslat, nebude moci k sběrnici připojit.

Existují ještě jisté neshody v tom, která metadata mají být odeslána, zda je to volitelné nebo ne. Andy nesouhlasí s poskytováním informací příkazového řádku (a souvisejících), protože je může nastavit zapojený proces, a proto nese žádné důvěryhodné informace. Tato metadata se zjevně používají převážně k účelům ladění; Andy navrhuje, že by je měl místo toho prostě přebírat /proc. On je také proti zasílání informací o možnostech, protože možnosti jsou v Linuxu obecně problematické a jejich používání by se neměla doporučovat.

Jedna další zajímavá část metadat, která se může připojovat ke zprávám, je čas spuštění odesílajícího procesu. Má zabránit konkurenčním podmínkám spojeným s opětovným použitím ID procesů, což se může v používaných systémech stát rychle. Andymu se tenhle přístup nelíbí, protože nebude dobře fungovat s obory názvů ani kontrolními body. On dává přednost vlastnímu řešení „highpid“. Tato oprava přidá druhé 64bitové jedinečné číslo přiřazené každému procesu; příslušné programy pak můžou zjistit opětovné použití ID procesu podle toho, zda se toto číslo změní. Eric Biederman s tímto přístupem nesouhlasil: „My nepotřebujeme nekonkurenční PID, ale API řízení procesů založené na popisovačích souborů.“ Andy nebyl proti této myšlence, ale rád by viděl něco jednoduchého, co by šlo na kdbus použít hned.

Andy měl řadu dalších komentářů, včetně upozornění na pár míst kde by se podle něj dal kdbus použít ke získání přístupu root ve všech systémech, kde by byl nainstalován. Přesto kvituje s uspokojením směr, jakým se kód ubírá: „A díky za řešení většiny problémů. Kód začíná vypadat z mého pohledu mnohem lépe.“

Směrem k hlavnímu stromu

Řešení zbývajících problémů by mělo být teoreticky relativně jednoduché, i když to není těžké odhadnout, že idea „highpid“ by mohla časem narazit na určitý odpor. Ale počet recenzentů druhé předložené verze kdbus je relativně malý, možná v důsledku svátků v USA. Přidání významného API jádra tohoto typu vyžaduje více pozornosti, než jaké se kdbusu zatím dostalo. To naznačuje, že ještě může dojít k značným problémům, na které recenzenti zatím neupozornili. Kdbus se přibližuje k začlenění do hlavního stromu, ale může trvat i několik dalších vývojových cyklů, než dospěje do bodu, kdy s ním bude spokojena většina vývojářů.

       

Komentáře

[Jardík]

Máte tam 2x psáno o kdubusu. Poprvé malý odstaveček, pak něco jiného a pak zase o kdubusu větší část, která obsahuje i to, co bylo řečeno v té první.

[rADOn]

Dnes se překlad nějak nepovedl

…nebude na počátku obsahovat žádné busy

"Bus" se překládá jako "sběrnice".

…protože možnosti jsou v Linuxu obecně problematické…

Jestli je řeč o "capabilites" tak to je vlastní jméno určitého subsystému a nepřekládá se.

A lze smazat všechny ty natvrdle doslovně překlopená zájmena na začátcích vět.

BTW s korekturou jaderných novin klidně pomůžu.

[mankind_boost]

Nechci bejt rejpal (a možná se pletu):
"My nepotřebujeme nekonkurenční PID"
Není tu chybně dvojitej zápor? Nějak nepobírám, co je tím myšleno.

[Filip Jirsák]

Nekonkurenčními PID se myslí PID, u kterých nebude problém s konkurenčním přístupem. Nebo-li i když dojde k situaci, že by mohlo dojít ke střetu dvou operací, ty operace si nekonkurují a ke střetu nedojde. Konkrétně u PID to znamená, že proces zjistí PID nějakého jiného procesu, ale než ho stihne použít, dojde k jiným operacím, které ten původní proces ukončí a vytvoří nový proces se stejným PID. S konkurenčním PID by to nebylo možné, protože proces by zjistil, že už to PID patří jinému procesu, než předtím.

[mankind_boost]

Díky.

[mankind_boost]

"Which probably means that we need a proc file we can write to and send signals to a process"
Konečně přišli na to, co v Plan9 bylo už v 80. letech.

[Petr Ježek]

Sláva! Některým nepomůže ani půlstoletí vzdálávání se nabírání zkušeností.