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

[Xen-tools] Re: [Fwd: Question about use of xenstore]

On Wed, 2005-08-10 at 10:16 +0100, harry wrote:
> > For block drivers, it works like this:
> > 1) tool deletes frontend dir
> > 2) frontend domain: xenbus calls driver cleanup
> > 3) backend domain: sees frontend go away and deletes backend dir, calls
> > xenbus to do driver cleanup.
> > 
> > That model seems to work well, and requires very little from the tools.
> > I would recommend pursuing the same model for USB, although your
> > frontend driver cleanup would leave the watch active, and page mapped,
> > waiting to see that final backend delete.
> 
> That seems broken to me: where is the interlock that guarantees that the
> shared memory page is not reused by the front-end whilst the back-end is
> servicing an interrupt which is reading from the page?

Say the FE pushes two requests and the BE takes the interrupt for the
first one, happens to pick up both because the second has arrived in the
ring by that time.  The BE completes both requests so there are none now
outstanding but there is still a BE interrupt pending.  The FE gets
completion for both requests because Xen happens to switch domains (and
temporarily suspends execution of the BE).  The FE cleans up and reuses
the shared page, filling it with something that can be misinterpreted as
a non empty ring filled with block IO requests.  The BE restarts, takes
the interrupt, sees the non-empty corrupt ring contents and proceeds to
scribble all over the disks.

Is there an interlock to prevent that?

Harry.


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