On 26/03/07, Jan Kiszka <[EMAIL PROTECTED]> wrote:
Gilles Chanteperdrix wrote: > Hi, > > I am porting a network driver from Linux to RTnet, and I have a sudden > doubt about what I am doing: is it safe to call a function like > wake_up_interruptible, from a non real-time context, with CONFIG_PREEMPT > enabled, while holding an rthal spinlock ? Do not I risk a rescheduling > with the spinlock locked ? Mmh, doesn't stalling the primary domain (what rthal_spin_lock_irqsave surely does) also make the root domain think it is running in interrupt context, thus will prevent any Linux reschedule?
I don't know the PREEMPT_RT code. Although, I do remember I asked Philippe once and the subject was some code in nucleus/pipe.c Just read the comments on PREEMPT_RT in xnpipe_wakeup_proc()... Philippe may comment more on that. However, there is one big fat issue with this approach:
wake_up_interruptible takes some Linux spin lock. So you must never call it from primary context on UP to avoid corruption. And an SMP, you create a nice source for priority inversion: CPU2 holds wait_queue lock, gets preempted by Xenomai and runs some longer low-prio RT job. Meanwhile CPU1 tries to acquire wait_queue as well with IRQs disabled, blocking any RT task on that CPU.
Jan, Gilles is talking about calling this function from non-rt context :o) "...is it safe to call a function like wake_up_interruptible, from a *non real-time* context, with CONFIG_PREEMPT" And for calling it from the real-time context, It's not only about a spinlock but a list (of pending tasks) as well and, in general, any data this routine may access and which can be /inconsistent/ at the moment. So it's a no go. Better defer the Linux wake-up via a rtdm_nrtsig. Alternatively, make
the Linux waiter also a Xenomai task and use a rtdm_event e.g. (mmh, maybe we should discuss the auto-shadow-any-Linux-task-on-demand feature for Xenomai once again...). Jan _______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core
-- Best regards, Dmitry Adamushko
_______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core