Patchwork APPLIED: [2.6.32+drm33-longterm] Linux

mail settings
Submitter Stefan Bader
Date July 14, 2011, 3:58 p.m.
Message ID <>
Download mbox
Permalink /patch/104693/
State New
Headers show


git:// master-next


Stefan Bader - July 14, 2011, 3:58 p.m.
On 14.07.2011 17:45, Tim Gardner wrote:
> On 07/14/2011 09:35 AM, Stefan Bader wrote:
>> On 14.07.2011 17:24, Stefan Bader wrote:
>>> On 14.07.2011 17:11, Tim Gardner wrote:
>>>> On 07/14/2011 09:07 AM, Stefan Bader wrote:
>>>>> On 14.07.2011 14:51, Tim Gardner wrote:
>>>>> Seems, Tim, you just dropped the new xen patch. OK, I don't know
>>>>> exactly what the preference for stable is, but we may want to get
>>>>> back to be same as upstream...
>>>>> -Stefan
>>>> Indeed I did as I saw no reason to revert the revert only to apply the revert
>>>> yet again.
>>>> I'm not sure I see the value in being the same as upstream stable. In fact,
>>>> we're not identical as soon as we revert _any_ patch that has arrived via
>>>> stable.
>>>> rtg
>>> Though reverting the revert (which was reverting an upstream stable patch) would
>>> make the kernel be the same as upstream. And then adding the additional (partial
>>> revert) fixes the breakage. I agree it sounds confusing...
>> Ok, I don't think that helped much...
>> So the initial patch from upstream changed things affecting 32 and 64 bit in
>> order to fix a breakage caused by another patch (however that one was reverted
>> from upstream stable because it caused some other regression and has not been
>> re-applied yet (with the fix that fixed that regression).
>> The new xen patch is a partial revert in the sense that it changes the 32bit
>> code back to how it was before and preserves the change on the 64bit code path.
>> So as long as upstream does not decide that they want the patch that caused all
>> those fallout (x86: Cleanup highmap after brk is concluded), then we are ok with
>> the complete revert of the xen patch. But if they did, then the 64bit kernel
>> would fail under Xen. If we re-apply the patch we reverted and add the partial
>> revert, we would be ok in all cases.
>> -Stefan
> Egads! How about a pull request on top of master-next
> 51baad9488da20194cd457f5d7e4c07e77b0d988 that show the changes you think are
> correct?
The following changes since commit 51baad9488da20194cd457f5d7e4c07e77b0d988:

  Linux (2011-07-14 06:45:33 -0600)

are available in the git repository at:
  git:// master-next

Stefano Stabellini (2):
      xen: set max_pfn_mapped to the last pfn mapped
      xen: partially revert "xen: set max_pfn_mapped to the last pfn mapped"

 arch/x86/xen/mmu.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)
Tim Gardner - July 14, 2011, 4:13 p.m.
On 07/14/2011 09:58 AM, Stefan Bader wrote:
> git:// master-next

OK, applied with a bit of order swizzling so that 'Linux' is 
the last commit.