Re: [PATCH 2/3] smp/ipi:Clarify ambiguous comments around deadlock scenarios in smp_call_function variants.

[Preeti U Murthy <preeti@linux.vnet.ibm.com>]

Hi Wang,

On 07/06/2013 11:42 AM, Wang YanQing wrote:
> On Fri, Jul 05, 2013 at 09:57:11PM +0530, Preeti U Murthy wrote:
>> Elaborate on when deadlocks can occur when a call is made to
>> smp_call_function_single() and its friends. This avoids ambiguity about
>> when to use these calls.
>>
>> +	 * 2. wait = 0: This function could be called from an interrupt
>> +	 * context, and can get blocked on the csd_lock(csd) below in
>> +	 * "non wait cases".
>> +	 * This is because the percpu copy of csd of this_cpu is used
>> +	 * in non wait cases. Under such circumstances, if the previous caller
>> +	 * of this function who got preempted by this interrupt has already taken
>> +	 * the lock under non wait condition, it will result in deadlock.
>> +	 *
> 
> No, it will not cause deadlock, it is not mutex lock,  it is busy wait, so
> when the CSD_FLAG_LOCK be cleared, the code will go on running.

A deadlock might not result, but a potential long wait in an interrupt
context could result if the source cpu got preempted by an interrupt
between  csd_lock(csd) and generic_exec_single(), where it actually
sends an ipi to the target cpu.

Under such a scenario, if no other cpu has sent a smp_call_function ipi
to it, it will not check its queue till such an ipi is sent, as a result
of which the target will not release the csd on which the source cpu is
waiting.

Hence, on the source cpu,the interrupt handler will have to wait till
then. It would be good therefore to issue a warning under this circumstance.
Maybe we can modify the changelog to reflect this scenario.

> 
> After stare into the kernel/smp.c, I can't catch what the exactly meaning
> of the "DeadLock" in the original comment also.
> 
> I hope someone can clarify it.
> 
> Thanks.
> 

Regards
Preeti U Murthy