Re: [Xen-devel] Re: Stable candidate? xen: events: do not unmask event channels on resume

[Stefan Bader <stefan.bader@xxxxxxxxxxxxx>]

On 07.06.2011 11:14, Ian Campbell wrote:
> On Tue, 2011-06-07 at 10:07 +0100, Stefan Bader wrote:
>> On 07.06.2011 10:48, Ian Campbell wrote:
>>> On Tue, 2011-06-07 at 08:44 +0100, Stefan Bader wrote:
>>>> Resending. I could not see this going to the list, so I subscribed and am 
>>>> trying
>>>> again.
>>>
>>> Posts from non-subscribers are moderated, it would have come through at
>>> some point.
>>>
>> I was not sure how long that would take or whether non-subscribers would just
>> get dropped to prevent spam. It does not hurt to be subscribed, so discussion
>> can go quicker.
>>
>>>> -Stefan
>>>>
>>>> -------- Original Message --------
>>>> Subject: Stable candidate? xen: events: do not unmask event channels on 
>>>> resume
>>>> Date: Wed, 25 May 2011 16:46:47 +0200
>>>> From: Stefan Bader <stefan.bader@xxxxxxxxxxxxx>
>>>> To: xen-devel@xxxxxxxxxxxxxxxxxxx <xen-devel@xxxxxxxxxxxxxxxxxxx>
>>>> CC: Ian Campbell <ian.campbell@xxxxxxxxxx>
>>>>
>>>> The following patch was reported to solve (at least some in the .32 case) 
>>>> hangs
>>>> on migration for 2.6.32 and 2.6.35 based kernels. I am not completely sure 
>>>> about
>>>> the 2.6.32 case as some reporters were reporting success after it was 
>>>> applied,
>>>> others still had issues[1]. But at least it seemed to improve the 
>>>> situation.
>>>> Should this get proposed for upstream longterm trees?
>>>>
>>>> -Stefan
>>>>
>>>> From cf2e26cf8402af6f65bd89611682497db278f309 Mon Sep 17 00:00:00 2001
>>>
>>> This seems to be 6903591f314b in the upstream tree. Also there was a
>>> subsequent cleanup in 676dc3cf5bc3 which relies on dc5f219e, which we
>>> should consider too. I think as a set they make sense for a
>>> stable/longterm backport so you can have my:
>>> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
>>> for forwarding to stable@
>>>
>>> I expect you'll want/need tglx's Ack for the latter two as well.
>>>
>> They would be needed when trying to push the whole set, yes. On the other 
>> hand,
>> on a casual glance, these just seem to make some functionality that the first
>> patch did on the xen side, available in the generic framework.
>> If there is no issue without the two, my feeling would be, that going with 
>> the
>> single patch for stable/longterm would be better. To me things going there
>> should have a real functional benefit.
>> But probably I am overlooking something in the cleanup.
> 
> The original patch was really a hack on the xen side, the followups do
> it properly...
> 
I am not doubting that. It is more the way I see for stable:
- first patch solves the problem
- does it cause other problems? If no, done. Otherwise, what changes are
  necessary to make it work?

So if the first patch is a hack, but one that makes things work and was upstream
at some point, I think it is hard to argue for the cleanup as long as it "only"
does things right.

But I will check how well the other two fit into the various stable/longterm
trees and then send a proposal to stable cc'ing you and Thomas with the options.
Then we will see how things go there.

-Stefan
> 
>>
>> -Stefan
>>
>>> Ian.
>>>
>>>> From: Ian Campbell <ian.campbell@xxxxxxxxxx>
>>>> Date: Mon, 1 Nov 2010 16:30:09 +0000
>>>> Subject: [PATCH] xen: events: do not unmask event channels on resume
>>>>
>>>> [1] https://bugs.launchpad.net/ubuntu/maverick/+source/linux/+bug/681083
>>>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>> http://lists.xensource.com/xen-devel
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel