Please note: I'm submitting this as a suggestion from an RHEL3 user, not as a corporate request from SGI. Description of problem: elf_core_dump uses over 1k of stack (about 20% of what's available) on ia32, due to large stack variables. Dumping core to a filesystem that is over stacked volume managers, or over a networked filesytem could cause the stack to overflow. A patch went into the 2.5 series to remedy this: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.64/2.5.64-mm1/broken-out/elf_core_dump-stack-size-reduction.patch I've attached a backport of this patch that gets elf_core_dump down under 200 bytes. It was quick work and could bear some scrutiny that I'm sure you'd give it anyway. :) Version-Release number of selected component (if applicable): 2.4.21-37 Thanks, -Eric
Created attachment 119685 [details] elf_core_dump stack reduction patch er, try that patch attachment one more time.
Eric, still an issue? Do you want to push as a RH employee now?
Yep looks like it's still an issue... c0191f50 <elf_core_dump>: c0191f50: 55 push %ebp c0191f51: 57 push %edi c0191f52: 56 push %esi c0191f53: 53 push %ebx c0191f54: bb 00 e0 ff ff mov $0xffffe000,%ebx c0191f59: 21 e3 and %esp,%ebx c0191f5b: 81 ec ac 04 00 00 sub $0x4ac,%esp 1196 bytes... ouch. I'll see what people think of fixing this. Maybe I can come up with a non-cxfs testcase ;-)
The problem isn't the stack above, it's what's below - elf_core_dump DUMP_WRITE dump_write file->f_op->write ... and down into whatever stacked IO stuff you may have OTOH 2.4.21 still has 8k to work withg, right, so it's not quite as bad (which is probably why this -was- cleaned up upstream in 2.6) If nobody's hit it in the wild on RHEL3, perhaps it's not worth worrying about at this point.
If this hasn't been an issue for our customers yet, it's probably not worth the change.