Jaderné noviny – 10. 12. 2014: Otevření začleňovacího okna verze 3.19

18. 1. 2015 | Tadeáš Pelech | Jaderné noviny | 3729×

Stav vydání jádra. Citát týdne. Otevírá se začleňovací okno verze 3.19. Připojení programů eBPF k soketům. Rozhraní iov_iter.

Obsah

• Stav vydání jádra
• Citát týdne
• Otevírá se začleňovací okno verze 3.19
• Připojení programů eBPF k soketům
• Rozhraní iov_iter

Stav vydání jádra

Je otevřené začleňovací okno 3.19, takže není žádné aktuální vývojové jádro. Do hlavního stromu začaly proudit opravy pro vývojový cyklus 3.19; podrobnosti viz samostatný článek níže.

Verze jádra 3.18 byla vydána dne 7. prosince (oznámení).

Stabilní aktualizace: Stabilní verze jádra 3.17.5 byla vydána 7. prosince s následujícím komentářem: „Nikdo by ji neměl používat“; místo ní by se měla použít verze 3.17.6 vydaná bezprostředně po ní, která obsahuje důležité odvolání oprav. K dispozici jsou také verze 3.14.26 a 3.10.62.

Citát týdne

Microsoft poskytne integrovaný ovladač a dodavatelé mají možnost ho použít nebo si certifikovat vlastní pomocí WHQL, což je trochu jako volba mezi zmrzlinou zdarma a bušením hlavou do prkna plného hřebíků.

– Alan Cox (díky Vishalu Vermovi).

Otevírá se začleňovací okno verze 3.19

V době vzniku tohoto článku se začalo poněkud pomalu rozjíždět začleňovací okno vývojového cyklu verze 3.19; prozatím bylo do hlavního repozitáře přijato necelých 2 000 sad změn bez začlenění. Jak je patrné z níže uvedených seznamů, i to stačí na to, aby si do jádra našlo cestu několik nových zajímavých zdrojových kódů.

Mezi změny ve verzi 3.19 viditelné uživatelem patří:

• Do jádra byla přidána podpora technologie Intel MPX. Procesory s podporou MPX (které lze stále sehnat jen velmi obtížně) mohou provádět kontrolu hranic na odkazech do paměti v naději, že zachytí spoustu chyb a zablokují zneužití zranitelností při přetečení vyrovnávací paměti. Použití této funkce však vyžaduje poskytnutí procesoru spousty informací o přijatelných mezích pro každý odkaz do paměti, takže se dá čekat, že její plné přijetí nějakou dobu potrvá.
• Došlo k výraznému zlepšení výkonu cíle mapovače zařízení „thin provisioning“, hlavně v souvislosti s agregací vstupně-výstupních operací na stejném bloku před jejich použitím na podkladové zařízení.
• Jádro nyní obsahuje podporu pro procesor Altera „Nios II“.
• Architektura Arm64 získala podporu pro subsystém zabezpečených výpočtů („seccomp“).
• Podpora nového hardwaru zahrnuje:
  • Systémy a procesory: Strukturované systémy na čipu (SoC) Broadcom IPROC, Amlogic Meson8 SoC, Allwinner A80 SoC, Samsung Exynos4415 SoC, Freescale LS1021A SoC, Alphascale ASM9260 SoC a AMD Seattle SoC. Prostřednictvím přírůstků ve stromu zařízení jsou navíc podporovány desítky nových systémů.
  • Bloková zařízení: Adaptéry Tekram DC390(T) a Am53/79C 974 SCSI a adaptéry Western Digital WD7193/7197/7296 SCSI.
  • Různé: Rozhraní karet SD/MMC Toshiba typ A, A-D převodníky X-Powers AXP288, master adaptéry Diolan DLN2 USB-I2C/SPI/GPIO, špičkové řadiče LCD Atmel, hardwarové sledovací čipy Nuvoton NCT7802Y, regulátory Richtek RT5033 a jednotky správy systémové paměti NVIDIA Tegra.

Mezi změny viditelné pro vývojáře jádra patří:

• Subarchitektura Atmel AT91 byla zcela převedena na mechanismus stromu zařízení. Na oslavu vývojáři odstranili všechny soubory starých desek pro tuto řadu, a tím snížili velikost jádra o 24 000 řádků kódu.
• Práce na problému roku 2038 pokračují. Vnitřní funkce do_settimeofday(), timekeeping_inject_sleeptime() a mktime() jsou nahrazeny verzemi fungujícími i po roce 2038. Nová verze každopádně přidává k názvu funkce „64“ a přepne na typ time64_t nebo timespec64 pro reprezentaci času. Nyní může začít proces zařazení starých verzí mezi zastaralé a konverze zdrojového kódu.
• Podpora domény hierarchických přerušení byla sloučena do jádra řešení přerušení. Tato podpora je nutní k řádné reprezentaci komplexního hardwaru, který má připojeno více řadičů přerušení složitým způsobem. Další informace najdete v nové části přidané do souboru Documentation/IRQ-domain.txt.

Pokud bude zachován obvyklý postup, začleňovací okno zůstane otevřené do 21. prosince, kdy bude uvolněna první prepatch verze 3.19. LWN bude – jako obvykle – sledovat změny začleněné během tohoto okna v dalších článcích.

Připojení programů eBPF k soketům

V předchozích vývojových cyklech jádra jsme byli svědky přidání subsystému rozšířeného filtru paketů Berkeley (eBPF) do jádra. Od verze 3.18 však může program uživatelského prostoru načíst program eBPF, ale nedokáže ho spustit v žádném užitečném kontextu; programy lze načíst a ověřit, ale nic víc. Vývojář eBPF Alexej Starovojtov samozřejmě předpokládá, že tento subsystém bude hrát významnější roli. Jádro 3.19 by mělo zahrnovat novou sadu oprav, která poprvé předvede schopnosti, které má Alexej na mysli.

Hlavní funkcí, která má být přidána ve verzi 3.19, je možnost připojit programy eBPF k soketům. Operace probíhají tak, že se nejprve nastaví program eBPF v paměti, pak se pomocí nového systémového volání bpf() (od verze 3.18) nahraje program do jádra a získá se popisovač souboru, který na něj odkazuje. Program lze potom připojit k soketu pomocí nové možnosti SO_ATTACH_BPF setsockopt():

    setsockopt(socket, SOL_SOCKET, SO_ATTACH_BPF, &fd, sizeof(fd));

Kde socket představuje příslušný soket a fd obsahuje popisovač souboru pro načtení programu eBPF.

Program se po načtení spustí na každý paket, který se objeví na daném soketu. V současnosti jsou dostupné funkce stále omezeny v několika směrech:

• Programy eBPF mají přístup k datům uloženým v paketu samotném, nikoli k žádným dalším informacím uloženým v datové struktuře jádra skb. Do budoucna se počítá se zpřístupněním části těchto metadat, ale ještě není jasné, která data budou dostupná a jak.
• Programy nemohou žádným způsobem ovlivnit doručení ani obsah paketu. I když se tyto programy označují jako „filtry“, v současnosti mohou pouze ukládat informace do „map“ eBPF, které může využívat uživatelský prostor.

Konečným důsledkem je, že programy eBPF budou ve verzi 3.19 použitelné v podstatě jen pro sběr statistických údajů.

Každopádně to je dobrý začátek. Jádro 3.19 by mělo v adresáři samples obsahovat několik příkladů s ukázkami použití této funkce. Dva z nich jsou verze jednoduchého programu, který z každého paketu získává nízkoúrovňové protokoly (UDP, TCP, ICMP,...) a udržuje v mapě eBPF počitadlo pro každý protokol. Pokud chce někdo takový program napsat přímo v jazyce virtuálních strojů eBPF, dopadne to nějak takto:

    struct bpf_insn prog[] = {
	BPF_MOV64_REG(BPF_REG_6, BPF_REG_1),
	BPF_LD_ABS(BPF_B, 14 + 9 /* R0 = ip->proto */),
	BPF_STX_MEM(BPF_W, BPF_REG_10, BPF_REG_0, -4), /* *(u32 *)(fp - 4) = r0 */
	BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
	BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -4), /* r2 = fp - 4 */
	BPF_LD_MAP_FD(BPF_REG_1, map_fd),
	BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem),
	BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 2),
	BPF_MOV64_IMM(BPF_REG_1, 1), /* r1 = 1 */
	BPF_RAW_INSN(BPF_STX | BPF_XADD | BPF_DW, BPF_REG_0, BPF_REG_1, 0, 0),
	BPF_MOV64_IMM(BPF_REG_0, 0), /* r0 = 0 */
	BPF_EXIT_INSN(),
    };

Je celkem zřejmé, že takové programy nepředstavují pro většinu z nás právě poučné čtení. Ale jak je uvedeno v tomto příkladu, program lze také napsat v omezující verzi jazyka C:

    int bpf_prog1(struct sk_buff *skb)
    {
	int index = load_byte(skb, 14 + 9);
	long *value;

	value = bpf_map_lookup_elem(&my_map, &index);
	if (value)
	    __sync_fetch_and_add(value, 1);

	return 0;
    }

Tento program lze předložit speciální verzi překladače LLVM, která vytvoří soubor objektu pro virtuální stroj eBPF. Prozatím je nutno použít Alexejovu verzi LLVM, Alexej však pracuje na začlenění těchto změn do hlavního stromu LLVM. Nástroj uživatelského prostoru může načíst program ze souboru objektu a nahrát ho do jádra obvyklým způsobem; není třeba používat přímo jazyk eBPF.

Výhoda možnosti práce s jazykem vyšší úrovně je zřejmá při pohledu na poslední příklad, který se přeloží do 300 instrukcí programu eBPF. Ten provádí sledování toku, počítá pakety podle adres IP. Program samotný má možná omezené použití, ale ukazuje, že některé poměrně složité věci lze provést s virtuálním strojem eBPF v jádře.

Do budoucna se počítá s použitím eBPF na řadě jiných míst včetně subsystému zabezpečených výpočtů („seccomp“) a pro filtrování nálezů trasovacích zarážek. Vzhledem k tomu, že se eBPF v jádru stává univerzálním prostředkem, dá se očekávat, že vývojáři přijdou na další místa, kde by se dal použít. Počítejte s tím, že se v následujících letech objeví další zajímavé možnosti využití eBPF.

Rozhraní iov_iter

Jedním z nejčastějších úkolů v jádře je zpracování vyrovnávací paměti dat poskytnutých uživatelským prostorem i v několika blocích. Asi nikoho nepřekvapí, že takový kód jádra často bývá nesprávný, což vede k chybám a případně i k bezpečnostním problémům. Jádro obsahuje základní operaci (jménem „iov_iter“), která by měla tento úkol zjednodušit. I když se iov_iter v současnosti používá většinou jen při správě paměti a vrstev souborových systémů, pomalu se šíří do dalších částí jádra. Toto rozhraní není zatím zdokumentované, tento článek se pokusí situaci napravit.

Koncept iov_iter není nový, poprvé ho přidal Nick Piggin pro verzi jádra 2.6.24 v roce 2007. V loňském roce ale probíhaly pokusy o rozšíření toto API a o jeho použití ve více částech jádra; v začleňovacím okně 3.19 by se například měly objevit první případy využití v síťovém subsystému.

Struktura iov_iter je v podstatě iterátor pro práci prostřednictvím struktury iovec definované v <uapi/linux/uio.h>:

    struct iovec
    {
	void __user *iov_base;
	__kernel_size_t iov_len;
    };

Tato struktura odpovídá struktuře uživatelského prostoru iovec definované v POSIX, kterou používají systémová volání jako readv(). Jak napovídá přípona „vec“, struktury iovec se obvykle používají v polích; iovec celkově popisuje vyrovnávací paměť, která může být rozptýlena ve fyzické i virtuální paměti.

Struktura iov_iter samotná je definována v <linux/uio.h>:

    struct iov_iter {
	int type;
	size_t iov_offset;
	size_t count;
	const struct iovec *iov; /* ZJEDNODUŠENO – viz níže */
	unsigned long nr_segs;
    };

Pole type popisuje typ iterátor. Je to bitová maska obsahující, mimo jiné, READ nebo WRITE podle toho, zda se data do iterátoru načítají nebo z něj zapisují. Směr dat tedy neodkazuje přímo na iterátor, ale na druhou část transakce dat; do iov_iter s typem READ se bude zapisovat.

Kromě toho iov_offset obsahuje pozici prvního bajtu zajímavých dat v prvním iovec, na který odkazuje iov. Celkové množství dat, na které odkazuje pole iovec, je uloženo v count a počet struktur iovec je uložen v nr_segs. Většina z těchto polí se změní, když kód „projde“ vyrovnávací paměti. Popisují kurzor do vyrovnávací paměti, nikoli celou vyrovnávací paměť.

Práce se strukturou iov_iter

Před použitím musí být iov_iter inicializována, aby obsahovala (již naplněnou) iovec:

    void iov_iter_init(struct iov_iter *i, int direction,
		       const struct iovec *iov, unsigned long nr_segs,
		       size_t count);

Potom lze například přesouvat data mezi iterátorem a uživatelským prostorem pomocí funkcí:

    size_t copy_to_iter(void *addr, size_t bytes, struct iov_iter *i);
    size_t copy_from_iter(void *addr, size_t bytes, struct iov_iter *i);

Názvy jsou možná trochu matoucí, dokud jim přijdete na kloub. Volání copy_to_iter() zkopíruje data bytes z vyrovnávací paměti na adrese addr do vyrovnávací paměti uživatelského prostoru zadané iterátorem. copy_to_iter() lze tedy považovat za obdobu copy_to_user(), která místo jedné vyrovnávací paměti používá iterátor. Podobně copy_from_iter() zkopírujete data z vyrovnávací paměti uživatelského prostoru do addr. Podobnost s copy_to_user() pokračuje i vrácenou hodnotou, která představuje počet nezkopírovaných bajtů.

Tato volání budou „posouvat“ iterátor vyrovnávací pamětí s ohledem na objem přenesených dat. Jinými slovy, pole iov_offset, count, nr_segs a iov iterátoru se všechna změní podle potřeby. Dvě volání copy_from_iter() tedy zkopírují dvě po sobě jdoucí oblasti z uživatelského prostoru. Mimo jiné to znamená, že kód vlastnící iterátor si musí pamatovat základní adresu pole iovec, protože hodnota iov ve struktuře iov_iter se může změnit.

K dispozici jsou i další funkce. Pro přesun dat odkazovaných pomocí struktury page do iterátoru nebo z něj použijte:

    size_t copy_page_to_iter(struct page *page, size_t offset, size_t bytes,
			     struct iov_iter *i);
    size_t copy_page_from_iter(struct page *page, size_t offset, size_t bytes,
			       struct iov_iter *i);

Zkopírována bude pouze jedna zadaná page, tyto funkce tedy nelze používat ke kopírování dat, která by překročila hranice stránky.

Kód spuštěný v atomickém kontextu se může pokusit získat data z uživatelského prostoru pomocí:

    size_t iov_iter_copy_from_user_atomic(struct page *page, struct iov_iter *i,
					  unsigned long offset, size_t bytes);

Protože tato kopie bude probíhat v atomickém režimu, uspěje pouze v případě, že data jsou již uložena v paměti RAM; volající proto musí být připraven na nadprůměrnou pravděpodobnost neúspěchu.

Pokud je to nezbytné k mapování vyrovnávací paměti uživatelského prostoru do jádra, lze použít jedno z těchto volání:

    ssize_t iov_iter_get_pages(struct iov_iter *i, struct page **pages,
                               size_t maxsize, unsigned maxpages, size_t *start);
    ssize_t iov_iter_get_pages_alloc(struct iov_iter *i, struct page ***pages,
    	    			     size_t maxsize, size_t *start);

Každá z těchto funkcí se změní na volání get_user_pages_fast(), které (doufejme) způsobí načtení stránek a uložení jejich umístění do pole pages. Rozdíl mezi nimi je, že iov_iter_get_pages() očekává, že pole pages alokuje volající, zatímco funkce iov_iter_get_pages_alloc() provede alokaci sama. Potom pole vrácené v pages musí být nakonec uvolněno pomocí volání kvfree(), protože mohlo být přiděleno pomocí kmalloc() nebo vmalloc().

Průchod iterátorem bez přesouvání dat lze provést pomocí:

    void iov_iter_advance(struct iov_iter *i, size_t size);

Vyrovnávací paměť, na kterou odkazuje iterátor (nebo jeho část), lze vyčistit pomocí:

    size_t iov_iter_zero(size_t bytes, struct iov_iter *i);

Informace o iterátoru je k dispozici od řady pomocných funkcí:

    size_t iov_iter_single_seg_count(const struct iov_iter *i);
    int iov_iter_npages(const struct iov_iter *i, int maxpages);
    size_t iov_length(const struct iovec *iov, unsigned long nr_segs);

Volání iov_iter_single_seg_count() vrátí délku dat v prvním segmentu vyrovnávací paměti. iov_iter_npages() hlásí počet stránek obsazených vyrovnávací pamětí v iterátoru a iov_length() vrátí celkovou délku dat. Poslední funkci je nutno používat opatrně, protože důvěřuje poli len ve strukturách iovec. Pokud tato data pochází z uživatelského prostoru, mohou v jádře způsobit celočíselné přetečení.

Nejen iovecs

Definice struct iov_iter uvedené výše se zcela neshodují se skutečnou situací v jádře. Namísto jediného políčka pro pole iov obsahuje skutečná struktura (ve verzi 3.18):

    union {
	const struct iovec *iov;
	const struct bio_vec *bvec;
    };

Struktura iov_iter je tedy také nastavena pro práci se strukturami BIO, které používá bloková vrstva. Takové iterátory jsou označeny zahrnutím ITER_BVEC do bitové masky pole type. Když je takový iterátor vytvořen, všechna výše uvedená volání s ním budou pracovat, jako by to byl „obyčejný“ iterátor, který používá struktury iovec. Prozatím je použití iterátorů využívajících BIO v jádře minimální; nacházejí se jen v kódu odkládací paměti a splice().

Novinky ve verzi 3.19

Jádro 3.19 pravděpodobně zaznamená značnou míru změn v kódu iov_iter, které by měly redukovat značný objem standardizovaného kódu potřebného k zavedení všech výše uvedených funkcí. Kód je skutečně kratší, ale za cenu zavedení poměrně velkého zapojení lehce děsivé magie maker preprocesoru, která pomáhá vygenerovat potřebný standardní kód na požádání.

Kód iov_iter již funguje, pokud je vyrovnávací paměť „user-space“ umístěna v prostoru jádra. Ve verzi 3.19 bude všechno trochu formalizováno a optimalizováno. Iterátor se potom bude vytvářet takto:

    void iov_iter_kvec(struct iov_iter *i, int direction,
		       const struct kvec *iov, unsigned long nr_segs,
		       size_t count);

Pro tento případ také do unionu přibude nové pole kvec uvedené výše.

Byly také konečně přidány některé funkce, které pomáhají se síťováním; v rámci procesu například bude možné zkopírovat vyrovnávací paměť a generovat kontrolní součet.

Znamená to tedy, že rozhraní iov_iter se pomalu stává standardním způsobem, jak skrýt mnoho složitostí spojených s manipulací s vyrovnávací pamětí uživatelského prostoru. Do budoucna můžeme očekávat, že bude doporučováno na více místech. Zabralo zhruba jen sedm let, ale zdá se, že iov_iter se blíží do stavu, kdy se stane rozhraním, o kterém bude chtít většina vývojářů jádra vědět.

       

Komentáře

[linuxtardis]

Jsem zvědav, jak to bude s verzí po 3.19, jestli bude ta extra stabilní verze 4.0.

[Aleš Kapica]

Proč? Co se ti nelíbí na 3.20?

[David Watzke]

Linus něco takovýho před ~rokem naznačil.

[Max]

Jako, vývoj je dobrý, ale myslím si, že se jádro dostává do stadia, kdy by měl jednou za čas takový release vyjít.
Zdar Max

[R]

Nestaci ti jadro 3.2, momentalne 3.2.66?

[Jendа]

Nebo obecně nějaké distribuční. LTS je víc, z Debianu a Ubuntu třeba 2.6.32, 3.2 a teď bude 3.16. Nebo CentOS 7 má tuším 3.10.

[trekker.dk]

a teď bude 3.16

... na kterém mi přestal fungovat software suspend kvůli ovladači radeon. Poslední fungující (z těch, co jsem zkoušel) je pro mě 3.2, takže kdybych to měl řešit, tak je to bisect přes 14 verzí, přičemž přinejmenším jedna z nich mi panikařila už při bootu.

[R]

Bisekcia ma priblizne rovnaky pocet krokov, ci ho robis to medzi 2 alebo 14 verziami. Ak vies rychlo kompilovat, tak to mas za hodinku-dve hotove. Pouzivam na kompilaciu 8-jadrovy server a predtym si minimalizujem config. Horsie je, ked nevies bug spolahlivo a rychlo reprodukovat.

[trekker.dk]

Což reprodukovat to jde snadno, stačí se pokusit uspat na disk. Problém je v tom - už jsem to psal - že mezi verzemi 3.2 a 3.16 mi některá verze (3.10, iirc) panikařila už při bootu. S největší pravděpodobností kvůli jiné chybě taky v ovladači pro grafiku.

[R]

To v principe nie je problem, staci preskocit nefunkcnu verziu (git bisect skip), akurat to predlzi bisekciu.

[pc2005]

Možná by šlo navíc ten bisect urychlit omezením na powermanagement subsystém.

[R]

Toto by som skor obmedzil na radeon. Ale pokym nemas uplnu istotu, je lepsie to nerobit. Lahko sa moze stat, ze budes robit este druhu bisekciu, tentokrat bez obmedzenia :D

[Max]

Ne :).
Zdar Max

[Petr Ježek]

Díky za perfektní popis iov_iteru. Ten dává rozhodně smysl a vypadá to na velmi kvalitně pojaté řešení.