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
>>> 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.
>>>> -------- Original Message --------
>>>> Subject: Stable candidate? xen: events: do not unmask event channels on
>>>> 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)
>>>> on migration for 2.6.32 and 2.6.35 based kernels. I am not completely sure
>>>> the 2.6.32 case as some reporters were reporting success after it was
>>>> others still had issues. But at least it seemed to improve the
>>>> Should this get proposed for upstream longterm trees?
>>>> 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
>> 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
>> 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.
>>>> 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
>>>>  https://bugs.launchpad.net/ubuntu/maverick/+source/linux/+bug/681083
>>> Xen-devel mailing list
>> Xen-devel mailing list
Xen-devel mailing list