Re: [Xenomai] Dealing with too small thread stacks

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2015-04-17 20:30, Gilles Chanteperdrix wrote:
> On Fri, Apr 17, 2015 at 08:26:32PM +0200, Jan Kiszka wrote:
>> On 2015-04-17 20:24, Gilles Chanteperdrix wrote:
>>> On Fri, Apr 17, 2015 at 08:17:26PM +0200, Jan Kiszka wrote:
>>>> On 2015-04-17 20:12, Gilles Chanteperdrix wrote:
>>>>> On Fri, Apr 17, 2015 at 08:10:40PM +0200, Jan Kiszka wrote:
>>>>>> On 2015-04-17 20:08, Gilles Chanteperdrix wrote:
>>>>>>> On Fri, Apr 17, 2015 at 08:05:57PM +0200, Jan Kiszka wrote:
>>>>>>>> On 2015-04-17 19:50, Gilles Chanteperdrix wrote:
>>>>>>>>> On Fri, Apr 17, 2015 at 07:34:30PM +0200, Jan Kiszka wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> analyzing page faults of an application that prefers to set its own
>>>>>>>>>> stacks, I noticed a problem in Xenomai (2 and 3), at least from the
>>>>>>>>>> usability POV: We document the minimum stack stack as PTHREAD_STACK_MIN
>>>>>>>>>> + 1 page, at least in Xenomai 3, and we enforce that on thread creation.
>>>>>>>>>> However, enforcement is doomed to fail if the stack is preallocated (and
>>>>>>>>>> that too small).
>>>>>>>>>>
>>>>>>>>>> As we cannot detect if the user set a stack address in pthread_attr_t, I
>>>>>>>>>> would suggest to fail thread creation instead of performing it with
>>>>>>>>>> improper parameters. Other suggestions? If not, I would prepare a patch
>>>>>>>>>> for Xenomai 3 (for 2 only if desired).
>>>>>>>>>
>>>>>>>>> It seems to me we can detect the parameters in the pthread_attr_t
>>>>>>>>> using pthread_attr_getstack. So, we can get __wrap_pthread_create to
>>>>>>>>> fail if the size is not sufficient.
>>>>>>>>
>>>>>>>> Nope, unfortunately not:
>>>>>>>>
>>>>>>>> "If the pthread_attr_getstack() function is called before the stackaddr
>>>>>>>> attribute has been set, the behavior is unspecified."
>>>>>>>
>>>>>>> It is unspecified by POSIX, but Xenomai supports only two
>>>>>>> implementations, glibc and uClibc, so, we can look at what these two
>>>>>>> libraries do. I would bet they return you a NULL stack pointer or
>>>>>>> something.
>>>>>>
>>>>>> I would have expected that, too, but the results for glibc seem random.
>>>>>> Plus there is the risk that something changes, thus we become
>>>>>> version-dependent.
>>>>>
>>>>> Ok then, what about the influence of pthread_attr_setstack() on
>>>>> pthread_attr_getstacksize(), maybe more luck there?
>>>>
>>>> setstack defines the size getstacksize returns. So does setstacksize.
>>>>
>>>> What happens during setstacksize is apparently that the address is set
>>>> to NULL - size. But, again, that is just the current glibc behaviour.
>>>
>>> Yes, ok, but in order to test the stack size passed by the user, it
>>> simply means we can use getstacksize and bail out if not sufficient.
>>
>> Sure, that would be the best way.
>>
>> Along that, I would recommend raising the minimum to 2*PTHREAD_STACK_MIN.
> 
> What for ? We know that the system crashes if the stack is too
> small, but that is the consequence of the user choice, there is not
> much we can do about it. What I would concentrate on, and I think we
> had that on xenomai 2.x is to have a reasonable default stack size.
> Actually, we could wrap pthread_attr_init to define our own default
> and be done with it.
> 

The current minimum PTHREAD_STACK_MIN + PAGE doesn't work reliably (see
my other posting). Thus we can either give up on checking the minimum
completely (much simpler) or raise it to a value that has at least an
effect.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux