Trond Myklebust wrote:
Hmmm... With those constraints, it seems difficult to be able to modify
the current rpc_wake_up_task() function...
That is the price of optimisation in this case.
Optimisation against potential race (see below) ?
Your deadlock problem resulted in __rpc_wake_up_task() iterating forever
on the same task since the while() loop would not ever exit before it
was empty. By changing the iteration scheme into one where we only try
to wake up each task once, we allow rpc_wake_up()/rpc_wake_up_status()
to complete.
IMO, the code will still hang because, the list_for_each_entry_safe()
loop will never complete, even with the new scheme. Indeed, the loop
call __rpc_wake_up_task() will try to set RPC_TASK_WAKEUP bit, but it is
already set by rpc_wake_up_task(), so it hangs...
A: run rpc_wake_up_task(task foo)
A: set RPC_TASK_WAKEUP bit
--interrupt--
B: run rpc_wake_up()
B: grab queue->lock
B: enter the list_for_each_entry_safe() loop
B: run __rpc_wake_up_task(task foo)
B: wait for RPC_TASK_WAKEUP bit
A: wait for queue->lock
-> deadlock ?
--
Aurelien Degremont
-
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]
