WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] On netfront accelerator add/remove watches

To: BVK Chaitanya <bayapuneni_chaitanya@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] On netfront accelerator add/remove watches
From: Neil Turton <nturton@xxxxxxxxxxxxxx>
Date: Tue, 29 Jul 2008 12:09:04 +0100
Cc: Xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 29 Jul 2008 04:10:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <488E8F39.4020406@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <488E8F39.4020406@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.0 (X11/20070326)
Hi,

BVK Chaitanya wrote:
> I see that netfront_accel_add_watch and netfront_accel_remove_watch 
> functions are _not_ protected by accelerator_mutex in accel.c   Is there 
> any specific reason for this?

Yes.  These functions need to be synchronised by the callers.  Adding a
mutex here would ensure that they didn't execute at the same time, but
wouldn't impose any order on the calls.  This matters because add
followed by remove is different from remove followed by add.  The
callers need to decide which order they should be executed in.

The relevant call chains are as follows:

xenbus otherend_changed callback
  -> backend_changed [netfront.c]
    -> network_connect
      -> talk_to_backend
        -> netfront_accelerator_add_watch

xenbus suspend_cancel callback
  -> netfront_suspend_cancel
    -> netfront_accelerator_suspend_cancel
      -> netfront_accelerator_add_watch

xenbus suspend callback
  -> netfront_suspend
    -> netfront_accelerator_suspend
      -> netfront_accelerator_remove_watch

xenbus remove callback
  -> netfront_remove
    -> netfront_accelerator_call_remove
      -> netfront_accelerator_remove_watch

So the watch is only added/removed from a xenbus callback.  I think
these callbacks should be synchronised by xenbus.  Can someone confirm that?

> I see that they sometimes get called twice (and result in BUG_ON) in 
> very fast (20ms) domain suspend-resume cycles and I couldn't figure out 
> how it is possible :-(

Is that the BUG_ON in netfront_accelerator_add_watch?  One possible
explanation is that suspend_cancel is called and then otherend_changed
is called.  Can you add a printk to netfront_suspend_cancel to see if it
gets called just before the BUG_ON gets triggered?

Cheers, Neil.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel