Skip to contentSkip to conversation

fix initial rpi_push

PATCH Applied Jan Kiszka 2 participants 2 messages Mar 1, 2008

lore
Share & tools
lore

Jan Kiszka

author
#0 lore raw

PATCH 1/1 fix initial rpi_push

[My favorite again... :->]

The initial rpi_push in xnshadow_start takes place for the caller's CPU, instead of the thread's target CPU.

I haven't fully made up my mind about the practical impact of this bug, I just came across it the hard way (rpi_push worked on uninitialized data) while kicking CPUs out of the set that Xenomai shall support. At least it should cause quite some RPI "confusion" for a while on both involved CPUs.

Jan

---
 ChangeLog             |    5 ++++
 include/nucleus/pod.h |    8 +++----
 ksrc/nucleus/shadow.c |   56 ++++++++++++++++++++++++++------------------------
 3 files changed, 39 insertions(+), 30 deletions(-)
include/nucleus/pod.h +4 -4
Index: b/include/nucleus/pod.h
===================================================================
@@ -313,21 +313,21 @@ static inline void xnpod_finalize_zombie
 
 #define xnpod_idle_p()		xnpod_root_p()
 
-static inline void xnpod_renice_root(int prio)
+static inline void xnpod_renice_root(int cpu, int prio)
 {
 	xnthread_t *rootcb;
 	spl_t s;
 
 	xnlock_get_irqsave(&nklock, s);
-	rootcb = xnpod_current_root();
+	rootcb = &xnpod_sched_slot(cpu)->rootcb;
 	rootcb->cprio = prio;
 	xnpod_schedule_runnable(rootcb, XNPOD_SCHEDLIFO | XNPOD_NOSWITCH);
 	xnlock_put_irqrestore(&nklock, s);
 }
 
-static inline int xnpod_root_priority(void)
+static inline int xnpod_root_priority(int cpu)
 {
-	return xnthread_current_priority(xnpod_current_root());
+	return xnthread_current_priority(&xnpod_sched_slot(cpu)->rootcb);
 }
 
 int xnpod_init(void);
ksrc/nucleus/shadow.c +30 -26

155 lines not on this page · raw message

ChangeLog +5 -0
Index: b/ChangeLog
===================================================================
@@ -2,6 +2,11 @@
 
 	* include/asm-generic/system.h (xnlock_put): Add proper barrier.
 
+	* ksrc/nucleus/shadow.c, include/nucleus/pod.h: Let rpi_push,
+	xnpod_renice_root, and xnpod_root_priority work on specified CPU
+	instead of the current one. Issue rpi_push for the new thread's
+	target CPU in xnshadow_start.
+
 2008-02-15  Gilles Chanteperdrix  <[email protected]>
 
 	* src/skins/posix/thread.c (__wrap_pthread_create): Follow more
Applied
#1 lore raw
Quoted 6 lines · Jan Kiszka

[My favorite again... :->]

The initial rpi_push in xnshadow_start takes place for the caller's CPU, instead of the thread's target CPU.

I haven't fully made up my mind about the practical impact of this bug,

This would leave the kernel spuriously run at a boosted priority level on the source CPU.

Quoted 5 lines

I just came across it the hard way (rpi_push worked on uninitialized data) while kicking CPUs out of the set that Xenomai shall support. At least it should cause quite some RPI "confusion" for a while on both involved CPUs.

Merged, thanks.

Quoted 9 lines

Jan

------------------------------------------------------------------------

_______________________________________________
Xenomai-core mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-core

Signature · 1 line
Philippe.