Module: xenomai-jki Branch: for-upstream Commit: 88e0f5dfac865ffabe32b38ab691a29a6948db74 URL: http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=88e0f5dfac865ffabe32b38ab691a29a6948db74
Author: Jan Kiszka <[email protected]> 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 <[email protected]> --- 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 [email protected] https://mail.gna.org/listinfo/xenomai-git
