Am 21.02.2013 00:35, schrieb Ben Hutchings:
> On Wed, 2013-02-20 at 17:29 +0100, Oleg Nesterov wrote:
>> Hi Ben,
>>
>> sorry for delay,
>>
>> On 02/20, Ben Hutchings wrote:
>>>
>>> On Tue, 2013-02-19 at 20:35 +0100, Stefan Priebe wrote:
>>>> Am 19.02.2013 20:05, schrieb Ben Hutchings:
>>>>> On Tue, Feb 19, 2013 at 06:51:53AM -0800, Greg KH wrote:
>>>>>> On Tue, Feb 19, 2013 at 10:18:37AM +0100, Stefan Priebe - Profihost AG 
>>>>>> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> will we see a backport for the above fix for the 3.0.X tree?
>>>>>>
>>>>>> Is it applicable to the 3.0.x tree?  And if so, someone needs to
>>>>>> backport it, and provide it to me, can you?
>>>>>
>>>>> For 3.2.y I've cherry-picked (in this order):
>>>>>
>>>>> 848e8f5f0ad3169560c516fff6471be65f76e69f
>>>>> 95cf00fa5d5e2a200a2c044c84bde8389a237e02
>>>>> 910ffdb18a6408e14febbb6e4b6840fd2c928c82
>>>>> 9899d11f654474d2d54ea52ceaa2a1f4db3abd68
>>>>> 9067ac85d533651b98c2ff903182a20cbb361fcb
>>>>>
>>>>> The last three fix the more recently-discovered race.  The first two
>>>>> are a fix for an x86-specific race in ptrace, made by Oleg back in
>>>>> August.  The fourth at least textually depends on the first two.
>>>>>
>>>>> I'm not sure whether 3.0.y would need anything more.
>>>> at least on 3.0 this picking does not work as
>>>> 910ffdb18a6408e14febbb6e4b6840fd2c928c82
>>>>
>>>> does not apply. But backports of the last three are here:
>>>> http://www.mail-archive.com/[email protected]/msg31694.html
>>>
>>> Oleg, could you comment on whether 'ptrace/x86: Partly fix
>>> set_task_blockstep()->update_debugctlmsr() logic' should be backported
>>> to 3.0.y as well?
>>
>> No, I don't think -stable really needs this fix. The fix itself is fine
>> (I hope ;), but the bug is not serious.
>>
>> You can apply 9899d11f654474d2d54ea52ceaa2a1f4db3abd68 without the comment
>> changes in arch/x86/kernel/step.c
> 
> Thanks a lot.

To be sure i've applied all 5 patches.

Stefan
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to