On Wed, Sep 21, 2011 at 05:08:38PM -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Sep 19, 2011 at 12:01:56PM +0100, Jan Beulich wrote:
> > >>> On 19.09.11 at 12:43, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> > >>>> On 16.09.11 at 21:06, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> > >>>> wrote:
> > >
> > >> The caller that orchestrates the state changes is xenwatch_thread
> > >> and it takes a mutex. In our processing of Xenbus states we can take
> > >> the luxery of going to sleep on a mutex, so lets do that and
> > >
> > > This is only the direct conversion of existing spinlock accesses in
> > > xenbus.c. However, in the course of converting from the legacy
> > > implementation you stripped a couple more (in xen_pcibk_attach(),
> > > xen_pcibk_reconfigure(), and xen_pcibk_setup_backend()), and
> >
> > Actually, xen_pcibk_attach() has its lock taken in xen_pcibk_do_attach(),
> > so no change needed there.
> >
> > In xen_pcibk_reconfigure() and xen_pcibk_setup_backend() the locking
> > may be redundant with the one in passthrough.c/vpci.c - is that the
> > basis upon which you removed the locks taken there?
>
> No. I believe the reason was much simpler.. it was b/c of this patch (see
> below).
> But for the life of me I don't recall what deadlock we could hit.
You know what.. I think the issue was that I was trying to fix the
"sleeping on a spinlock" issue and was moving the spinlocks around to fix it.
.. Without realizing I could have just used a mutex.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home