Please give more safety margin for vger delays. I got this on Thursday.
Unless you mean "next Thursday" :-).
Maybe not _very_ important, but a few compile time configuration options
which don't add much code to the kernel, should be possible to change
at run time (using sysctl or /proc/sys/net/ipv4/*). This would reduce
the number of config questions, and also help to avoid recompiling the
kernel too often when it stabilizes...
These include (there are probably more):
CONFIG_INET_PCTCP
CONFIG_IP_NOSR
CONFIG_NO_PATH_MTU_DISCOVERY
CONFIG_SKB_LARGE (or just SK_[RW]MEM_MAX)
CONFIG_TCP_NAGLE_OFF
CONFIG_IP_FORWARD (adds more code - maybe keep the compile time option
but allow disabling it at run time if enabled at compile time; I think
someone has a patch for this)
Especially CONFIG_INET_PCTCP and CONFIG_NO_PATH_MTU_DISCOVERY - so that
you don't have to recompile after you discover some broken software in
use on the network.
> Note. The bridge will now be commented out. Its not workable enough. Sort it
> in 2.1
I'm going to test it soon (I happen to need a bridge to split one, way
too long ethernet segment into two, and a router isn't good because it
would create too many too small subnets for the number of IP addresses
available). There are no more bridges on this network, just this one.
Any chances that it will work? What are the problems should I expect?
Or am I better off using PCbridge for DOS? (the Linux box is needed
there anyway for other reasons, so it would be better to make it work
as a bridge too)
> DMA allocations dont have a blocking form - nuisance on module loads
Not just DMA - ncpfs readdir cache allocation fails often on a box
with 8MB RAM, too. It _does_ use GFP_KERNEL (not ATOMIC) but it
seems that it doesn't try to swap out things hard enough, and gives
up ("Couldn't get a free page" while there is certainly enough free
memory, but it's too fragmented).
Once the allocation of large blocks works correctly, the ftape buffer
(96K! - six times the random driver :-) could be allocated on first
open (and freed on last close), not during driver initialization.
Other things:
I often get the IPX network number collision messages on the console.
This happens on three completely different novell networks so I don't
believe they are all misconfigured - maybe change the priority of
the messages so they don't show up on the console but only in syslog.
I think there is a potential memory leak in net/core/net_alias.c
(net_alias_dev_create) if the first kmalloc succeeds but the second
one fails (won't free memory allocated by the first).
get_empty_filp() should reserve a few last files (tunable?) for the
superuser - otherwise a simple denial of service is possible. Just
fork 4 processes, have each of them try to open 256 file descriptors
- and almost everything stops working. No heavy swapping necessary.
Sometimes I get "deleted inode XX has zero dtime" from e2fsck even
though the system was shut down cleanly. Is this something to
worry about? I saw this in early 1.1.x days for the first time,
and it's still there...
The kmalloc return value not checked for NULL in net/unix/af_unix.c
(unix_copyrights, unix_attach_fds). If it fails - oops.
Regards,
Marek