From patchwork Thu Jul 14 15:58:04 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: APPLIED: [2.6.32+drm33-longterm] Linux 2.6.32.43+drm33.19 Date: Thu, 14 Jul 2011 05:58:04 -0000 From: Stefan Bader X-Patchwork-Id: 104693 Message-Id: <4E1F120C.9040901@canonical.com> To: tim.gardner@canonical.com Cc: kernel-team@lists.ubuntu.com 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: >>>>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/810425 >>>>> >>>>> >>>>> 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 2.6.32.43 (2011-07-14 06:45:33 -0600) are available in the git repository at: git://kernel.ubuntu.com/smb/ubuntu-lucid.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(-)