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

[KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>]

On Tue, Jun 19, 2012 at 9:52 PM, Siddhesh Poyarekar <siddhesh@redhat.com> wrote:
> 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.

OK. I understand. I agree little inconsistency is no big matter. So, I
clearly believe your patch is correct. thank you.

To me, I like setrlimit(RLIM_STACK) round up to pagesize for consistency.
but even if kernel folks agree me, your round down logic is necessary when
running on old kernel. So, I'd like to discuss this issue on lkml. but this is
clearly unrelated to glibc.

thanks again.




>
>> > 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.