FreeBSD kernel panic: vm_thread_new: kstack allocation failed
Lubomir Host
rajo at platon.sk
Tue Mar 20 15:09:58 CET 2007
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
More information about the Users-l
mailing list