On Mon, 13 Sep 1999, Matthew Dillon wrote:
> The case that is causing the panics is with the non-interrupt mbuf
> allocation mechanism. Specifically, the case where M_WAIT is used.
>
> The second problem under discussion, which really ought to be separated
> out from the mbuf pan
On Mon, 13 Sep 1999, Matthew Dillon wrote:
> The case that is causing the panics is with the non-interrupt mbuf
> allocation mechanism. Specifically, the case where M_WAIT is used.
>
> The second problem under discussion, which really ought to be separated
> out from the mbuf pa
:In 4.3, the code was able to deal with cluster allocation failing. We
:have a somewhat different situation now, because many network
:interface devices have less-flexible DMA mechanisms which don't allow
:packet reception into non-contiguous buffers, so we need to have at
:least a certain number
:In 4.3, the code was able to deal with cluster allocation failing. We
:have a somewhat different situation now, because many network
:interface devices have less-flexible DMA mechanisms which don't allow
:packet reception into non-contiguous buffers, so we need to have at
:least a certain number
I think that what needs to be done is to split the problem in two. First,
allow the mbuf routines to return a failure even with M_WAIT. If M_WAIT
is used, it simply means 'try harder, sleeping a bit if necessary'. This
requires ensuring that all the networking code deal with the
I think that what needs to be done is to split the problem in two. First,
allow the mbuf routines to return a failure even with M_WAIT. If M_WAIT
is used, it simply means 'try harder, sleeping a bit if necessary'. This
requires ensuring that all the networking code deal with th
> From woll...@khavrinen.lcs.mit.edu Mon Sep 13 22:39:37 1999
> > I'm also aware of the possiblity of some people not liking the
> > fact that we tsleep() forever (e.g. tsleep(x,x,x,0)).
>
> I don't have any problem with sleeping forever -- but I am concerned
> about the possibility of deadloc
On Mon, 13 Sep 1999, Garrett Wollman wrote:
!>< said:
!>
!>> This message is in MIME format. The first part should be readable text,
!>> while the remaining parts are likely unreadable without MIME-aware tools.
!>> Send mail to [EMAIL PROTECTED] for more info.
!>
!>It would be preferable
On Mon, 13 Sep 1999, Garrett Wollman wrote:
!>< said:
!>
!>> This message is in MIME format. The first part should be readable text,
!>> while the remaining parts are likely unreadable without MIME-aware tools.
!>> Send mail to m...@docserver.cac.washington.edu for more info.
!>
!>It woul
!>I think that what needs to be done is to split the problem in two. First,
!>allow the mbuf routines to return a failure even with M_WAIT. If M_WAIT
!>is used, it simply means 'try harder, sleeping a bit if necessary'. This
!>requires ensuring that all the networking code de
!>I think that what needs to be done is to split the problem in two. First,
!>allow the mbuf routines to return a failure even with M_WAIT. If M_WAIT
!>is used, it simply means 'try harder, sleeping a bit if necessary'. This
!>requires ensuring that all the networking code dea
< said:
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
> Send mail to [EMAIL PROTECTED] for more info.
It would be preferable if text were sent as text, since MIME-encoded
patches requir
<
said:
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
> Send mail to m...@docserver.cac.washington.edu for more info.
It would be preferable if text were sent as text, since MIME-encode
Hello (again),
On Thu, 9 Sep 1999, Stas Kisel wrote:
!>> From [EMAIL PROTECTED] Thu Sep 9 16:17:27 1999
!>
!>> > Probably it is not self-evident why we HAVE to drop this connection.
!>>
!>> So what if someone manages to crash a program due to a DOS attack ?
!>> An easy one that comes to mind i
Hello (again),
On Thu, 9 Sep 1999, Stas Kisel wrote:
!>> From ava...@cheops.anu.edu.au Thu Sep 9 16:17:27 1999
!>
!>> > Probably it is not self-evident why we HAVE to drop this connection.
!>>
!>> So what if someone manages to crash a program due to a DOS attack ?
!>> An easy one that comes to
> From ja...@puck.nether.net Thu Sep 9 18:10:06 1999
> I am creating about 100 icmp sockets, and as they are
> created, allocate a very large SO_RCVBUF:
> (void)setsockopt(localstruct->icmp_s, SOL_SOCKET,
> SO_RCVBUF, (char *)&hold, sizeof(hold));
This can be a part
> From [EMAIL PROTECTED] Thu Sep 9 18:10:06 1999
> I am creating about 100 icmp sockets, and as they are
> created, allocate a very large SO_RCVBUF:
> (void)setsockopt(localstruct->icmp_s, SOL_SOCKET,
> SO_RCVBUF, (char *)&hold, sizeof(hold));
This can be a part of
> I would get out of mbufs, increase maxusers. Either my code
> is less agressive than originally, or something has changed in
> some of the freebsd releases since then, even slightly to prevent this
> from currently happening. I'm not sure which. NetBSD also suffers
> from this problem, a
> I would get out of mbufs, increase maxusers. Either my code
> is less agressive than originally, or something has changed in
> some of the freebsd releases since then, even slightly to prevent this
> from currently happening. I'm not sure which. NetBSD also suffers
> from this problem,
> From ava...@cheops.anu.edu.au Thu Sep 9 16:17:27 1999
> > Probably it is not self-evident why we HAVE to drop this connection.
>
> So what if someone manages to crash a program due to a DOS attack ?
> An easy one that comes to mind is syslogd. It's often stuck in disk-wait
> and can easily be
On Thu, Sep 09, 1999 at 01:45:39PM +0400, Stas Kisel wrote:
> > From: Darren Reed
>
> > The problem with this is the BSD TCP/IP implementation ACK's (or at least
> > attempts to ACK) data as soon as it is received and it is a big no-no to
> > discard queued data that has already been ACK'd.
>
>
> From [EMAIL PROTECTED] Thu Sep 9 16:17:27 1999
> > Probably it is not self-evident why we HAVE to drop this connection.
>
> So what if someone manages to crash a program due to a DOS attack ?
> An easy one that comes to mind is syslogd. It's often stuck in disk-wait
> and can easily be target
On Thu, Sep 09, 1999 at 01:45:39PM +0400, Stas Kisel wrote:
> > From: Darren Reed <[EMAIL PROTECTED]>
>
> > The problem with this is the BSD TCP/IP implementation ACK's (or at least
> > attempts to ACK) data as soon as it is received and it is a big no-no to
> > discard queued data that has alrea
In some mail from Karl Pielorz, sie said:
>
> Darren Reed wrote:
>
> > > It is evil connection. Good applications do read data from their sockets,
> > > and evil ones do not. And ever if it is good, but silly or busy
> > > application, good clients do not send so much data that application
> > >
Darren Reed wrote:
> > It is evil connection. Good applications do read data from their sockets,
> > and evil ones do not. And ever if it is good, but silly or busy
> > application, good clients do not send so much data that application
> > can not process it. Am I wrong, there are any examples?
>
In some mail from Stas Kisel, sie said:
>
> > From: Darren Reed
>
> > The problem with this is the BSD TCP/IP implementation ACK's (or at least
> > attempts to ACK) data as soon as it is received and it is a big no-no to
> > discard queued data that has already been ACK'd.
>
> Probably it is no
In some mail from Karl Pielorz, sie said:
>
> Darren Reed wrote:
>
> > > It is evil connection. Good applications do read data from their sockets,
> > > and evil ones do not. And ever if it is good, but silly or busy
> > > application, good clients do not send so much data that application
> > >
Darren Reed wrote:
> > It is evil connection. Good applications do read data from their sockets,
> > and evil ones do not. And ever if it is good, but silly or busy
> > application, good clients do not send so much data that application
> > can not process it. Am I wrong, there are any examples?
In some mail from Stas Kisel, sie said:
>
> > From: Darren Reed <[EMAIL PROTECTED]>
>
> > The problem with this is the BSD TCP/IP implementation ACK's (or at least
> > attempts to ACK) data as soon as it is received and it is a big no-no to
> > discard queued data that has already been ACK'd.
>
> From: Darren Reed
> The problem with this is the BSD TCP/IP implementation ACK's (or at least
> attempts to ACK) data as soon as it is received and it is a big no-no to
> discard queued data that has already been ACK'd.
Probably it is not self-evident why we HAVE to drop this connection.
It i
> From: Darren Reed
>
> In some mail from Stas Kisel, sie said:
> [...]
> > IMHO it is a good idea to develop tcp_drain() from /sys/netinet/tcp_subr.c
> > It should be quite intellectual to select a target - a process or a uid,
> > which does not read properly from it's sockets, and has many data
> From: Darren Reed <[EMAIL PROTECTED]>
> The problem with this is the BSD TCP/IP implementation ACK's (or at least
> attempts to ACK) data as soon as it is received and it is a big no-no to
> discard queued data that has already been ACK'd.
Probably it is not self-evident why we HAVE to drop th
> From: Darren Reed <[EMAIL PROTECTED]>
>
> In some mail from Stas Kisel, sie said:
> [...]
> > IMHO it is a good idea to develop tcp_drain() from /sys/netinet/tcp_subr.c
> > It should be quite intellectual to select a target - a process or a uid,
> > which does not read properly from it's sockets
(probably some debugging), but I wouldn't mind doing this. However, I'd
> like to know if there are objections to doing this or, in fact, if there
> are any suggestions on how to handle mbuf shortage situations (aside from
> just limiting -- although limiting is in itself a good solu
ably some debugging), but I wouldn't mind doing this. However, I'd
> like to know if there are objections to doing this or, in fact, if there
> are any suggestions on how to handle mbuf shortage situations (aside from
> just limiting -- although limiting is in itself a good solu
On Sep 5, 9:18pm, Matthew Dillon wrote:
} Subject: Re: mbuf shortage situations
} : The only reason that I see for which we would actually panic() in
} :this situation (as opposed to suffer the packet loss) is if we get to the
} :point where we're losing packets because some script kid s
On Sep 5, 9:18pm, Matthew Dillon wrote:
} Subject: Re: mbuf shortage situations
} : The only reason that I see for which we would actually panic() in
} :this situation (as opposed to suffer the packet loss) is if we get to the
} :point where we're losing packets because some scrip
s handeled relatively 'cleanly'
:(probably some debugging), but I wouldn't mind doing this. However, I'd
:like to know if there are objections to doing this or, in fact, if there
:are any suggestions on how to handle mbuf shortage situations (aside from
:just limiting -- although limitin
s handeled relatively 'cleanly'
:(probably some debugging), but I wouldn't mind doing this. However, I'd
:like to know if there are objections to doing this or, in fact, if there
:are any suggestions on how to handle mbuf shortage situations (aside from
:just limiting -- although limitin
#x27;d
like to know if there are objections to doing this or, in fact, if there
are any suggestions on how to handle mbuf shortage situations (aside from
just limiting -- although limiting is in itself a good solution and I'm
glad that Brian F. is working on that).
Cheers,
Bosko.
/*
*
#x27;d
like to know if there are objections to doing this or, in fact, if there
are any suggestions on how to handle mbuf shortage situations (aside from
just limiting -- although limiting is in itself a good solution and I'm
glad that Brian F. is working on that).
Cheers,
Bosko.
/*
* Bo
41 matches
Mail list logo
