On Tue, Mar 20, 2007 at 02:27:24PM +0100, Dan Lukes wrote: > Lubomir Host napsal/wrote, On 03/20/07 10:04: > > stretol sa niekto niekedy s takymto problemom? Tuto je vypis dmesg: > > > Mar 20 09:44:14 vyvoj kernel: collecting pv entries -- suggest increasing > > PMAP_SHPGPERPROC > > Mar 20 09:46:11 vyvoj syslogd: kernel boot file is /boot/kernel/kernel > > Mar 20 09:46:11 vyvoj kernel: maxproc limit exceeded by uid 4006, please > > see tuning(7) and login.conf(5). > > Mar 20 09:46:11 vyvoj kernel: panic: vm_thread_new: kstack allocation failed > > > Kolega nakodoval jeden perlovy skript, ktory vytvaral nejakym sposobom > > stale nove vlakna. Spustil to pod neprivilegovanym uzivatelom (vid uid > > = 4006). Ten skript mu ale nejako zblbol a zacal vytvarat strasne vela > > vlakien. > > A jak zni otazka ? > > Kazdy novy thread vyzaduje aby pro ni kernel drzel jakousi datovou > strukturu. Mnozstvi pameti kernelu dostupne je vsak omezene. Po > vycerpani dalsi alokace mozna neni - a to dopadne prave takhle. > > Vytvareni novych procesu (ktere take vyzaduje alokaci datove struktury) > obsahuje limity, ktere by mely omezit schopnost uzivatele vycerpat tyto > omezene zdroje.
To mi je vsetko zhruba jasne, ale dakujem za vysvetlenie. Nemal by vsak kernel v takomto stave reagovat radsej tak, ze nedovoli uz vytvorit dalsie vlakno a teda ze zabije inkriminovany proces sam? Aj SIGSEGV signal zaslany takejto chybnej aplikacii by bol tuto namieste. > Moznost vytvaret nove thready IMHO nijak omezena neni a kazdy uzivatel > tak patrne nezrizenym vytvarenim movych ma moznost shora popsany panic > vyvolat. Otazka znie, ze ci to je spravne spravanie, ak moze neprivilegovany uzivatel dosiahnut reboot stroja. Ja by som to videl na nejaky bug v kerneli. rajo -- ,''`. Lubomir Host 'rajo' <rajo AT platon.sk> ICQ #: 257322664 : :' : Jabber: rajo AT jabber.platon.sk VoIP: callto://rajo207 `. `' WWW: http://rajo.platon.sk/ Platon Group: http://platon.sk/ `- GnuPG key: DC0C C7EA 55C8 B089 C41D 944A F251 A93A 2361 A82F -- FreeBSD mailing list ([email protected]) http://www.freebsd.cz/listserv/listinfo/users-l
