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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, 2013-02-14 at 12:47 +0000, David Vrabel wrote:
> 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.
> 

Yes returning 0 in error case is wrong. I thought we talked about this
problem on the basis that we fix this one, and the latter timer bug.

> 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.
> 

Yeah, I have patches to fix these bugs, will post them today. :-)


Wei.

> David



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