Re: [Xenomai-core] [PULL] native: Fix msendq fastlock leakage

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 05/25/2011 01:20 PM, Jan Kiszka wrote:
> On 2011-05-24 16:03, Gilles Chanteperdrix wrote:
>> On 05/24/2011 03:52 PM, Jan Kiszka wrote:
>>> On 2011-05-24 14:30, Gilles Chanteperdrix wrote:
>>>>>>>>> Do you already have an idea how to get that info to the delete hook
>>>>>>>>> function?
>>>>>>>>
>>>>>>>> Yes. We start by not applying the list reversal patch, then the sys_ppd
>>>>>>>> is the first in the list. So, we can, in the function ppd_remove_mm,
>>>>>>>> start by removing all the others ppd, then remove the sys ppd (that is
>>>>>>>> the first), last. This changes a few signatures in the core code, a lot
>>>>>>>> of things in the skin code, but that would be for the better...
>>>>>>>
>>>>>>> I still don't see how this affects the order we use in
>>>>>>> do_taskexit_event, the one that prevents xnsys_get_ppd usage even when
>>>>>>> the mm is still present.
>>>>>>
>>>>>> The idea is to change the cleanup routines not to call xnsys_get_ppd.
>>>>>
>>>>> ...and use what instead? Sorry, I'm slow today.
>>>>
>>>> The sys_ppd passed as other argument to the cleanup function.
>>>
>>> That would affect all thread hooks, not only the one for deletion. And
>>> it would pull in more shadow-specific bits into the pod.
>>>
>>> Moreover, I think we would still be in troubles as mm, thus ppd,
>>> deletion takes place before last task deletion, thus taskexit hook
>>> invocation. That's due to the cleanup ordering in the kernel's do_exit.
>>>
>>> However, if you have a patch, I'd be happy to test and rework my leakage
>>> fix.
>>
>> I will work on this ASAP.
> 
> Sorry for pushing, but I need to decide if we should role out my
> imperfect fix or if there is chance to use some upstream version
> directly. Were you able to look into this, or will this likely take a
> bit more time?

I intended to try and do this next week-end. If it is more urgent than
that, I can try in one or two days. In any case, I do not think we
should try and workaround the current code, it is way to fragile.

-- 
					    Gilles.