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

[Christian Borntraeger]

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/