On Fri, Apr 17, 2015 at 08:34:00PM +0200, Jan Kiszka wrote:
> 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.
As in xenomai 2.x, I would suggest the maximum of __WORDSIZE * 1024
and PTHREAD_STACK_MIN as a default stack size.
I think the idea of adding pagesize to PTHREAD_STACK_MIN comes from
the implementation of signals which were pulling siginfo structs
from kernel after each syscall. Since this thing is long gone (even
in xenomai 2.6 I believe), we have no reason to try and enforce
another minimum than POSIX.
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
