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? Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core