Re: [Xen-devel] netback Oops then xenwatch stuck in D state

[David Vrabel <david.vrabel@xxxxxxxxxx>]

On 14/02/13 12:29, Wei Liu wrote:
> On Thu, 2013-02-14 at 12:20 +0000, David Vrabel wrote:
>> On 14/02/13 11:48, Jan Beulich wrote:
>>>>>> On 14.02.13 at 12:20, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
>>>
>>>> If this is a bug, and, if my previous patch fixes Christopher's OOPS, he
>>>> will hit this bug soon when shutting down DomU.
>>>
>>> I don't think this patch will fix his problems, which - as described
>>> yesterday - I'm relatively certain result from the harsh action
>>> netbk_fatal_tx_err() does.
>>
>> I can't see anything broken in netbk_fatal_tx_err().
>>
>> However, a call to netbk_fatal_tx_err() may result in the vif's ref
>> count going to 1 which means a simutaneous attempt to shutdown the vif
>> will free the net device.
> 
>> Netback thread              Xenwatch thread
>>
>> netbk_fatal_tx_err()        netback_remove()
>>                               xenvif_disconnect()
>>                                 ...
>>                                 free_netdev()
>> netbk_tx_err() Oops!
>>
> 
> This is not a problem. Reading comments and code of the commit,
> netbk_fatal_tx_err shuts down the vif entirely (at the moment the timer
> is not handled though) which should make sure it will never get
> scheduled again, so in practice it will never hit netbk_tx_err.

Without the fix to the error paths of netbk_count_requests(), then if it
returned 0 netbk_tx_err() may be called.  e.g., if txreq.size < ETH_HLEN.

netbk_fatal_tx_err() should call del_timer_sync() on the credit timer
(vif->credit_timeout) as well, otherwise it may fire and attempt to
reschedule the vif, which will then oops as vif->netbk == NULL.

David

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