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);
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
