Re: [Xen-devel] rcu_sched self-detect stall when disable vif device

[David Vrabel <david.vrabel@xxxxxxxxxx>]

On 28/01/15 16:45, Julien Grall wrote:
> On 27/01/15 16:53, Wei Liu wrote:
>> On Tue, Jan 27, 2015 at 04:47:45PM +0000, Julien Grall wrote:
>>> On 27/01/15 16:45, Wei Liu wrote:
>>>> On Tue, Jan 27, 2015 at 04:03:52PM +0000, Julien Grall wrote:
>>>>> Hi,
>>>>>
>>>>> While I'm working on support for 64K page in netfront, I got
>>>>> an rcu_sced self-detect message. It happens when netback is
>>>>> disabling the vif device due to an error.
>>>>>
>>>>> I'm using Linux 3.19-rc5 on seattle (ARM64). Any idea why
>>>>> the processor is stucked in xenvif_rx_queue_purge?
>>>>>
>>>>
>>>> When you try to release a SKB, core network driver need to enter some
>>>> RCU cirital region to clean up. dst_release for one, calls call_rcu.
>>>
>>> But this message shouldn't happen in normal condition or because of
>>> netfront. Right?
>>>
>>
>> Never saw  report like this before, even in the case that netfront is
>> buggy.
> 
> This is only happening when preemption is not enabled (i.e
> CONFIG_PREEMPT_NONE in the config file) in the backend kernel.
> 
> When the vif is disabled, the loop in xenvif_kthread_guest_rx turned
> into an infinite loop. In my case, the code executed looks like:
> 
> 
>  1. for (;;) {
>  2.   xenvif_wait_for_rx_work(queue);
>  3.
>  4.   if (kthread_should_stop())
>  5.         break;
>  6.
>  7.   if (unlikely(vif->disabled && queue->id == 0) {
>  8.           xenvif_carrier_off(vif);
>  9.           xenvif_rx_queue_purge(queue);
> 10.           continue;
> 11.   }
> 12. }
> 
> The wait on line 2 will return directly because the vif is disabled
> (see xenvif_have_rx_work)
> 
> We are on queue 0, so the condition on line 7 is true. Therefore we will
> loop on line 10. And so on...
> 
> On platform where preemption is not enabled, this thread will never
> yield/give the hand to another thread (unless the domain is destroyed).

I'm not sure why we have a continue in the vif->disabled case and not
just a break.  Can you try that?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel