Messages in this thread |  | | From | Marek Michalkiewicz <> | Subject | Re: Networking Patches | Date | Thu, 6 Jun 1996 03:21:17 +0200 (MET DST) |
| |
Alan Cox: > I think everything that is going to go into 2.0 is now in, if there is something > important (and I mean _IMPORTANT_) missing please scream loudly at this point > and before thursday. This is your LAST chance.
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
|  |