Re: [PATCH for stable] x86/spinlocks/paravirt: Fix memory corruption on unlock

From: Christian Borntraeger
Date: Wed Feb 25 2015 - 05:14:53 EST


Am 25.02.2015 um 11:08 schrieb Ingo Molnar:
>
> * Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
>>>> It's:
>>>>
>>>> d6abfdb20223 x86/spinlocks/paravirt: Fix memory corruption on unlock
>>>
>>> Yes, This is the original patch. Please note I have taken out the
>>> READ_ONCE changes from the original patch to avoid build warnings
>>> mentioned below.
>>> (Those READ_ONCE changes were cosmetic and was not present in the
>>> previous versions)
>>>
>>>>
>>>> You'll also need this fix from Linus to avoid (harmless)
>>>> build warnings:
>>>>
>>>> dd36929720f4 kernel: make READ_ONCE() valid on const arguments
>>>
>>> So this may not be absolutely necessary with the current patch.
>>
>> I'd prefer to be as close as possible to the upstream
>> patch. So if applying both of these patches will work,
>> I'd much rather do that. Changing patches when
>> backporting them to stable for no good reason than to
>> clean things up, just confuses everyone involved.
>>
>> Let's keep our messy history :)
>
> By all means!
>
> You'll first need to cherry-pick these commits:
>


> 927609d622a3 kernel: tighten rules for ACCESS ONCE
> c5b19946eb76 kernel: Fix sparse warning for ACCESS_ONCE
> dd36929720f4 kernel: make READ_ONCE() valid on const arguments

If you go before 3.19, you will also need

230fa253df63 kernel: Provide READ_ONCE and ASSIGN_ONCE
43239cbe79fc kernel: Change ASSIGN_ONCE(val, x) to WRITE_ONCE(x, val)


>
> That's the minimum set you will need for backporting, due
> to overlapping changes to the ACCESS_ONCE() definition.
>
> and then apply this commit:
>
> d6abfdb20223 x86/spinlocks/paravirt: Fix memory corruption on unlock

the alternative might be to replace READ_ONCE with ACCESS_ONCE when
doing the backport.
This depends on how important you consider backporting the ACCESS_ONCE fixes.

Christian


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/