Jaderné noviny – 28.10.2010: Optimalizace návěští skoku goto (diskuse)

[Michal]

seccomp ... on to nekdo pouziva?

[frr]

Tenhle citát mě zaujal - nepochopil jsem, o co šlo. Tak jsem se mrknul na přilinkovaný originál. A musím říct, že pořád docela nechápu, na co M.Garrett naráží - zpráva v LKML je ve vlákně jediná (nikdo nereagoval) a nedokážu dohledat případné předchozí debaty, na které M.Garrett možná reaguje. Patch níže obsahuje dokonale čitelný kus kódu, který upravuje kernel/printk.c - a způsobuje přidávání náhodných znaků do printk zpráv. Trochu světla na tu záležitost vrhne strýček Google, pokud zadáte prostě "Zalgo" - zjevně nějaký insider termín / kulturní fenomén z oblasti komixu a cyberpunku (řečeno jazykem internetových dědečků). V kostce bych řekl, že tady nejspíš prostě zas jednou někomu hrabe z přepracování

[Kvakor]

Hmm, podle rozličných zdrojů (např. Know You Meme) to opravdu pochází z jednoho komixu a z důvodů, po kterých raději pátrat nebudu, Zalgo, zvaný též jako Ten, Který Čeká Za Zmi, reprezentuje chaos, rozklad a zpotvořené znaky typu Z͂̾͂̄͗ͦẢͪͣ͌͑̒̐LͦGͦͩ̓ͧOͭ̎̒,͑ proto ona narážka na Něj u vkládání podobného "bordelu" do výstupu printk(). Ale raději po Něm moc negooglete, mně stačilo pár minut a mám chuť si vyndat mozek z hlavy a pořádně ho vydrhnou rejžákem

[_dworkin]

Chapu to dobre, ze tam, kde to jde, se:

if (unlikely(*key)) goto label;

Prelozi na:

goto label;

nebo:

nop; nop; nop; // podle delky kodu toho predchoziho

a ve chvili co se aktivuje/deaktivuje sledovaci bod ty fce budou samomodifikovat spustitelny kod? Jsem myslel ze se tohle od dob 8-bitu a realneho modu x86 nedela. Dokonce jsem myslel, ze jsou nad useky kde lezi instrukce nejaky flagy, ktery zakazuji zapis. A ze se tyhle techniky opustily kvuli snazsi citelnosti a aby se snaze odhalili viry.

[trekker.dk]

Dokonce jsem myslel, ze jsou nad useky kde lezi instrukce nejaky flagy, ktery zakazuji zapis.

Vztahuje se tohle i na paměť jádra? Proti zápisu z userspace je chráněná z principu. (A když někdo ukecá jádro, aby modifikovalo svou vlastní paměť, problém je jinde.)

A navíc... buď něco můžeš dělat se snazší čitelností, nebo mít rychlejší jádro a tím celý stroj. Vzhledem k tomu, že v tomhle případě to první není nijak velký problém, hlasuju pro to druhé.

[_dworkin]

Osobne se mi to taky libi, ale jsem velmi prekvapen ze to vubec jde. Kdyz i moznost pouzivat goto u nekterych vyvolava husi kuzi a kupodivu jim vadi i strukturovany goto schovany za continue a break. Na druhou stranu je tohle schovany pod #define JUMP_LABEL(key, label) if (unlikely(*key)) goto label; a jak je to reseno "fyzicky" je nemusi znepokojovat, jako je neznepokojuje ani jmp ve vyslednem kodu.

[chrono]

Osobne se mi to taky libi, ale jsem velmi prekvapen ze to vubec jde.

Niečo podobné sa využíva aj pri JIT v JavaScript, Jave..., takže urobiť sa to dá, stačí len vhodne nastaviť parametre stránok.

[_dworkin]

Ale urcite by se mi to prestalo libit a zacala bolet hlava, kdybych mel byt v kuzi navrhare CPU, kteremu se kod modifikuje pod rukama a ja delal kvuli zrychleni nejake predzpracovani.

[trekker.dk]

Ono nějaké CPU předzpracovává kód tak, že se to někam trvale uloží? Pokud vím, tak všechno, co CPU dělá, se týká kódu, který je vykonáván v danou chvíli, což tady není relevantní (kód, který se modifikuje, nemůže zároveň běžet.)

[chrono]

Pri x86 procesoroch od Intel bolo niečo také použité už pri P4 procesoroch a pri Sandy Bridge to zjednodušili (celkom pekný popis sa dá nájsť napr. tu).

[Kvakor]

Problémy s dekódováním samomodifikujícího se kódu jsou tu už od dob, kdy se instrukce načítraly dopředu, což je u x86 někdy od 286 (8086 sice také má prefetch, ale jen 6 byte, což většinou moc nevadilo). Pamatuju na doporučení u přepínání real/protected módu, kde se těsně po přepnutí doporučuje udělat dlouhý* skok na následující instrukci, aby se vyprázdnila fronta, ve které mohou být ještě instrukce nadekódované pro realmód. Novější proceory mají na podobné účely přímo připravené instrukce, fungující jako bariéry, za cenu toho, že procesor zahodí celou frontu nadekódovanýžch instrukcí a znova je načte.

*Dlouhý ve smyslu segment, resp. selektor:offset, ne ve smyslu délky

[Milan Jurik]

Tady je jen drobny rozdil - ten kod se nesamomodifikuje, jen ty NOPy predstavuji prostor v kodu, ktery lze modifikovat. Tu modifikaci zaridi zcela jiny thread, at uz jadra ci jine aplikace. Takze vami popsany problem nenastava, protoze CPU uz uvidi zmodifikovany kod, kdyz se k nemu dostane (vyjma extremnich pripadu "trefeni se" do zrovna vykonavaneho kodu).

[trekker.dk]

vyjma extremnich pripadu "trefeni se" do zrovna vykonavaneho kodu

Ty jsou samozřejmě ošetřeny. Když se kód takto modifikuje, jádro zastaví všechna CPU v systému kromě jednoho (které ovšem nemůže vykonávat měněný kód, protože zrovna vykonává měnící kód)

[Milan Jurik]

Pri zapinani proby (prepisem NOPu) se na Linuxu zastavi vsechna CPU? Dost drsna metoda pri hodne CPU a hodne probes, ktere maji byt aktivovany. Existuji vhodnejsi triky.

[trekker.dk]

No jo, abys mě nechytal za slovíčka, že jo... podstatou příspěvku bylo sdělit, že situace trefení se do modifikovaného kódu je ošetřena.

[Luboš Doležel (Doli)]

Nevíte někdo, jestli už v C++0x jde dělat break jako v Javě podle návěští? Příklad:

outer:
for (;;)
{
  for (;;)
  {
    if (...)
      break outer;
  }
}

[Jirka]

A co tohle? http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Named_Loop

Je to vubec potreba? Python to nepotrebuje: http://mail.python.org/pipermail/python-3000/2007-July/008663.html .

[Semo]

Bash to ma (nepovinny parameter breaku udava, z kolko cyklov sa ma vyskocit. A obcas sa to hodi a blbo sa to nahradza niecim inym pri sucasnej poziadavke na zachovanie prehladnosti.

[Luboš Doležel (Doli)]

A co tohle? http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Named_Loop

Což ono se to dá vždycky nějak vyřešit, spíš mě zajímalo, jestli to do C++0x přidali nativně.

[Tomáš]

Teď jsem to v Pythonu taky potřeboval a bylo to přesně, jak je napsáno v odkazu. Lehkou změnou struktury toho kousku kódu to šlo vyřešit i s jednou smyčkou (loop).

[Milan Jurik]

Inu, dela se to. Pro zajemce treba prednaska o implementaci dtrace na x86 platforme (CZOSUG prezentace z roku 2006 od Franka Hofmanna). Diky prefetch/pipeline to pak ma v podstate nulovou rezii, pokud je sledovaci bod neaktivni.

[zde]

Na ta makra jsem nikdy nekoukal, ale měl jsem pocit že patchování kódu při zapínání trasovacích bodů se v jádře používá už několik let, proto omc nerozumím proč se to tady najednou bez souvislosti rozebírá..

[chrono]

Ak si dobre spomínam, tak pred nejakým časom práve patchovanie nejakej adresy bez toho, aby sa skontrolovalo, či tam je to, čo tam bolo predtým, spôsobovalo nejakú chybu.

[snehuliak]

Tak uz konecne chapem preco ma M$ instrukcie noop v cykloch ;) a odteraz ich bude mat aj Linux... lol

[snehuliak]

I think goto's are fine, and they are often more readable than large amounts of indentation. That's _especially_ true if the code flow isn't actually naturally indented (in this case it is, so I don't think using goto is in any way _clearer_ than not, but in general goto's can be quite good for readability).

Of course, in stupid languages like Pascal, where labels cannot be descriptive, goto's can be bad. But that's not the fault of the goto, that's the braindamage of the language designer.

Linus

[snehuliak]

Este dodam pre anglicky hovoriacich, ze zvysok diskusie je tiez zaujimavy: http://kerneltrap.org/node/553/2131

Suhlasim s Linusom ze vela "vyssieho" kodu sa aj tak tranformuje do "goto" a teda jmp alebo podmienenych jmp. Momentalne nemame procesory bez skokov a x86 architektura nepozna "callz" alebo "retz" (alebo dalsie flagy) ktore si urcite pamataju fanusikovia Z80...

Co sa tyka goto - Asi sme na skolach fakt boli "brainwasched"...

[trekker.dk]

Co sa tyka goto - Asi sme na skolach fakt boli "brainwasched"...

To si pamatuju na vejšce, jak je goto špatné, protože procesor má pipeline a ta se musí zahodit a kdesi cosi...