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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]