Jaderné noviny – 20. 12. 2012: Umlčování GCC ne vždy přínosné

14. 1. 2013 | Luboš Doležel

Články - Jaderné noviny – 20. 12. 2012: Umlčování GCC ne vždy přínosné  

Aktuální verze jádra. Citáty týdne: Android Authority, Linus Torvalds. Začleňovací okno verze 3.8, část druhá. Odstranění uninitialized_var().

Obsah

• Aktuální verze jádra
• Citáty týdne: Android Authority, Linus Torvalds
• Začleňovací okno verze 3.8, část druhá
• Odstranění uninitialized_var()

Aktuální verze jádra

Začleňovací okno verze 3.8 je stále otevřené a patche nadále proudí do hlavní řady. Přehled významných změn v 3.8 najdete níže.

Stabilní aktualizace: verze 3.0.57, 3.4.24, 3.6.11 a 3.7.1 vyšly 17. prosince. Pozor na to, že 3.6.11 je poslední aktualizací v řadě 3.6.

Citáty týdne: Android Authority, Linus Torvalds

Ti, kdo vyvíjejí jádra pro zařízení s Androidem vědí, jak frustrující vždy bylo portovat jádro na nové zařízení. Pokud jste téhož názoru a byli byste rádi, kdyby se tento proces zjednodušil, tak vás jistě potěší, že Linus Torvalds ohlásil podporu ARM v Linuxu.

-- Android Authority při jedné ze svých slabších chvilek

Takže počty jsou zmatené, typy jsou zmatené a jména jsou zmatená. Někdo se na to prosím podívejte, protože teď jsem i *já* zmatený.

-- Linus Torvalds

Začleňovací okno verze 3.8, část druhá

Linus neměl v uplynulém týdnu čas na lelkování, od přehledu z minulého týdne bylo do hlavní řady přetaženo nějakých 6200 sad změn. To celkem dělá více než 10 000 změn, což dělá z 3.8 jedno z nejživějších začleňovacích oken a vůbec první, kdy byl překročen počet 10 000. A to ještě nejsme na konci.

Do jádra se dostalo několik významných změn. Mimo jiné bylo rozhodnuto, jak bude pokračovat vývoj lepšího vyvažování NUMA. A teď už bez dalšího zdržování přehled nejvýznamnějších změn viditelných uživatelům jádra od minulého týdne:

• Neshody kvůli tomu, jak by se měly vyřešit výkonnostní problémy NUMA, byly částečně vyřešeny tím, že Ingo Molnar souhlasil se začleněním patche „balancenuma“ od Mela Gormana, který bude sloužit jako základ pro další vývoj. Balancenuma vytváří základní infrastrukturu, jež umožní budoucí experimentování s pravidly pro umisťování a vyvažování; samo o sobě moc pravidel nepřidává. Tento základní kód byl začleněn do verze 3.8; pravidla jako taková se dostanou až do 3.9.
• Byla začleněna funkce velké nulové stránky, což v některých případech značně sníží využití paměti.
• Byla začleněna infrastruktura pro počítání využití jaderné paměti, což umožní určování omezení využití jaderné paměti dle řídících skupin. Více o použití této funkce najdete v dokumentaci.
• Patch pro inline data byl začleněn do systému souborů ext4. Ext4 nyní dokáže ukládat data drobných souborů přímo v inode, což zvyšuje výkon a efektivitu využití místa na disku. Ext4 nyní také podporuje operace SEEK_HOLE a SEEK_DATA ve volání lseek().
• Btrfs má novou operaci „replace“ (nahraď) umožňující efektivní nahrazení jedné jednotky ve svazku.
• Systém souborů tmpfs nyní podporuje operace SEEK_HOLE a SEEK_DATA ve volání lseek().
• Byl přetažen patch podpory uživatelských jmenných prostorů. Eric Biederman k němu říká: Tato sada změn přidává podporu toho, aby si obyčejní uživatelé mohli vytvářet uživatelské jmenné prostory a jako root takového prostoru vytvářeli další jmenné prostory.
• Nové systémové volání:

  int finit_module(int fd, const char *args, int flags);

  lze použít k načtení jaderného modulu z daného popisovače. Toto volání bylo přidáno vývojáři ChromeOS, aby mohli přijímat nebo odmítat modul na základě toho, kde je uložený na systému souborů.
• Síťový subsystém batman-adv získal podporu distribuované tabulky ARP.
• Ovladače tun/tap a virtio podporují vícero front u jednoho zařízení.
• Plánovač paketů QFQ byl upgradován na QFQ+, který je prý rychlejší a schopnější; více v tomto PDF.
• Architektura s390 má podporu pro připojené řadiče PCI.
• Proměnné UEFI jsou nyní přístupné přes nový virtuální systém souborů efivars.
• Systémové volání ptrace() má novou volbu PTRACE_O_EXITKILL, které zajistí, že všechny sledované procesy obdrží signál SIGKILL, když sledující proces neočekávaně skončí.
• Podpora nového hardwaru.

Počet interních změn je ale relativně malý. Mezi změny viditelné vývojářům jádra patří:

• Vrstva Video4Linux2 nyní podporuje použití sdílených bufferů DMA pro I/O snímků. Více se o této funkci dozvíte z dokumentace v DocBooku. Subsystém videobuf2 pak dále podporuje použití roztroušených seznamů (scatterlist) s buffery z uživatelského prostoru v „souvislém“ režimu DMA.
• Subsystém pro vstup podporuje použití „řízených“ zařízení přes novou funkci devm_input_allocate_device().

Jednou z funkcí, které začleněny nebyly, je podpora RAID5/6 v Btrfs. Tyto patche se aktuálně připravují pro hlavní řadu a můžeme je očekávat v cyklu verze 3.9.

Odstranění uninitialized_var()

Varování kompilátoru mohou být pro jaderné vývojáře spasitelem; dobré varování může pomoci předejít chybě, kterou by vývojář těžko dohledával. Vývojáře ale rychle otráví varování, která se objevují v kódu, jenž je správně. Netrvá moc dlouho, než vývojář vypne varování úplně. Proto se vývojáři mnohdy snaží potlačovat varování u kódu, který je správně – což je postup mající jiné nechtěné důsledky.

GCC při použití vhodných voleb vypíše varování, pokud je přesvědčeno, že některá proměnná může být použita před nastavením její hodnoty. Toto varování je založeno na analýze kompilátoru, který zkoumá možné průchody kódem; pokud najde cestu, kde není proměnná inicializována, uvidíte varování na „neinicializovanou proměnnou“. Problém je v tom, že kompilátor je ne vždy dostatečně chytrý při provádění svých analýz. Pěknou ukázkou je funkce uhid_hid_get_raw() v drivers/hid/uhid.c:

size_t len;
/* ... */
return ret ? ret : len;

Při pohledu na okolní kód je člověku jasné, že pokud je ret nastaveno na nulu, tak byla hodnota len náležitě nastavena. Jenže kompilátor není schopen toto vydedukovat a varuje, že len může být použito v neinicializovaném stavu.

Zjevně se na toto varování dá reagovat úpravou deklarace, kde proměnnou rovnou inicializujeme:

size_t len = 0;

Toto je postup, od kterého jaderní vývojáři obvykle odrazují. Nepotřebná inicializace vede ke generování více kódu a (lehce) delšímu běhu. Navíc člověka rozčiluje, když si kompilátor vymýšlí a vy se tomu musíte přizpůsobovat; Skuteční jaderní hackeři něco takového netolerují. Proto bylo přidáno speciální makro:

/* <linux/compiler-gcc.h> */
#define uninitialized_var(x) x = x

V deklaracích se používá takto:

size_t uninitialized_var(len);

Toto makro má za následek potlačení varování, ale nevede ke generování žádného dodatečného kódu. Makro se stalo dosti oblíbeným; rychlý grep odhalí, že v repozitáři verze 3.7+ má 280 výskytů. Není se čemu divit: umožňuje vývojářům vypnout chybné varování a rovnou tento fakt dokumentovat.

uninitialized_var() má ale své vlastní problémy. Jedním je, že přesvědčením GCC, že proměnnou inicializujeme, jej také přesvědčujeme, že proměnnou používáme. Pokud tato proměnná není nikde jinde použita, kompilátor pak už nevypíše varování o „nepoužité proměnné“. Proto je pravděpodobné, že existuje spousta nadbytečných proměnných, jež nebyly odstraněny, protože nikdo nezaregistroval, že nejsou doopravdy používány. To trochu naštve, ale ještě by se to dalo přejít, kdyby ale šlo o nedostatek jediný.

Dalším problémem je ale to, že kompilátor měl možná původně pravdu. Během začleňovacího okna verze 3.7 byl zařazen patch přesouvající kód pracující s rozšířenými atributy z tmpfs do obecného kódu. Během toho si vývojář všiml, že by bylo možné odstranit jednu inicializaci proměnné, protože se zdálo, že získá svou hodnotu někde jinde. GCC nesouhlasilo a varovalo, takže když tento vývojář napsal druhý patch, tak rovnou varování potlačil pomocí uninitialized_var(). GCC ale tentokrát vědělo, o čem mluví; do kódu byl tudíž zavlečen bug, kdy za určitých okolností kfree() dostalo neinicializovanou proměnnou, což má jednoznačně dosti výbušné následky. Bug museli vystopovat jiní vývojáři; opravu provedl David Rientjes 17. října. A zrovna tehdy Hugh Dickins řekl, že jde o dobrou ukázku toho, jak se může používání uninitialized_var() pokazit.

A podobný problém by tam samozřejmě nemusel být od začátku. Kód mohl být už od svého počátku správě a stejně tak uninitialized_var() mohlo být použito správně. Jenže změny v budoucnu by pak mohly způsobit chybu, na kterou by kompilátor obvykle varoval, kdyby ho ovšem neumlčeli. Proto je každé použití uninitialized_var() pastí, do které se neznalý člověk snadno chytí.

To je ostatně proč Linus v říjnu varoval, že tuto věc, kterou nazval odporností, odstraní:

Je to postavené na hlavu. Máme to tu prakticky jen kvůli chybám v kompilátorech (*hloupé* chování gcc) a bylo by lepší, kdybychom použili explicitní (zbytečnou) inicializaci, která alespoň nepovede k náhodným pádům v případě chyby.

V reakci na to Ingo Molnar sestavil patch, který kompletně odstraňuje uninitialized_var(). Každé použití makra je nahrazeno příslušnou inicializací proměnné. K tomu je připojen komentář /* GCC */ označující důvod dané inicializace.

Patch byl přijat kladně a zdá se, že má cestu do jádra volnou. V říjnu Ingo řekl, že patch do linux-next nedá (aby předešel nesčetným konfliktům při slučování), ale nechá jej zařadit hned na konci okna verze 3.8. V době psaní tohoto textu se tak ještě nestalo, ale nic nenasvědčuje tomu, že by se tento záměr neměl uskutečnit. Proto je pravděpodobné, že v jádře 3.8 už makro uninitialized_var() nebude a vývojáři budou muset umlčnovat kompilátor postaru.

Diskuse k tomuto článku

[Sten]

Za zkušenosti má kompilátor vždy pravdu, když varuje, i když tvrdí trochu něco jiného, než co je skutečný problém. Použití return ret ? ret : len; ukazuje na nepříliš promyšlenou strukturu kódu, protože zbytečně porovnávám ret na konci funkce, když už někde dříve muselo být jasné a musel jsem otestovat, že není nulové (a tedy jsem měl funkci ukončit už tam), protože jinak by len bylo inicializováno.

[kralyk z abclinuxu]

To není tak úplně jisté...

Jednak mám dojem, že dle C89 (s -pedantic) musíš mít deklarace proměnných na začátku scope. Ale nevim, podle jakýho standardu se kompiluje jádro.

No a jednak si umím představit i takovej kód, kde by to opravdu muselo být rozlišeno až na konci. Asi by to chtělo vidět ten konkrétní kód...

[Sten]

Jednak mám dojem, že dle C89 (s -pedantic) musíš mít deklarace proměnných na začátku scope. Ale nevim, podle jakýho standardu se kompiluje jádro.

To by nevadilo, to varování vyvolá až použití.

No a jednak si umím představit i takovej kód, kde by to opravdu muselo být rozlišeno až na konci. Asi by to chtělo vidět ten konkrétní kód...

Já si ho samozřejmě taky umí představit, to ale neznamená, že je strukturálně správně.

[Goheeca]

static int uhid_hid_get_raw(struct hid_device *hid, unsigned char rnum,
			    __u8 *buf, size_t count, unsigned char rtype)
{
	struct uhid_device *uhid = hid->driver_data;
	__u8 report_type;
	struct uhid_event *ev;
	unsigned long flags;
	int ret;
	size_t uninitialized_var(len);
	struct uhid_feature_answer_req *req;

	if (!uhid->running)
		return -EIO;

	switch (rtype) {
	case HID_FEATURE_REPORT:
		report_type = UHID_FEATURE_REPORT;
		break;
	case HID_OUTPUT_REPORT:
		report_type = UHID_OUTPUT_REPORT;
		break;
	case HID_INPUT_REPORT:
		report_type = UHID_INPUT_REPORT;
		break;
	default:
		return -EINVAL;
	}

	ret = mutex_lock_interruptible(&uhid->report_lock);
	if (ret)
		return ret;

	ev = kzalloc(sizeof(*ev), GFP_KERNEL);
	if (!ev) {
		ret = -ENOMEM;
		goto unlock;
	}

	spin_lock_irqsave(&uhid->qlock, flags);
	ev->type = UHID_FEATURE;
	ev->u.feature.id = atomic_inc_return(&uhid->report_id);
	ev->u.feature.rnum = rnum;
	ev->u.feature.rtype = report_type;

	atomic_set(&uhid->report_done, 0);
	uhid_queue(uhid, ev);
	spin_unlock_irqrestore(&uhid->qlock, flags);

	ret = wait_event_interruptible_timeout(uhid->report_wait,
				atomic_read(&uhid->report_done), 5 * HZ);

	/*
	 * Make sure "uhid->running" is cleared on shutdown before
	 * "uhid->report_done" is set.
	 */
	smp_rmb();
	if (!ret || !uhid->running) {
		ret = -EIO;
	} else if (ret < 0) {
		ret = -ERESTARTSYS;
	} else {
		spin_lock_irqsave(&uhid->qlock, flags);
		req = &uhid->report_buf.u.feature_answer;

		if (req->err) {
			ret = -EIO;
		} else {
			ret = 0;
			len = min(count,
				min_t(size_t, req->size, UHID_DATA_MAX));
			memcpy(buf, req->data, len);
		}

		spin_unlock_irqrestore(&uhid->qlock, flags);
	}

	atomic_set(&uhid->report_done, 1);

unlock:
	mutex_unlock(&uhid->report_lock);
	return ret ? ret : len;
}

Stačilo by přiřadit len do ret v té else větvi.

[kralyk z abclinuxu]

No to je teda prasečina... Nelíbí se mi na tom, že ret i celá ta funkce je int, kdežto len je size_t.

[Goheeca]

Jo to implicitní přetypování se mi taky nelíbí.

[j]

A nebylo by lepsi opravit ten kompilator?

[Ondrej 'SanTiago' Zajicek]

Jestli pod 'opravit' myslis upravit GCC tak, aby nehlasil to varovani tam, kde nemuze k problemu dojit, a hlasil tam, kde muze, tak to principielne neni mozne. At pouzijes sebelepsi algoritmus, tak vzdy jsou pripady, kdy nelze spolehlive ani potvrdit ani vyvratit chybu, a maximalne v takovych pripadech lze zvolit zda hlasit varovani (a riskovat false positive) nebo nehlasit (a riskovat false negative). Pritom ty priklady mohou byt treba prokazatelne korektni. Abych se nepoustel do konstrukci spojenych s vycislitelnosti, tak staci vzit v uvahu pripad, kdy chovani zavisi na nejakem vnejsim faktoru (napr. externi funkci), o niz kompilator nema zadne informace, ale programator ma.

[teoretik]

Opravit? U te analyzy inicializaci se v extremnich pripadech muze jednat o ekvivalent problemu zastaveni, tedy o neco algoritmicky neresitelneho. I kdyz mohl by to Honza Hubicka zadat jako semestralku studentum, treba mu to nekdo omylem vyresi... :)

[:::]

poslyste vy dva teoretici nademnou. Principielne resitelny to samozrejme je a s problemem zastaveni to nema nic spolecnyho.

Ale je pravda ze kvuli volani dalsich funkci nemusi mit kompilator vsechny potrebny informace a shanet je by zbytecne zpomalovalo preklad.

[petr_p]

Principielne resitelny to samozrejme je a s problemem zastaveni to nema nic spolecnyho.

Důkaz máte? :)

[teoretik]

Nejsem sam kdo si to mysli:

http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings <- "Unfortunately, detecting when the use of an uninitialized variable is equivalent, in the general case, to solving the halting problem."

[Grunt]

Co třeba inicializace na nějakou předefinovanou hodnotu nečíselného typu (podobně jako je NaN) kdy při libovolné operaci s touto hodnotou vyhodí procesor debugovací přerušení nebo si udělá zářez na křemík nebo tak něco? Bylo by to o moc blbější?

[Bluebear]

Ale co dělat u integerů?

Respektive, dalo by se přidat zvláštní flag "je-není inicializován". Bohužel myslím, že tohle tam dát, tak Linus vezme nunčaky a půjde po krvi toho, kdo ten patch do GCC poslal.

Ukazatele by samozřejmě šlo inicializovat na NULL, a osobně bych byl pro, ale spousta lidí by (právem) začala nadávat, že to je v drtivé většině případů zcela zbytečná instrukce a přístup do paměti.

[Grunt]

Ale co dělat u integerů?

To by se asi muselo implementovat na procesoru, kdy libovolná aritmetická operace s nějakým specifickým číslem (nebo číslem s flagem) by způsobila vyhození z běžného běhu.

Ukazatele by samozřejmě šlo inicializovat na NULL, a osobně bych byl pro, ale spousta lidí by (právem) začala nadávat, že to je v drtivé většině případů zcela zbytečná instrukce a přístup do paměti.

Tak třeba #ifdef DEBUG. Furt lepší kfree(NULL) než kfree(rand()).

[petr_p]

Pokud někdo potřebuje něco takového, tak nepoužije C, ale Adu. C má mnohem více záludnějších problémů ,jako ke třeba přetečení znaménkového integeru. Ostatně těšte se na GCC 4.8, které jde s optimalizacemi ještě více na dřeň specifikace, kdy například takovéto přiřazení do iterátoru povede k zacyklení programu.

[Grunt]

Pokud někdo potřebuje něco takového, tak nepoužije C, ale Adu.

Takže už jen stačí přepsat jádro z Céčka do Ady…

jako ke třeba přetečení znaménkového integeru

V tom problém nevidím. Když přeteče, tak se začne počítat znova od spodní hranice rozsahu, ne?

[Voty]

jako ke třeba přetečení znaménkového integeru

V tom problém nevidím. Když přeteče, tak se začne počítat znova od spodní hranice rozsahu, ne?

Dle normy je to nedefinovaná operace a tudíž se může stát cokoliv. Například v kódu:

int a, b;

...

if(a > 0 && b > 0)
{
    int c = a + b;
    
    if(c < 0)
    {
        printf("Overflow");
    }
}

může překladač usoudit, že při sčítání dvou kladných čísel nemůže nastat "legální" situace, kdy výsledek součtu bude záporný a Overflow se nikdy nevypíše.

[Grunt]

1. Furt nevidím problém
2. Tohle

   if(c < 0)
       {
           printf("Overflow");
       }

   mi moc validní nepřijde. Není k detekci přetečení určen overflow flag v SR?

[Voty]

Byla to jen ukázka, co se může stát (přišlo mi to lepší než příklad s auty :)

Každopádně jde o to, že u znaménkových integerů v jazyce C obecně neplatí (nelze se spolehnout) na to, že se začne počítat od spodní hranice rozsahu. A vyrobit podobnou chybu může být poměrně snadné, v příkladu je naznačen jeden možný (a zcela zřejmý) postup.

Norma C poměrně jasně říká, že pokud dojde k přetečení integeru, může se dále dít prakticky cokoliv a další chování programu je _zcela_ nedefinované. Mimojiné je tak překladači dovoleno jakékoliv testy na zjištění, že došlo k přetečení ignorovat a v rámci optimalizace je úplně vyhodit. Nehledě na to, že svět není jen x86 a některé arch overflow flag ani nemají.

[petr_p]

Doporučuji nečíst vlákno, proč bash vrací na $((2**63)) divný výstup. Mohl byste mít špatné spaní.