Re: RT and Cascade interrupts

[Trond Myklebust <trond.myklebust@fys.uio.no>]

su den 29.05.2005 Klokka 15:31 (+0400) skreiv Oleg Nesterov:
> __rpc_execute() calls ->tk_exit and goes to 'restarted' label.
> What if ->tk_exit calls rpc_sleep_on() ? If it is possible, we
> have a race.
> 
> CPU_0 (main loop in rpc_execute restarted)		CPU_1
> 
> rpc_delete_timer:
> 	if (RPC_IS_QUEUED())	// YES
> 		return;
> 							rpc_run_timer:
> 								rpc_wake_up_task:
> 									clear_bit(RPC_TASK_QUEUED)
> 								preemption, or long interrupt
> 
> if (!RPC_IS_QUEUED())		// YES
> 	task->tk_action()
> 		__rpc_add_timer:
> 			set_bit(RPC_TASK_HAS_TIMER)
> 			mod_timer();
> 								clear_bit(RPC_TASK_HAS_TIMER)
> 
> Now we have pending timer without RPC_TASK_HAS_TIMER bit set.

It is possible, but it should be _extremely_ rare. The only cases where
tk_exit() sets a timer are the cases where we call rpc_delay(). In the
existing cases in the kernel, that would be setting timers of 5 seconds
(for the case of JUKEBOX errors) or longer.

These tx_exit()+restart events are very rare in themselves (JUKEBOX
errors only occur if the server needs to do something with a long
latency - such as retrieving a file from an HSM unit), but for that to
coincide with a preemption or interrupt of > 5 seconds inside
__rpc_execute... I'd hate to see those RPC performance figures.

> Is this patch makes any sense?

Yes. I agree the scenario is theoretically possible (so I can queue that
patch up for you). I am not convinced it is a plausible explanation for
what John claims to be seeing, though.

Cheers,
  Trond