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

[David Woodhouse <dwmw2@xxxxxxxxxxxxx>]

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
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel