linux-kernel - Re: [Xen-devel] Re: [PATCH] xen/pciback: Use mutexes when working with Xenbus state transitions.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20110921211259.GB30029@phenom.oracle.com>
Date:	Wed, 21 Sep 2011 17:12:59 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Jan Beulich <JBeulich@...e.com>
Cc:	xen-devel@...ts.xensource.com, linux-kernel@...r.kernel.org
Subject: Re: [Xen-devel] Re: [PATCH] xen/pciback: Use mutexes when working
 with Xenbus state transitions.

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@...e.com> wrote:
> > >>>> On 16.09.11 at 21:06, Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/