Názory k článku
Jádro 6.8 bude rychleji prohledávat $PATH

Wow, já doteď myslel že o zpracování $PATH se stará shell a že jádro potřebuje vždy jednoznačnou cestu pro exec. Pořád je co se učit.

mno exec je funkce kernelu. Zakladni rekneme. A exec jede bez shellu samzorejme. A exec bere jak plnou cestu k prikazu, tak path + prikaz z path... Tolik k uceni :)

Ta funkce je zduplikovaná v shellu, libc, v jádře.

Shell normálně najde (vytáhne z předpřipravené hash mapy) cestu k programu a to předá jedné z libc exec funkcí, která to verbatim předá jadernému execvpe (např) syscallu.

Knihovní exec může ale volat i někdo jiný a nepředat úplnou cestu, potom to v PATH hledá implementace v libc (hezky čitelně to je v musl src/process/e­xecvp.c).

A taky může někdo přímo zavolat exec syscall bez úplné cesty, a nebo spustit skript jehož #! nemá úplnou cestu. Pak je na jádře, aby si to našlo samo.

9. 1. 2024, 12:22 editováno autorem komentáře

no a pak příjde nějaký pan Poettering a nakáže nám, že vše v exec musí mít absolutní cestu...

U konfigurace systémových služeb to je rozumné rozhodnutí – nebo opačně, je špatně v takovém případě spoléhat na $PATH, jejíž obsah ani neznáte. Kolik bylo jenom tady ve fóru dotazů, kdy někdo řešil, že mu něco nefunguje z cronu nebo init skriptu, a když to spustí ručně, funguje mu to – a problém byl to, že spouštěl něco z $PATH, ve svém prostředí to měl, ale cron nebo init skript měl mnohem menší $PATH a daná věc tam prostě nebyla.

Taky mě to překvapilo. Pak jsem kouknul na patch a on jenom optimalizuje pořadí operací - místo kopírování argumentů and environment a poté exec filename lookup provede nejdřív filename lookup a pokud selže, tak rovnou vrátí chybu a ostatní drahé operace přeskočí.

Takže klasický exec zůstává pořád implementovaný v libc a zkouší postupně všechny cesty. Chytřejší shelly si "úspěšnou" path cachují.

Ulozit si uspesnou cestu do cache moc chytre neni, protoze obsah adresaru se muze zmenit. Shell by si musel hlidat zmeny v PATH adresarich pres inotify, ktere ale nefunguje pro vzdalene vyvolane zmeny u sitovych souborovych systemu.

bash používá svůj hash, platí pouze pro daný proces, je in-memory a vynulovat ho můžeš ručně nebo redefinicí PATH. Změny v adresářích se nehlídají, problém to může dělat pouze u hodně dlouho běžících scriptů, ty buď musíš při změně restartovat nebo uvnitř volat rehash.

To je obezlicka pro systemy bez dentry cache a minimalne u me se to musi explicitne zapnout, jinak bash vzdy zkousi vsechny cesty:

~ >date
Tue Nov 14 16:35:10 UTC 2023
~ >type date
date is /usr/bin/date
~ >set -h
~ >date
Tue Nov 14 16:35:14 UTC 2023
~ >type date
date is hashed (/usr/bin/date)


https://patchwork.kernel.org/project/linux-fsdevel/patch/5c7333ea4bec2fad1b47a8fa2db7c31e4ffc4f14.1663334978.git.josh@joshtriplett.org/

Zapomněl jsem to tam dát, doplněno, díky.

Fakt? Neuveritelne ... kolik GHzlet to tak asi usetri? Eh .. aha, ona latence libovolnyho disku ... je tak nejak radove jinde (vyse).

Chmm copak to asi tak rozbije... uz sem videl mnohem kratsi a mnohem neskodnejsi patche ... To sem zvedav, zdalipak to aspon autor aspon jednou vyzkousi ...

Hned v prvním odkazu je benchmark, stačí číst...

Pri prekladu cest se pouziva dentry cache, ktera ma bezne hit ratio temer 100%, takze nemuzu uverit tomu, ze fakt nekdo resi latenci disku. Dotaz do cache je mnohem rychlejsi nez zbytecna alokace a dealokace mm struktur.