Module: xenomai-jki
Branch: for-upstream
Commit: 88e0f5dfac865ffabe32b38ab691a29a6948db74
URL:    
http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=88e0f5dfac865ffabe32b38ab691a29a6948db74

Author: Jan Kiszka <jan.kis...@siemens.com>
Date:   Mon Apr 26 17:58:25 2010 +0200

nucleus: Plug race between rpi_clear_remote and rpi_next

Most RPI services work on the current task or the one to be scheduled in
next, thus are naturally serialized. But rpi_next is not as it can walk
the chain of RPI requests for a CPU independently. In that case,
clearing RPI via rpi_clear_remote can race with rpi_next, and if the
former loses after checking thread->rpi for NULL, we will dereference a
NULL pointer in xnsched_pop_rpi().

Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>

---

 ksrc/nucleus/shadow.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
index 872c37f..cf7c08f 100644
--- a/ksrc/nucleus/shadow.c
+++ b/ksrc/nucleus/shadow.c
@@ -332,6 +332,15 @@ static void rpi_clear_remote(struct xnthread *thread)
        xnlock_get_irqsave(&rpi->rpilock, s);
 
        /*
+        * Re-check under lock. Someone may have invoked rpi_next and cleared
+        * rpi by now.
+        */
+       if (unlikely(!rpi_p(thread))) {
+               xnlock_put_irqrestore(&rpi->rpilock, s);
+               return;
+       }
+
+       /*
         * The RPI slot - if present - is always valid, and won't
         * change since the thread is resuming on this CPU and cannot
         * migrate under our feet. We may grab the remote slot lock


_______________________________________________
Xenomai-git mailing list
Xenomai-git@gna.org
https://mail.gna.org/listinfo/xenomai-git

Reply via email to