Re: 2.0.30 crash in lock_remove_locks (cont'd)

Michael L. Galbraith (
Fri, 16 May 1997 08:36:34 +0200 (MET DST)

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/

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