This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix stacksize returned for main process thread whenRLIMIT_STACK is relevant


On Tue, 19 Jun 2012 17:10:08 -0400, KOSAKI wrote:
> And then, one more question is upcoming. Why do you only round up
> pthread_getattr_np() case and don't round up getrlimit(RLIM_STACK)
> case? I'm still not convinced when this rounding up is needed and
> they seems inconsistent. Can you please help me clarify?

I believe you're talking about the inconsistency in the test case? It
is intentional to make sure that the pthread_getattr_np code does not
fumble on unaligned rlimit.

> > Now if the next stacksize returned is a function of rlimit, it
> > could be an unaligned value and hence stackaddr too would be
> > unaligned. If I try to access stackaddr, the kernel rounds *up* to
> > page size and hence results in a request larger than rlimit,
> > resulting in a request violation. 
> 
> Hmmm...
> I haven't caught why do you think this is violation. the spec only
> says if a request is smaller than rlimit, it shouldn't make SEGV. but
> don't say anything about opposition. I think kernel round up is not
> invalid. Which scenario do you worry about?

Request violation == segfault, not spec violation. I guess the rlimit
spec has no other choice than being ambivalent about the case of access
beyond rlimit, since the rlimit_stack check can only be done during a
page fault. In fact the linux kernel only does the stack_rlimit check
during vma extension within the page fault. It might be worthwhile to
add a check in the kernel that does not depend on the vma extension, so
that if the stack rlimit is reduced during runtime, then the kernel
sees it and tries to implement it.

I am ensuring that there is a page fault as well as a vma extension for
my stack top access, so the linux kernel will respond to an access
beyond rlimit with a SIGSEGV. Any other kernel implementation should
also catch an access beyond rlimit_stack here since otherwise it is not
doing an rlimit_stack check at all.

> > To prevent this, pthread_getattr_np must round the stacksize
> > *down* to make it page aligned so that the kernel does not convert
> > our request to something larger than rlimit.
> 
> And, please teach me why we should round down at pthread_getattr_np
> instead of dropping kernel rounding up logic in stack expansion.

Because the kernel align-up logic is necessary to ensure that the user
request gets the amount of memory being requested -- align-down will
return less memory than what was requested. The alternative may be to
make sure that rlimit_stack is always aligned, but I don't see that as a
really useful thing to do.


Regards,
Siddhesh


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]