Messages in this thread | | | Date | Fri, 16 May 1997 08:36:34 +0200 (MET DST) | From | "Michael L. Galbraith" <> | Subject | Re: 2.0.30 crash in lock_remove_locks (cont'd) |
| |
On Thu, 15 May 1997, Carlo Wood wrote:
> Hi again, > > I think I also know which part of the patches is the problem *shrug* : > the new ones :). That is, I need to run several irc daemons with > each more then 2048 clients (for testing ircu2.10), so I tried to increase > the number of fd's per process to 4096. > Hi Carlo,
Yeah, but you forgot to change __FD_SETSIZE in include/linux/posix_types.h and /usr/include/gnu/types.h for one.
BTW gurus: isn't it dangerous having NR_OPEN and __FD_SETSIZE defined in multiple places? I noticed that recent 2.0.x and 2.1.x kernels have __FD_SETSIZE defined as 1024. /usr/include/gnu/types.h has it defined as 256.
> I think that the kernel crash is still a bug. I also saw once a patch > for 2.0.29 that made it possible to do this (this huge amount of fd's), but > this patch didn't apply to 2.0.30 : all hunks but one failed. I hoped it > was solved in another way. >
Increasing # of fd's without the malloc patch creates a stack size problem. limited_fd_set is 32 bytes at 256 fd's.. 512 at 4096. Sys_select allocates 3 of these on the stack.. 1.5k of stack usage for 1 function is pretty much a guaranteed overflow. That's where I think your crash comes from. Also, I can say that because I did that once too :) with the same result.. kaboom.
Your change to struct cmsghdr is not needed. The cmsg_data[0] should be a zero sized array. What gcc does with this kind of construct is.. when you dereference this pointer, it points to the next available memory cell of the type you allocated *at the time you allocated it*. This works fine as long as the data is aligned (true in this case) or if you use __attribute__((aligned)). I thoroughly tested this the first time it came up out of curiosity/ needless_worry.
> Please let me know what to do if I need 4096 fd's per process (and a LOT > more for the total system, for which I thought I can use /proc/kernel). > > Carlo >
The O'Reilly patch goes in easily though you must do it manually. I have it in my 2.0.kinda_sorta.31 tree, and have been using it since it came out.
Bottom line is that this breaks one *hell* of a lot of stuff.. better really need it if you start because you'll end up recompiling nearly every library/ binary in your system to get things straight again. BTDT: reverted to 256 :)
Ciao,
-Mike
| |