Jaderné noviny – 4. 4. 2013: K čemu vede více pevných odkazů na adresář

22. 4. 2013 | Luboš Doležel | Jaderné noviny | 4679×

Aktuální verze jádra: 3.9-rc5. Citáty týdne: Frederic Weisbecker, Steven Rostedt. ZFS na Linuxu 0.6.1. Post-mortem analýza deadlocku ve VFS.

Obsah

• Aktuální verze jádra: 3.9-rc5
• Citáty týdne: Frederic Weisbecker, Steven Rostedt
• ZFS na Linuxu 0.6.1
• Post-mortem analýza deadlocku ve VFS

Aktuální verze jádra: 3.9-rc5

Aktuální vývojová verze jádra je 3.9-rc5 vydaná 31. března. Linus k ní řekl: Z řady nevyčnívá nic zvláštního. Aktualizace Exynos DRM, aktualizace ovladače IBM Ram San jsou trochu větší, aktualizace l2tp... Zbytek jsou malé patche rozprostřené napříč jádrem. Většinou jde o ovladače (block, net, media, tty, usb), síťování a nějaké aktualizace systémů souborů (btrfs, nfs). Pak nějaké aktualizace architektur (x86, arc). Postupně se to uklidňuje a k vydání verze 3.9 za pár týdnů se blížíme podle plánu.

Stabilní aktualizace: verze 3.8.5, 3.4.38 a 3.0.71 vyšly 28. března s obvyklou várkou oprav. 28. března vyšla i verze 3.5.7.9. Na 4. dubna se chysta jiná velká dávka oprav v podobě 3.8.6, 3.4.39 a 3.0.72.

Citáty týdne: Frederic Weisbecker, Steven Rostedt

Bylo by pěkné vyhnout se kroku feature-removal.txt (odstranění-funkcí.txt). Když jsem kurzorem vybral tento soubor, tak jsem jednou zaslechl jakési bolestné nářky. Místo otevření tohoto souboru jsem pak okamžitě zavřel celý adresář. Nikdy předtím jsem o tom nikomu neřekl, tohle je poprvé. Také jsem se doslechl, že do tohoto souboru někdo přidal položku, že se má soubor odstranit? Tohle je nějaká černá magie.

-- Frederic Weisbecker

< systém je v jediném stavu: každý vidí kočka = naživu >

vlož_kočku_do_krabice(kočka);

< systém je ve dvojím stavu: nová volání vidí kočka == mrtvá, ale
  současná volání vidí kočka == naživu >
  
otevři_krabici();

< systém je opět v jediném stavu : všichni vidí kočka = mrtvá >

pohřeb(kočka);

-- Steven Rostedt vysvětlující RCU

ZFS na Linuxu 0.6.1

Jménem projektu ZFS-on-Linux Brian Behlendorf ohlásil dostupnost verze 0.6.1 tohoto systému souborů s původem na Solarisu. To, že je ZoL používáno skutečnými uživateli už více než dva roky, nás přesvědčilo, že je ZoL vhodné pro rozsáhlé nasazení od desktopů po superpočítače. Domovská stránka projektu nabízí binární moduly pro celou řadu distribucí. (Pro postoj tohoto projektu k licenčním problémům čtěte toto FAQ).

Post-mortem analýza deadlocku ve VFS

Dave Jones pokračuje ve zkoušení svého Trinity fuzz testeru a daří se mu v jaderném kódu odhalovat zajímavé chyby. Nedávno se mu povedlo odhalit starý bug v implementaci síťových jmenných prostorů.

Diskuze o chybě začala, když Dave na mailing list linux-kernel zaslal zprávu ukazující deadlock v kódu VFS. Toto hlášení dohnalo Ala Vira k úvahám, jak se instanci Trinity mohlo podařit viset na dvou zámcích (což je situace, která by neměla nikdy nastat), což bylo vidět na výstupu lockdep (klíčové části jsou zvýrazněné):

Showing all locks held in the system:
    4 locks on stack by trinity-child2/7669:
     #0: blocked:  (sb_writers#4){.+.+.+}, 
         instance: ffff8801292d17d8, at: [<ffffffff811df134>] mnt_want_write+0x24/0x50
     #1: held:     (&type->s_vfs_rename_key){+.+.+.}, 
         instance: ffff8801292d1928, at: [<ffffffff811c6f5e>] lock_rename+0x3e/0x120
     #2: held:     (&type->i_mutex_dir_key#2/1){+.+.+.}, 
         instance: ffff880110b3a858, at: [<ffffffff811c701e>] lock_rename+0xfe/0x120
     #3: blocked:  (&type->i_mutex_dir_key#2/2){+.+.+.}, 
         instance: ffff880110b3a858, at: [<ffffffff811c7034>] lock_rename+0x114/0x120

Al také poznamenal, že výstup ukazuje, že inode adresáře byl v inode cache mapován pomocí dvou různých dentries, protože lockdep ukázal dva zámky i_mutex_dir_key na stejné adrese. Dentry (directory entry; položka adresáře) je datová struktura představující název souboru v jaderné cachi adresářových položek (dcache); krátký přehled o dentries a dcache lze najít v tomto článku. Jak bude všem brzy jasné, nikdy by se nemělo přihodit, že je inode adresáře mapována v dcache dvakrát.

Některé návrhy se týkaly přidání vhodných ladících výstupů do jaderné funkce lock_rename(), aby bylo možné problém dále analyzovat. Hlavně kvůli držení dvou zámků nad stejnou adresou inodu chtěl Linus vidět názvy souborů tohoto inode a Ala zajímal název systému souborů, kde se tyto inody nacházejí.

Další spuštění Trinity s dodatečným ladícím výstupem odhalilo, že se tyto zámky objevují u různých položek ve stromu /proc. V ten moment Linus upřesnil, že se dotyčné položky nacházejí jen v /proc/net, ale stejně jako Al byl zmatený z toho, jak se něco takového může dít.

Zde se sluší vysvětlit některé okolnosti. Bylo nebylo, /proc/net existovalo jen jako jediný adresář. Jenže s vynálezem síťových jmenných prostorů jde nyní o symbolický odkaz do adresáře /proc/self/net; jinými slovy, každý proces teď má svůj vlastní pohled na síťové informace pod /proc specifický pro síťový jmenný prostor.

S ladícím výstupem se rychle podařilo pochopit souvislosti. Dave si uvědomil, že začal selhání Trinity vídat po povolení síťových jmenných prostorů po nedávné opravě chyby od Erica Biedermana. Al se blíže podíval na některé podadresáře v adresáři /proc/PID/net a odhalil neveselou skutečnost:

al <at> duke:~/linux/trees/vfs$ ls -lid /proc/{1,2}/net/stat
4026531842 dr-xr-xr-x 2 root root 0 Mar 21 19:33 /proc/1/net/stat
4026531842 dr-xr-xr-x 2 root root 0 Mar 21 19:33 /proc/2/net/stat

Toto odhalení vedlo k malému výbuchu:

NĚMŮŽEME MÍT NĚKOLIK DENTRIES NA STEJNÉM INODE ADRESÁŘE. [...] Ach jo... Jmenné prostory – mělo se zůstat jen u jediného...

Ti z vás, kteří máte dobrou paměť, nebo jste u nedávného článku na LWN dávali pozor, se možná usmíváte kvůli tomu, že od počátku a mnoho let poté byl jen jediný typ jmenných prostorů – jmenné prostory připojovacích bodů, které implementoval nějaký Al Viro.

Srandičky stranou, byl to právě Al, kdo odhalil podstatu problému. Výpis adresáře, který můžete vidět výše, ukazuje dvě adresářové položky vedoucí k jedinému inode. Obecně řečeno všechny procesy sdílející jediný síťový jmenný prostor mají své /proc/PID/net implementováno jako pevný odkaz na stejný (virtuální) soubor v /proc.

Implementace příslušných položek v /proc jako pevné odkazy na stejný inode je při implementaci jmenných prostorů technika používaná na různých místech. Povolování více pevných odkazů na jediný soubor je samozřejmě běžná funkce unixových systémů. Až na jeden případ: Linux, stejně jako ostatní unixové systémy, zakazuje vícero pevných odkazů na adresář. Spolehlivost různého kódu v jádře i mimo něj stojí na tomto předpokladu. Patch v Linuxu 2.6.25 začleněný v počátcích implementace síťových jmenných prostorů tento předpoklad pro adresáře pod /proc/PID/net potají rozbil.

Jakmile se podařilo najít příčinu problému, museli vývojáři vymyslet vhodnou opravu. V tento moment se muselo k věci přistupovat pragmaticky, protože cílem bylo opravit nejen budoucí jádra, ale i ta minulá. Jinými slovy by idelání opravou byl patch, který by šel aplikovat nejen na současná jádra, ale i na starší stabilní řady. To vedlo Linuse ke spekulacím, zda nepovolit výjimku v jinak přísném pravidlu, že na adresáře nemůže být více pevných odkazů. Protože jsou tyto zámky umisťovány na úrovni inode, proč nezměnit kontrolu v lock_rename() tak, aby se ověřovalo, zda se nepracuje se stejnými inody místo dentries?

Al ale rychle upozornil, že takto by se sice odstranil tento konkrétní deadlock, ale ostatní problémy by zůstaly nedotčeny. Jaderný kód pracující s těmito zámky závisí na topologickém řazení na bázi hierarchických vztahů mezi položkami v dcache; přítomnost více adresářových položek odkazujících na stejný inode činí toto řazení nespolehlivým.

Al pak popsal, co by považoval za úplné a řádné řešení: vytvoření souborů /proc/PID/net jako symbolické odkazy na adresáře konkrétních jmenných prostorů v podobě /proc/nents-ID/net, kde netns-ID je identifikátorem daného jmenného prostoru. Alternativou by bylo zachovat stávající stromy /proc/PID/net, akorát by podadresáře byly vytvořeny jako duplicitní podstromy místo odkazování na jediný adresářový podstrom. Al si ale nebyl jistý, zda by toto šlo implementovat jako backportovatelný patch.

Mezitím přišel Linus s jiným návrhem. proc_get_inode(), jaderná funkce pro alokaci inodů v systému souborů /proc, má tuto podobu:

    struct inode *proc_get_inode(struct super_block *sb, struct proc_dir_entry *de)
    {
        struct inode *inode = iget_locked(sb, de->low_ino);

        if (inode && (inode->i_state & I_NEW)) {

            ...
            /* Populate fields in newly allocated cache entry pointed
               to by 'inode' */
               ...

            unlock_new_inode(inode);
        } else
            pde_put(de);
        return inode;
    }

Funkce iget_locked() prohledává jadernou inode cache, aby našla inode, jehož číslo odpovídá číslu ve struktuře dentry de. Vrátí buď ukazatel na existující položku, nebo novou neinicializovanou položku v cache v případě, že tam ještě taková není. Funkce proc_get_inode() pak naplní pole nově vytvořené položky v inode cache pomocí údajů z dentry.

Problém s deadlockem je důsledkem toho, že kvůli mapování více dentries na jediný inode může být vícero zámků umístěno k té samé položce v inode cache. Deadlockům by se mohlo zabránit tím, že by se zabraňovalo umisťování více zámků na položky inode vracené z cache. Jak Linus poznamenal, v případě /proc není skutečně nutné hledat existující položku v cache, neboť soubory v /proc neexistují na žádném fyzickém disku. Místo toho by proc_get_inode() mohlo vždy vytvořit novou položku cache pomocí new_inode_pseudo() a naplnit ji. Protože by vždy docházelo k vytváření nové položky, nebyla by viditelná jiným procesům a nemohlo by tedy docházet ke konfliktům zámků nebo k deadlockům. Jinými slovy by logika v proc_get_inode() mohla být upravena takto:

    struct inode *proc_get_inode(struct super_block *sb, struct proc_dir_entry *de)
    {
        struct inode *inode = new_inode_pseudo(sb);

        if (inode) {
            inode->i_ino = de->low_ino;

            ...
            /* Populate fields in newly allocated cache entry pointed
               to by 'inode' */
            ...

        } else
           pde_put(de);
        return inode;
    }

Zde je vhodné upozornit na existenci dvou různých schémat alokace pro inody pod /proc: první schéma se obvykle používá pro inody pod adresáři /proc/PID a to druhé ve zbytku /proc. Linusův patch ovlivňuje jen alokace inodů pro položky ve druhé skupině. Z historických důvodů, kdy /proc/net bylo přesunuto do /proc/PID/net, jsou inody pod /proc/PID/net alokovány stejně jako inody mimo /proc/PID a tento patch proto má dopad i na ně.

V komentáři u následného commitu Linus řekl, že by patch mohl být poladěn tak, aby se nové chování týkalo jen položek adresářů a ne tedy všeho v /proc. V zájmu zachování jednoduchosti to tak ale uděláno nebylo.

Důsledkem Linusova patche je zabránění vzniku více zámků (a tedy deadlocků) na stejném inodu. Al souhlasil, že tato změna by z hlediska správnosti neměla představovat problém. Na druhou stranu má tato změna za důsledek odstranění předností cachování inodů v /proc mimo /proc/PID. Al se zabýval výkonnostními dopady této změny. Nahodilé testování ukázalo. že přednosti cachování inodů v /proc jsou tak jako tak velmi malé. Dave navíc oznámil, že po aplikaci opravy už běh Trinity deadlockem nekončil.

       

Komentáře

[Aleš Kapica]

To s tou kočkou mě fakt dostalo. 8-D

[Bedňa]

Je to dobré, ale už som to niekde čítal, by som si tipol že to je od nejakého fylozofa.

A súbor čo má v sebe napísané, že ho treba zmazať je tiež moc dobré :)

[Bedňa]

Na jaaaa, už to mám, Schrödingerova kočka.

[vencour]

Cože? Ty neznáš BBT (Velký třesk)? Když už nic jiného? Aneb "kočka žije, jde se jíst"

[Bedňa]

Poznám, tam práve vyriešili teóriu Schrödingerovej kočky

[li737]

Moc pekny clanek. Ta kocka me take velice pobavila. mimochodem hodi se k zitrejsimu vydani alfy fedori kocky

[Petr Ježek]

Kočka je fajn a pobaví. Horší je to s naprosto nekritickou pasáží o ZFS v linuxu. Jakoby s tím nikdo nedělal a netrápil se těžce podprůměrnou rychlostí, dokonce nižší než u btrfs. Přitom čím více dat, tím je požadavek rychlosti jejich zpracování urgentnější.

[little.owl]

No moment. A kdo tu kocku zabil? Byla to opravdu jen krabice? Tyrani zvirat!