* lost blocks in TCP/IP streams
@ 1995-02-03 18:17 forsyth
0 siblings, 0 replies; 3+ messages in thread
From: forsyth @ 1995-02-03 18:17 UTC (permalink / raw)
I have recently tracked down some troublesome kernel
memory leaks, that turned out to be mainly in the TCP/IP subsystem.
While doing so, I found several off-by-one allocation errors that
might lead to kernel heap corruption and subsequent panics.
I'm not sure how worthwhile it is sending the changes out if a new release is
imminent, but the consequences of the various small errors are annoying enough
that you might not like to wait even a month or so. Specifically, if
you have a machine that receives or sends moderate to heavy TCP/IP traffic, chances
are that your kernel will gradually/rapidly run out of kernel memory, since it
fails to free stream Blocks at several key points. A busy but small machine (one of my 16 Mbyte PCs),
has run out of memory in under two days. Very tedious!
On the other hand, I run several other machines that haven't been
troubled anything like so much; it depends on the nature of the traffic.
Anyhow, if you are interested in receiving the changes, please let me know by
email.
If you have a >1.02 Gbyte SCSI disc, also let me know and I can supply
changes to the port SCSI code to use extended read/write requests when necessary.
Finally, here is an one line change to /sys/src/9/pc/main.c to stop reads of /dev/sysstat
from mangling memory and eventually crashing the system (386/486 only). Insert the following
line as the first executable statement of confinit():
conf.nmach = 1;
Without it, conf.nmach is zero.
^ permalink raw reply [flat|nested] 3+ messages in thread
* lost blocks in TCP/IP streams
@ 1995-02-06 17:04 Bill
0 siblings, 0 replies; 3+ messages in thread
From: Bill @ 1995-02-06 17:04 UTC (permalink / raw)
>
> I have recently tracked down some troublesome kernel
> memory leaks, that turned out to be mainly in the TCP/IP subsystem.
> While doing so, I found several off-by-one allocation errors that
> might lead to kernel heap corruption and subsequent panics.
>
> I'm not sure how worthwhile it is sending the changes out if a new release is
> imminent, but the consequences of the various small errors are annoying enough
The point of the code freeze is to fix bugs just like this, I encourage you
to submit them to linux and/or whoever is in charge of the code.
> that you might not like to wait even a month or so. Specifically, if
> you have a machine that receives or sends moderate to heavy TCP/IP traffic, chances
> are that your kernel will gradually/rapidly run out of kernel memory, since it
> fails to free stream Blocks at several key points. A busy but small machine (one of my 16 Mbyte PCs),
> has run out of memory in under two days. Very tedious!
Sounds like a bad problem, if you bother to fix em definitely give them
to the rest of the community.
> On the other hand, I run several other machines that haven't been
> troubled anything like so much; it depends on the nature of the traffic.
>
> Anyhow, if you are interested in receiving the changes, please let me know by
> email.
I personally am not, but I would think that linus wouldd.
> If you have a >1.02 Gbyte SCSI disc, also let me know and I can supply
> changes to the port SCSI code to use extended read/write requests when necessary.
>
> Finally, here is an one line change to /sys/src/9/pc/main.c to stop reads of /dev/sysstat
> from mangling memory and eventually crashing the system (386/486 only). Insert the following
> line as the first executable statement of confinit():
> conf.nmach = 1;
> Without it, conf.nmach is zero.
>
>
>
--
Bill Broadley Broadley@math.ucdavis.edu UCD Math Sys-Admin
Linux is great. http://ucdmath.ucdavis.edu/~broadley PGP-ok
^ permalink raw reply [flat|nested] 3+ messages in thread
* lost blocks in TCP/IP streams
@ 1995-02-06 17:04 Bill
0 siblings, 0 replies; 3+ messages in thread
From: Bill @ 1995-02-06 17:04 UTC (permalink / raw)
ARGH
Sorry I thought this was a linux list.... sorry.
>
> I have recently tracked down some troublesome kernel
> memory leaks, that turned out to be mainly in the TCP/IP subsystem.
> While doing so, I found several off-by-one allocation errors that
> might lead to kernel heap corruption and subsequent panics.
>
> I'm not sure how worthwhile it is sending the changes out if a new release is
> imminent, but the consequences of the various small errors are annoying enough
> that you might not like to wait even a month or so. Specifically, if
> you have a machine that receives or sends moderate to heavy TCP/IP traffic, chances
> are that your kernel will gradually/rapidly run out of kernel memory, since it
> fails to free stream Blocks at several key points. A busy but small machine (one of my 16 Mbyte PCs),
> has run out of memory in under two days. Very tedious!
> On the other hand, I run several other machines that haven't been
> troubled anything like so much; it depends on the nature of the traffic.
>
> Anyhow, if you are interested in receiving the changes, please let me know by
> email.
>
> If you have a >1.02 Gbyte SCSI disc, also let me know and I can supply
> changes to the port SCSI code to use extended read/write requests when necessary.
>
> Finally, here is an one line change to /sys/src/9/pc/main.c to stop reads of /dev/sysstat
> from mangling memory and eventually crashing the system (386/486 only). Insert the following
> line as the first executable statement of confinit():
> conf.nmach = 1;
> Without it, conf.nmach is zero.
>
>
>
--
Bill Broadley Broadley@math.ucdavis.edu UCD Math Sys-Admin
Linux is great. http://ucdmath.ucdavis.edu/~broadley PGP-ok
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~1995-02-06 17:04 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1995-02-03 18:17 lost blocks in TCP/IP streams forsyth
1995-02-06 17:04 Bill
1995-02-06 17:04 Bill
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).