From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Xenomai <xenomai@xenomai.org>
Subject: Re: [Xenomai] [CRITICAL PATCH] ipipe: Re-read domain context after IRQ processing
Date: Fri, 10 May 2013 17:27:19 +0200 [thread overview]
Message-ID: <518D11D7.4040409@xenomai.org> (raw)
In-Reply-To: <50F96C89.8010004@siemens.com>
On 01/18/2013 04:38 PM, Jan Kiszka wrote:
> This fixes a nasty bug on SMP boxes: We may migrate to root in the
> context of an IRQ handler, and then also to a different CPU. Therefore,
> we must not use domain contexts read before the invocation but update
> them afterward or use stable information like the domain reference.
>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
>
> We are still facing stalled, unkillable RT processes despite this fix,
> but at least the head domain status corruption (and related warnings)
> seems to be gone now.
>
> kernel/ipipe/core.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/ipipe/core.c b/kernel/ipipe/core.c
> index 68af0b3..6aa9572 100644
> --- a/kernel/ipipe/core.c
> +++ b/kernel/ipipe/core.c
> @@ -1173,18 +1173,19 @@ static void dispatch_irq_head(unsigned int irq) /* hw interrupts off */
> head->irqs[irq].handler(irq, head->irqs[irq].cookie);
> __ipipe_run_irqtail(irq);
> hard_local_irq_disable();
> + p = ipipe_this_cpu_head_context();
> __clear_bit(IPIPE_STALL_FLAG, &p->status);
>
> /* Are we still running in the head domain? */
> if (likely(__ipipe_current_context == p)) {
> /* Did we enter this code over the head domain? */
> - if (old == p) {
> + if (old->domain == head) {
> /* Yes, do immediate synchronization. */
> if (__ipipe_ipending_p(p))
> __ipipe_sync_stage();
> return;
> }
> - __ipipe_set_current_context(old);
> + __ipipe_set_current_context(ipipe_this_cpu_root_context());
> }
>
> /*
Hi Jan,
I may have an issue reported which resembles the problem fixed by this
patch. If I understand your patch, it means that an irq handler may
migrate domain. But if I read __ipipe_sync_stage() code:
void __ipipe_do_sync_stage(void)
{
struct ipipe_percpu_domain_data *p;
struct ipipe_domain *ipd;
int irq;
p = __ipipe_current_context;
ipd = p->domain;
__set_bit(IPIPE_STALL_FLAG, &p->status);
smp_wmb();
if (ipd == ipipe_root_domain)
trace_hardirqs_off();
for (;;) {
irq = __ipipe_next_irq(p);
if (irq < 0)
break;
/*
* Make sure the compiler does not reorder wrongly, so
* that all updates to maps are done before the
* handler gets called.
*/
barrier();
if (test_bit(IPIPE_LOCK_FLAG, &ipd->irqs[irq].control))
continue;
if (ipd != ipipe_head_domain)
hard_local_irq_enable();
if (likely(ipd != ipipe_root_domain)) {
ipd->irqs[irq].handler(irq, ipd->irqs[irq].cookie);
__ipipe_run_irqtail(irq);
hard_local_irq_disable();
} else if (ipipe_virtual_irq_p(irq)) {
irq_enter();
ipd->irqs[irq].handler(irq, ipd->irqs[irq].cookie);
irq_exit();
root_stall_after_handler();
hard_local_irq_disable();
while (__ipipe_check_root_resched())
__ipipe_preempt_schedule_irq();
} else {
ipd->irqs[irq].handler(irq, ipd->irqs[irq].cookie);
root_stall_after_handler();
hard_local_irq_disable();
}
p = __ipipe_current_context;
}
if (ipd == ipipe_root_domain)
trace_hardirqs_on();
__clear_bit(IPIPE_STALL_FLAG, &p->status);
}
It seems to me that at the end of each loop, we re-read p, but we assume
that p->domain did not change. So I would add:
ipd = p->domain
right after the line
p = __ipipe_current_context
But I am not sure that we are supposed to allow irq handlers to migrate
domains.
Regards.
--
Gilles.
next prev parent reply other threads:[~2013-05-10 15:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-18 15:38 [Xenomai] [CRITICAL PATCH] ipipe: Re-read domain context after IRQ processing Jan Kiszka
2013-01-18 16:37 ` Philippe Gerum
2013-01-18 17:04 ` Jan Kiszka
2013-01-18 19:04 ` Jan Kiszka
2013-01-18 20:09 ` Jan Kiszka
2013-01-21 11:30 ` Jan Kiszka
2013-01-21 11:57 ` Gilles Chanteperdrix
2013-05-10 15:27 ` Gilles Chanteperdrix [this message]
2013-05-10 15:44 ` Gilles Chanteperdrix
2013-05-10 16:22 ` Jan Kiszka
2013-05-10 16:34 ` Gilles Chanteperdrix
2013-05-11 14:53 ` Philippe Gerum
2013-05-11 15:24 ` Gilles Chanteperdrix
2013-05-11 15:28 ` Philippe Gerum
2013-05-11 16:32 ` Gilles Chanteperdrix
2013-05-13 6:38 ` Jan Kiszka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=518D11D7.4040409@xenomai.org \
--to=gilles.chanteperdrix@xenomai.org \
--cc=jan.kiszka@siemens.com \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.