lost blocks in TCP/IP streams

lost blocks in TCP/IP streams

[forsyth]

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.

lost blocks in TCP/IP streams

[Bill]

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

lost blocks in TCP/IP streams

[Bill]

> 
> 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