Gilles Chanteperdrix wrote:
> On Fri, Feb 1, 2008 at 11:10 AM, Philippe Gerum <[EMAIL PROTECTED]> wrote:
>> Gilles Chanteperdrix wrote:
>> > Gilles Chanteperdrix wrote:
>> > >
>> > > Hi Philippe,
>> > >
>> > > here comes a new patch on the theme "reworking self deletion". This
>> > > time, execution of nkpod delete hooks is made before the context switch
>> > > whereas finalizing the thread takes place after the context
>> > > switch. Special care has been taken to call xnfreesync before we run
>> > > hooks, in order to avoid freeing the thread control block before the
>> > > finalization, and xnheap_t::idleq was made a per-cpu thing for the same
>> > > purpose.
>> > >
>> > > I made a simple watchdog test with all debugs enabled, and
>> > > xnshadow_unmap did not complain.
>> > >
>> > > If you are OK with this patch, I will rebase the unlocked context
>> > > patch on it.
>> > Thinking a bit more about the unlocked context switch case: do we
>> > tolerate that an ISR may delete a thread that is not current ? Because
>> > if an ISR deleted a non current thread, we would not run the hooks over
>> > the deleted thread context, so we would be again in the case where
>> > xnshadow_unmap is not run by current. Besides, at first sight, it seems
>> > to simplify greatly the case of the unlocked context switch.
>> No we don't; thread deletion is normally a service callable from thread
>> context only. We allow the watchdog code to call into
>> xnpod_delete_thread() as an exception, because we have no other mean to
>> fix the runaway situation properly, and we know that this will work
>> precisely because the deleted thread is current.
>> Any other situation would lockup, because the termination signal would
>> never make it to the runaway thread since Linux is starved from CPU at
>> that point, and we can't even relax the thread either. So, yes, we may
>> safely assume that thread deletion is either called from a thread, or
>> called on behalf of an ISR for the preempted thread only (and solely for
>> internal code and well-know situations).
> Unfortunately, my reasoning was UP only, in SMP, it may happen that a
> distant CPU deletes from a valid context the thread being currently
> switched out with nklock unlocked on current CPU. So, we have to take
> care about this case anyway.
IIUC, this should only be a problem with kernel threads, others would
end up self-deleting on behalf of a termination signal from the remote CPU.
Xenomai-core mailing list