Messages in this thread | | | Subject | Re: RT and Cascade interrupts | From | Trond Myklebust <> | Date | Sat, 28 May 2005 15:17:34 -0700 |
| |
lau den 28.05.2005 Klokka 13:48 (-0400) skreiv john cooper: > The other possibility to fix the original problem within > the scope of the RPC code was to replace the bit state of > RPC_TASK_HAS_TIMER with a count so we don't obscure the > fact the timer was requeued during the preemption window. > This happens as rpc_run_timer() does an unconditional > clear_bit(RPC_TASK_HAS_TIMER,..) before returning.
Just to clarify a bit more here. RPC_TASK_HAS_TIMER is definitely _not_ redundantly replicating timer state, as I saw you asserting previously.
There are two distinct cases where timer->base may be NULL. In the first case, the timer is inactive and was never queued so it is entirely pointless to be calling del_timer() & friends. In the second case, the timer was active, but has expired and was picked up by __run_timers(). del_singleshot_timer_sync() fails to distinguish these two cases, and will therefore end up redundantly calling del_timer_sync() every time a task loops through __rpc_execute() without setting a timer. Your patch to remove RPC_TASK_HAS_TIMER will re-introduce that redundant behaviour but will re-introduce precisely the race that del_timer_sync() is designed to fix.
So, I repeat: I want to see a case description that clearly demonstrates a race scenario in the existing code before I'm willing to consider any patches at all.
Cheers, Trond
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |