[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Guest soft lockups with "xen: make xen_qlock_wait() nestable"

On Mon, 2018-11-19 at 08:05 +0100, Juergen Gross wrote:
> On 15/11/2018 00:22, David Woodhouse wrote:
> > On Thu, 2018-11-08 at 11:18 +0100, Juergen Gross wrote:
> > > Oh, sorry. Of course it does. Dereferencing a percpu variable
> > > directly can't work. How silly of me.
> > > 
> > > The attached variant should repair that. Tested to not break
> > > booting.
> > 
> > Strictly speaking, shouldn't you have an atomic_init() in there
> > somewhere?
> atomic_t variables initialized with 0 (e.g. static ones) seem not to
> require atomic_init() (or ATOMIC_INIT). Documentation/atomic_t.txt
> doesn't mention the need to use it in this case. So I guess it is a
> matter of taste.

Yeah, we have '#define ATOMIC_INIT(i) { (i) }' fairly much everywhere
now, even on SPARC (not that this code runs on SPARC).

So it doesn't really matter, and it's fairly unlikely that the atomic_t
implementation is going to *change*.

But still, there's no harm in doing the 'tasteful' version:

static DEFINE_PER_CPU(atomic_t, xen_qlock_wait_nest) = ATOMIC_INIT(0);

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.