Re: [Xen-devel] Netback vif reference count mismatching in latest 3.11 kernels

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, Nov 27, 2013 at 03:17:20PM +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: xen-devel-bounces@xxxxxxxxxxxxx [mailto:xen-devel-
> > bounces@xxxxxxxxxxxxx] On Behalf Of Wei Liu
> > Sent: 27 November 2013 14:41
> > To: Tomasz Wroblewski
> > Cc: xen-devel; Paul Durrant; Wei Liu; David Vrabel
> > Subject: Re: [Xen-devel] Netback vif reference count mismatching in latest
> > 3.11 kernels
> > 
> > On Wed, Nov 27, 2013 at 03:07:09PM +0100, Tomasz Wroblewski wrote:
> > > Hi,
> > >
> > > After update of our network backend vm kernel to 3.11.9 I'm seeing
> > > trouble with netback vif close which seem related to the recent
> > > changes which separated vif disconnect and free; It seems that now
> > > multiple disconnect/connect cycles can happen without freeing and
> > > reallocing the netdev in the processes, which confuses the vif
> > > refcount.
> > >
> > > vif refcount is initialized to 1 in xenvif_alloc. Then first
> > > xenvif_disconnect brings it back to 0, instead of 1 which would seem
> > > more reasonable (since its initialized to 1 in xenvif_alloc i would
> > > expect it to not be dropped to 0 until xenvif_free). Second
> > > xenvif_disconnect brings it to -1 and hangs. For us (xenclient XT)
> > > this happens when we hibernate linux guest, since linux hibernate is
> > > a complex beast which transitions the drivers to between
> > > close/connected states multiple times (i.e. first it suspends/closes
> > > the drivers to take memory snapshot, then resumes/reconnects the
> > > drivers to the actual writing of hibernate image to disk, then
> > > finally it closes them again to shutdown the system)
> > >
> > 
> > Can you illustrate a graph of the whole process? I'm not very clear of
> > the whole cycle.
> > 
> > There's a xenvif_get in xenvif_connect, which increases refcnt by 1,
> > that should corresponds to the atomic_dec in xenvif_disconnect, right?
> > 
> 
> ISTR this happening with some frontends that did not drive the state model 
> entirely correctly. Commit ea732dff5cfa10789007bf4a5b935388a0bb2a8f (Handle 
> backend state transitions in a more robust way ) should fix this.
> 

FWIW 3.11.9 already has that patch.

Wei.

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