Linux-kernel mailing list archive 1997-48,: Re: Insufficient allocations in net/unix/garbage.c

# Re: Insufficient allocations in net/unix/garbage.c

Alan Cox (alan@lxorguk.ukuu.org.uk)
Wed, 3 Dec 1997 22:36:03 +0000 (GMT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Philip Blundell: "Re: ISSUE: lp0/lp1 incompatibility"
- Previous message: Michael Neuffer: "Re: file ID redesign proposal"
- Next in thread: Erik Corry: "Re: [linux-alert] Re: Insufficient allocations in net/unix/garbage.c"
- Reply: Erik Corry: "Re: [linux-alert] Re: Insufficient allocations in net/unix/garbage.c"

> program which opens up a large number of unix domain sockets, eventually
> causing a kernel panic in the garbage collection routines (which test for
> this limit and panic if hit); on systems which have NR_FILE (or
> /proc/sys/kernel/file-max) set to a value larger than 1024 or so. The

Yep. I know about this. The as shipped systems are all fine, if you up
it you need to change it. 2.1.x fixed this a while ago

> ! stack=(unix_socket **)kmalloc(max_stack * sizeof(unix_socket **),
> ! GFP_KERNEL);

This is not good. With a very large set of fd's you can now have the kmalloc
hang forever deadlocking the fd recovery. Use vmalloc and your idea is
correct.

(see 2.1.x)

- Next message: Philip Blundell: "Re: ISSUE: lp0/lp1 incompatibility"
- Previous message: Michael Neuffer: "Re: file ID redesign proposal"
- Next in thread: Erik Corry: "Re: [linux-alert] Re: Insufficient allocations in net/unix/garbage.c"
- Reply: Erik Corry: "Re: [linux-alert] Re: Insufficient allocations in net/unix/garbage.c"