All of lore.kernel.org
 help / color / mirror / Atom feed
* [Adeos-main] __ipipe_run_isr vs. domain migration
@ 2009-03-09 17:09 Jan Kiszka
  0 siblings, 0 replies; only message in thread
From: Jan Kiszka @ 2009-03-09 17:09 UTC (permalink / raw)
  To: Philippe Gerum; +Cc: adeos-main

Hi Philippe,

as indicated on xenomai-core, there is at least a theoretical issue with
__ipipe_sync_stage/__ipipe_run_isr and non-root IRQ handlers performing
a domain migration. And it's not only limited to x86 but rather a
cross-arch thing: While __ipipe_run_isr assumes, that the domain stays
the same across a handler call

[e.g. x86-32:]
	__clear_bit(IPIPE_SYNC_FLAG, &ipipe_cpudom_var(ipd, status)); \
	ipd->irqs[irq].handler(irq, ipd->irqs[irq].cookie);	\
	__set_bit(IPIPE_SYNC_FLAG, &ipipe_cpudom_var(ipd, status)); \

i.e. ipd is not updated on return, __ipipe_sync_stage interestingly
reloads the current domain

	__ipipe_run_isr(ipd, irq);
	p = ipipe_cpudom_ptr(ipipe_current_domain);

Is it forbidden for some other reasons to change the domain from within
an IRQ handler or is there a bug sleeping?

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2009-03-09 17:09 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-03-09 17:09 [Adeos-main] __ipipe_run_isr vs. domain migration Jan Kiszka

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.