* [Xenomai-core] [RFC][PATCH] nucleus: Prevent rescheduling while in xntbase_tick
@ 2011-06-17 9:27 Jan Kiszka
2011-06-17 10:58 ` Gilles Chanteperdrix
0 siblings, 1 reply; 6+ messages in thread
From: Jan Kiszka @ 2011-06-17 9:27 UTC (permalink / raw)
To: Xenomai core
Based on code inspection, it looks like a timer handler triggering a
reschedule in the path xntbase_tick -> xntimer_tick_aperiodic /
xntimer_tick_periodic_inner -> handler can cause problems, e.g. a
reschedule before all expired timers were processed. The timer core is
usually run atomically from an interrupt handler, so better emulate an
IRQ context inside xntbase_tick by setting XNINIRQ.
This patch only affects users of xntbase_tick, ie. psos, vrtx and the
vxworks skin.
Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
---
If my analysis is correct, this is also 2.5 material.
ksrc/nucleus/timebase.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/ksrc/nucleus/timebase.c b/ksrc/nucleus/timebase.c
index 6f7c02f..8f9af04 100644
--- a/ksrc/nucleus/timebase.c
+++ b/ksrc/nucleus/timebase.c
@@ -477,12 +477,16 @@ EXPORT_SYMBOL_GPL(xntbase_stop);
void xntbase_tick(xntbase_t *base)
{
+ struct xnsched_t *sched;
spl_t s;
xnlock_get_irqsave(&nklock, s);
trace_mark(xn_nucleus, tbase_tick, "base %s", base->name);
+ ++sched->inesting;
+ __setbits(sched->lflags, XNINIRQ);
+
if (base == &nktbase)
xntimer_tick_aperiodic();
else {
@@ -490,6 +494,11 @@ void xntbase_tick(xntbase_t *base)
xntimer_tick_periodic_inner(slave);
}
+ if (--sched->inesting == 0) {
+ __clrbits(sched->lflags, XNINIRQ);
+ xnpod_schedule();
+ }
+
xnlock_put_irqrestore(&nklock, s);
}
EXPORT_SYMBOL_GPL(xntbase_tick);
--
1.7.1
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [Xenomai-core] [RFC][PATCH] nucleus: Prevent rescheduling while in xntbase_tick
2011-06-17 9:27 [Xenomai-core] [RFC][PATCH] nucleus: Prevent rescheduling while in xntbase_tick Jan Kiszka
@ 2011-06-17 10:58 ` Gilles Chanteperdrix
2011-06-17 11:03 ` Jan Kiszka
0 siblings, 1 reply; 6+ messages in thread
From: Gilles Chanteperdrix @ 2011-06-17 10:58 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Xenomai core
On 06/17/2011 11:27 AM, Jan Kiszka wrote:
> Based on code inspection, it looks like a timer handler triggering a
> reschedule in the path xntbase_tick -> xntimer_tick_aperiodic /
> xntimer_tick_periodic_inner -> handler can cause problems, e.g. a
> reschedule before all expired timers were processed. The timer core is
> usually run atomically from an interrupt handler, so better emulate an
> IRQ context inside xntbase_tick by setting XNINIRQ.
I do not understand this one either: if we are inside
xntimer_tick_aperiodic, XNINIRQ is already set.
--
Gilles.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Xenomai-core] [RFC][PATCH] nucleus: Prevent rescheduling while in xntbase_tick
2011-06-17 10:58 ` Gilles Chanteperdrix
@ 2011-06-17 11:03 ` Jan Kiszka
2011-06-17 11:58 ` Philippe Gerum
0 siblings, 1 reply; 6+ messages in thread
From: Jan Kiszka @ 2011-06-17 11:03 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Xenomai core
On 2011-06-17 12:58, Gilles Chanteperdrix wrote:
> On 06/17/2011 11:27 AM, Jan Kiszka wrote:
>> Based on code inspection, it looks like a timer handler triggering a
>> reschedule in the path xntbase_tick -> xntimer_tick_aperiodic /
>> xntimer_tick_periodic_inner -> handler can cause problems, e.g. a
>> reschedule before all expired timers were processed. The timer core is
>> usually run atomically from an interrupt handler, so better emulate an
>> IRQ context inside xntbase_tick by setting XNINIRQ.
>
> I do not understand this one either: if we are inside
> xntimer_tick_aperiodic, XNINIRQ is already set.
Not if you come via xntbase_tick, called by the mentioned skins also
outside a timer IRQ (at least based on my understanding of that skin
APIs). But I might be wrong, I just came across this while checking for
potentially invalid cached xnpod_current_sched values.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-core] [RFC][PATCH] nucleus: Prevent rescheduling while in xntbase_tick
2011-06-17 11:03 ` Jan Kiszka
@ 2011-06-17 11:58 ` Philippe Gerum
2011-06-17 12:11 ` Jan Kiszka
0 siblings, 1 reply; 6+ messages in thread
From: Philippe Gerum @ 2011-06-17 11:58 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Xenomai core
On Fri, 2011-06-17 at 13:03 +0200, Jan Kiszka wrote:
> On 2011-06-17 12:58, Gilles Chanteperdrix wrote:
> > On 06/17/2011 11:27 AM, Jan Kiszka wrote:
> >> Based on code inspection, it looks like a timer handler triggering a
> >> reschedule in the path xntbase_tick -> xntimer_tick_aperiodic /
> >> xntimer_tick_periodic_inner -> handler can cause problems, e.g. a
> >> reschedule before all expired timers were processed. The timer core is
> >> usually run atomically from an interrupt handler, so better emulate an
> >> IRQ context inside xntbase_tick by setting XNINIRQ.
> >
> > I do not understand this one either: if we are inside
> > xntimer_tick_aperiodic, XNINIRQ is already set.
>
> Not if you come via xntbase_tick, called by the mentioned skins also
> outside a timer IRQ (at least based on my understanding of that skin
> APIs). But I might be wrong, I just came across this while checking for
> potentially invalid cached xnpod_current_sched values.
That is ok, ui_timer(), tickAnnounce() and tm_tick() are designed by the
respective RTOS to be called from IRQ context.
>
> Jan
>
--
Philippe.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-core] [RFC][PATCH] nucleus: Prevent rescheduling while in xntbase_tick
2011-06-17 11:58 ` Philippe Gerum
@ 2011-06-17 12:11 ` Jan Kiszka
2011-06-17 12:12 ` Philippe Gerum
0 siblings, 1 reply; 6+ messages in thread
From: Jan Kiszka @ 2011-06-17 12:11 UTC (permalink / raw)
To: Philippe Gerum; +Cc: Xenomai core
On 2011-06-17 13:58, Philippe Gerum wrote:
> On Fri, 2011-06-17 at 13:03 +0200, Jan Kiszka wrote:
>> On 2011-06-17 12:58, Gilles Chanteperdrix wrote:
>>> On 06/17/2011 11:27 AM, Jan Kiszka wrote:
>>>> Based on code inspection, it looks like a timer handler triggering a
>>>> reschedule in the path xntbase_tick -> xntimer_tick_aperiodic /
>>>> xntimer_tick_periodic_inner -> handler can cause problems, e.g. a
>>>> reschedule before all expired timers were processed. The timer core is
>>>> usually run atomically from an interrupt handler, so better emulate an
>>>> IRQ context inside xntbase_tick by setting XNINIRQ.
>>>
>>> I do not understand this one either: if we are inside
>>> xntimer_tick_aperiodic, XNINIRQ is already set.
>>
>> Not if you come via xntbase_tick, called by the mentioned skins also
>> outside a timer IRQ (at least based on my understanding of that skin
>> APIs). But I might be wrong, I just came across this while checking for
>> potentially invalid cached xnpod_current_sched values.
>
> That is ok, ui_timer(), tickAnnounce() and tm_tick() are designed by the
> respective RTOS to be called from IRQ context.
Fine. Should we add a XENO_ASSERT to set this in stone and for
documentation purposes?
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-core] [RFC][PATCH] nucleus: Prevent rescheduling while in xntbase_tick
2011-06-17 12:11 ` Jan Kiszka
@ 2011-06-17 12:12 ` Philippe Gerum
0 siblings, 0 replies; 6+ messages in thread
From: Philippe Gerum @ 2011-06-17 12:12 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Xenomai core
On Fri, 2011-06-17 at 14:11 +0200, Jan Kiszka wrote:
> On 2011-06-17 13:58, Philippe Gerum wrote:
> > On Fri, 2011-06-17 at 13:03 +0200, Jan Kiszka wrote:
> >> On 2011-06-17 12:58, Gilles Chanteperdrix wrote:
> >>> On 06/17/2011 11:27 AM, Jan Kiszka wrote:
> >>>> Based on code inspection, it looks like a timer handler triggering a
> >>>> reschedule in the path xntbase_tick -> xntimer_tick_aperiodic /
> >>>> xntimer_tick_periodic_inner -> handler can cause problems, e.g. a
> >>>> reschedule before all expired timers were processed. The timer core is
> >>>> usually run atomically from an interrupt handler, so better emulate an
> >>>> IRQ context inside xntbase_tick by setting XNINIRQ.
> >>>
> >>> I do not understand this one either: if we are inside
> >>> xntimer_tick_aperiodic, XNINIRQ is already set.
> >>
> >> Not if you come via xntbase_tick, called by the mentioned skins also
> >> outside a timer IRQ (at least based on my understanding of that skin
> >> APIs). But I might be wrong, I just came across this while checking for
> >> potentially invalid cached xnpod_current_sched values.
> >
> > That is ok, ui_timer(), tickAnnounce() and tm_tick() are designed by the
> > respective RTOS to be called from IRQ context.
>
> Fine. Should we add a XENO_ASSERT to set this in stone and for
> documentation purposes?
I think so.
>
> Jan
>
--
Philippe.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-06-17 12:12 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-06-17 9:27 [Xenomai-core] [RFC][PATCH] nucleus: Prevent rescheduling while in xntbase_tick Jan Kiszka
2011-06-17 10:58 ` Gilles Chanteperdrix
2011-06-17 11:03 ` Jan Kiszka
2011-06-17 11:58 ` Philippe Gerum
2011-06-17 12:11 ` Jan Kiszka
2011-06-17 12:12 ` Philippe Gerum
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.