Jan Kiszka wrote:
> Philippe Gerum wrote:
>> Jan Kiszka wrote:
>>> Philippe Gerum wrote:
>>>> Jan Kiszka wrote:
>>>>> Hi,
>>>>> this looks suspicious to me:
>>>>> static inline void do_taskexit_event(struct task_struct *p)
>>>>> {
>>>>>     ...
>>>>>     if (xnpod_shadow_p())
>>>>>         xnshadow_relax(0);
>>>>> A) The only call context of this hook is do_exit() - and that's Linux
>>>>> kernel code which should always run in secondary mode, no?
>>>> It is a left-over from the days when do_exit() could be called from
>>>> primary context directly on behalf on the shadow unmapping code; now
>>>> we go through an APC, so that should be ok.
>>> Mmm, then I wonder if we shouldn't be able to drop the explicit
>>> xnpod_schedule() from do_taskexit_event() as well: we always enter this
>>> code over the ROOT thread, and xnpod_delete_thread() will only kill a
>>> suspended thread. So there should be no need to reschedule afterwards.
>>> Will post an updated patch.
>> Nak, the deletion hook may alter the scheduling state.
> OK. Is such a hook expected to call xnsched_set_resched in that case,
> ie. can we drop it?

Yes, 2.5 only.

> Jan

Xenomai-core mailing list

Reply via email to