Re: [PATCH] Use malloca instead alloca

[Rich Felker <dalias at aerifal dot cx>]

On Sun, Dec 30, 2012 at 02:18:11PM -0500, KOSAKI Motohiro wrote:
> On Sun, Dec 30, 2012 at 1:45 PM, Rich Felker <dalias@aerifal.cx> wrote:
> > On Sun, Dec 30, 2012 at 12:48:50PM -0500, KOSAKI Motohiro wrote:
> >> >> For platform specific way best solution is to read where bottom of stack is
> >> >> and allocate only when at least say 32768 bytes are left.
> >> >> >
> >> > And when knowing stack boundaries I could also recognize stack pointer
> >> > by single comparison.
> >> >
> >> > It needs to define _STACK_TOP,_STACK_CUP, _STACK_SIZE macros for stack parameters.
> >> > I can find them by pthread_attr_getstack but this call is slow.
> >>
> >> I think this approach has two issues.
> >>
> >> 1) On LInux, RLIMIT_STACK doesn't affect to main thread. so there is
> >> no reliable stack limit detection way. Think mmap vs stack expansion
> >> race case for example.
> >
> > I'm not sure this is correct, or perhaps I don't understand. The
> > entire virtual memory range covered by RLIMIT_STACK is reserved for
> > stack growth, but only the first 128k (this number seems to be
> > hard-coded in the kernel..?) is initially reserved in the
> > commit-charge sense.
> 
> Damn. I wrote incorrect. I'm very sorry. I'd like to try clarify. On
> linux main thread,
> it doesn't reserve RLIMIT_STACK size virtual memory. but automatically expand
> a stack when needed and then makes SEGV if exceed RLIMIT_STACK.
> 
> Then, the trouble is happen when virtual memory is very tight. mmap()
> may allocate
> a virtual memory very near place of ESP and it prevent to expand to
> stack. So, stack
> access can make SEGV even if stack size < RLIMIT_STACK.

Could you provide a citation for this? I'm pretty sure the kernel
ensures this does not happen by never allocating maps in the
RLIMIT_STACK range. On the other hand, I have seen buggy
vendor-patched kernels which would allocate maps in the stack range
even when there is no memory pressure.

Rich