On 19/11/2018 10:39, David Woodhouse wrote:
> 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);
Feel free to send a patch (my patch is already in rc2).
Juergen
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
