Re: [Xenomai-core] Overcoming the "foreign" stack

[Jan Kiszka <jan.kiszka@domain.hid>]

Am 05.10.2010 15:42, Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Am 05.10.2010 15:15, Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Hi,
>>>>
>>>> quite a few limitations and complications of using Linux services over
>>>> non-Linux domains relate to potentially invalid "current" and
>>>> "thread_info". The non-Linux domain could maintain their own kernel
>>>> stacks while Linux tend to derive current and thread_info from the stack
>>>> pointer. This is not an issue anymore on x86-64 (both states are stored
>>>> in per-cpu variables) but other archs (e.g. x86-32 or ARM) still use the
>>>> stack and may continue to do so.
>>>>
>>>> I just looked into this thing again as I'm evaluating ways to exploit
>>>> the kernel's tracing framework also under Xenomai. Unfortunately, it
>>>> does a lot of fiddling with preempt_count and need_resched, so patching
>>>> it for Xenomai use would become a maintenance nightmare.
>>>>
>>>> An alternative, also for other use cases like kgdb and probably perf, is
>>>> to get rid of our dependency on home-grown stacks. I think we are on
>>>> that way already as in-kernel skins have been deprecated. The only
>>>> remaining user after them will be RTDM driver tasks. But I think those
>>>> could simply become in-kernel shadows of kthreads which would bind their
>>>> stacks to what Linux provides. Moreover, Xenomai could start updating
>>>> "current" and "thread_info" on context switches (unless this already
>>>> happens implicitly). That would give us proper contexts for system-level
>>>> tracing and profiling.
>>>>
>>>> My key question is currently if and how much of this could be realized
>>>> in 2.6. Could we drop in-kernel skins in that version? If not, what
>>>> about disabling them by default, converting RTDM tasks to a
>>>> kthread-based approach, and enabling tracing etc. only in that case?
>>>> However, this might be a bit fragile unless we can establish
>>>> compile-time or run-time requirements negotiation between Adeos and its
>>>> users (Xenomai) about the stack model.
>>> A stupid question: why not make things the other way around: patch the
>>> current and current_thread_info functions to be made I-pipe aware and
>>> use an "ipipe_current" pointer to the current thread task_struct. Of
>>> course, there are places where the current or current_thread_info macros
>>> are implemented in assembly, so it may be not simple as it sounds, but
>>> it would allow to keep 128 Kb stacks if we want. This also means that we
>>> would have to put a task_struct at the bottom of every Xenomai task.
>>
>> First of all, overhead vs. maintenance. Either every access to
>> preempt_count() would require a check for the current domain and its
>> foreign stack flag, or I would have to patch dozens (if that is enough)
>> of code sites in the tracer framework.
> 
> No. I mean we would dereference a pointer named ipipe_current. That is
> all, no other check. This pointer would be maintained elsewhere. And we
> modify the "current" macro, like:
> 
> #ifdef CONFIG_IPIPE
> extern struct task_struct *ipipe_current;
> #define current ipipe_current
> #endif
> 
> Any calll site gets modified automatically. Or current_thread_info, if
> it is current_thread_info which is obtained using the stack pointer mask
> trick.

The stack pointer mask trick only works with fixed-sized stacks, not a
guaranteed property of in-kernel Xenomai threads.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux