On Wed, 6 Nov 2002, Ian Dowse wrote:
> In message <[EMAIL PROTECTED]>, Archie Cobbs wri > tes: > >Oops, you're right.. sorry for the misinformation. > > > >Sounds like a bug to me (did Iasen file a PR?) > > kern/38872 already exists, and I'm sure there is a much older PR > that also describes this problem. Basically it is hard to fix because > the errors are detected so deep within functions and macros that > were never designed to correctly handle mbuf allocation failures. > > I think the most feasable solution would be to use libmchain or > something like it, but even that is a huge amount of work. The > workaround is of course just setting nmbclusters/nmbufs so high > that they never run out... I don't think that is a proper way go around such bug. Thus when you are DoS-ed how can you know how much mbuf you will need ?:). My problem apeared at the moment I've tried to scan 192.168.0.0/16 with nbtscan. Mbufs were exhausted for about 2-3 second. At that moment there was NFS activity - So server crashed... Ok I won't do that again - but someone else ? And how many parts of the kernel are afected by this problem. Raising nmbclusters/nmbufs at same scan with nbtscan will give my server about 2-3 second more life. That is no good and if someone DoS-es you (local user for example) no nmbclusters/nmbufs raising will save you. Can MGET really wait for memory when M_WAIT flag is used and not to timeouts (I don't know howlong is this timeout, but system crushes at the moment of first NFS operation , thus it should be < 10ms :) ? > Ian > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
