[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl



branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl
test guest-saverestore

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  c6c9161d064d30e78904f3affe5184487493e0fc
  Bug not present: 8b2ed21e846c63d8f1bdee0d8df0645721a604a1


  commit c6c9161d064d30e78904f3affe5184487493e0fc
  Merge: 8b2ed21 b5e212a
  Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
  Date:   Fri Nov 21 15:46:17 2014 -0800
  
      Merge branch 'x86-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
      
      Pull x86 fixes from Thomas Gleixner:
       "Misc fixes:
         - gold linker build fix
         - noxsave command line parsing fix
         - bugfix for NX setup
         - microcode resume path bug fix
         - _TIF_NOHZ versus TIF_NOHZ bugfix as discussed in the mysterious
           lockup thread"
      
      * 'x86-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86, syscall: Fix _TIF_NOHZ handling in syscall_trace_enter_phase1
        x86, kaslr: Handle Gold linker for finding bss/brk
        x86, mm: Set NX across entire PMD at boot
        x86, microcode: Update BSPs microcode on resume
        x86: Require exact match for 'noxsave' command line option
  
  commit b5e212a3051b65e426a513901d9c7001681c7215
  Author: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
  Date:   Wed Nov 19 13:56:19 2014 -0800
  
      x86, syscall: Fix _TIF_NOHZ handling in syscall_trace_enter_phase1
      
      TIF_NOHZ is 19 (i.e. _TIF_SYSCALL_TRACE | _TIF_NOTIFY_RESUME |
      _TIF_SINGLESTEP), not (1<<19).
      
      This code is involved in Dave's trinity lockup, but I don't see why
      it would cause any of the problems he's seeing, except inadvertently
      by causing a different path through entry_64.S's syscall handling.
      
      Signed-off-by: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
      Cc: Don Zickus <dzickus@xxxxxxxxxx>
      Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
      Cc: Dave Jones <davej@xxxxxxxxxx>
      Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
      Link: 
http://lkml.kernel.org/r/a6cd3b60a3f53afb6e1c8081b0ec30ff19003dd7.1416434075.git.luto@xxxxxxxxxxxxxx
      Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
  
  commit 70b61e362187b5fccac206506d402f3424e3e749
  Author: Kees Cook <keescook@xxxxxxxxxxxx>
  Date:   Mon Nov 17 16:16:04 2014 -0800
  
      x86, kaslr: Handle Gold linker for finding bss/brk
      
      When building with the Gold linker, the .bss and .brk areas of vmlinux
      are shown as consecutive instead of having the same file offset. Allow
      for either state, as long as things add up correctly.
      
      Fixes: e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd")
      Reported-by: Markus Trippelsdorf <markus@xxxxxxxxxxxxxxx>
      Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx>
      Cc: Junjie Mao <eternal.n08@xxxxxxxxx>
      Link: http://lkml.kernel.org/r/20141118001604.GA25045@xxxxxxxxxxxxxxx
      Cc: stable@xxxxxxxxxxxxxxx
      Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
  
  commit 45e2a9d4701d8c624d4a4bcdd1084eae31e92f58
  Author: Kees Cook <keescook@xxxxxxxxxxxx>
  Date:   Fri Nov 14 11:47:37 2014 -0800
  
      x86, mm: Set NX across entire PMD at boot
      
      When setting up permissions on kernel memory at boot, the end of the
      PMD that was split from bss remained executable. It should be NX like
      the rest. This performs a PMD alignment instead of a PAGE alignment to
      get the correct span of memory.
      
      Before:
      ---[ High Kernel Mapping ]---
      ...
      0xffffffff8202d000-0xffffffff82200000  1868K     RW       GLB NX pte
      0xffffffff82200000-0xffffffff82c00000    10M     RW   PSE GLB NX pmd
      0xffffffff82c00000-0xffffffff82df5000  2004K     RW       GLB NX pte
      0xffffffff82df5000-0xffffffff82e00000    44K     RW       GLB x  pte
      0xffffffff82e00000-0xffffffffc0000000   978M                     pmd
      
      After:
      ---[ High Kernel Mapping ]---
      ...
      0xffffffff8202d000-0xffffffff82200000  1868K     RW       GLB NX pte
      0xffffffff82200000-0xffffffff82e00000    12M     RW   PSE GLB NX pmd
      0xffffffff82e00000-0xffffffffc0000000   978M                     pmd
      
      [ tglx: Changed it to roundup(_brk_end, PMD_SIZE) and added a comment.
              We really should unmap the reminder along with the holes
              caused by init,initdata etc. but thats a different issue ]
      
      Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx>
      Cc: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
      Cc: Toshi Kani <toshi.kani@xxxxxx>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@xxxxxxxxxxxxxx>
      Cc: David Vrabel <david.vrabel@xxxxxxxxxx>
      Cc: Wang Nan <wangnan0@xxxxxxxxxx>
      Cc: Yinghai Lu <yinghai@xxxxxxxxxx>
      Cc: stable@xxxxxxxxxxxxxxx
      Link: http://lkml.kernel.org/r/20141114194737.GA3091@xxxxxxxxxxxxxxx
      Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
  
  commit fb86b97300d930b57471068720c52bfa8622eab7
  Author: Borislav Petkov <bp@xxxxxxx>
  Date:   Tue Nov 18 10:46:57 2014 +0100
  
      x86, microcode: Update BSPs microcode on resume
      
      In the situation when we apply early microcode but do *not* apply late
      microcode, we fail to update the BSP's microcode on resume because we
      haven't initialized the uci->mc microcode pointer. So, in order to
      alleviate that, we go and dig out the stashed microcode patch during
      early boot. It is basically the same thing that is done on the APs early
      during boot so do that too here.
      
      Tested-by: alex.schnaidt@xxxxxxxxx
      Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=88001
      Cc: Henrique de Moraes Holschuh <hmh@xxxxxxxxxx>
      Cc: Fenghua Yu <fenghua.yu@xxxxxxxxx>
      Cc: <stable@xxxxxxxxxxxxxxx> # v3.9
      Signed-off-by: Borislav Petkov <bp@xxxxxxx>
      Link: http://lkml.kernel.org/r/20141118094657.GA6635@xxxxxxx
      Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
  
  commit 2cd3949f702692cf4c5d05b463f19cd706a92dd3
  Author: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
  Date:   Tue Nov 11 14:01:33 2014 -0800
  
      x86: Require exact match for 'noxsave' command line option
      
      We have some very similarly named command-line options:
      
      arch/x86/kernel/cpu/common.c:__setup("noxsave", x86_xsave_setup);
      arch/x86/kernel/cpu/common.c:__setup("noxsaveopt", x86_xsaveopt_setup);
      arch/x86/kernel/cpu/common.c:__setup("noxsaves", x86_xsaves_setup);
      
      __setup() is designed to match options that take arguments, like
      "foo=bar" where you would have:
      
        __setup("foo", x86_foo_func...);
      
      The problem is that "noxsave" actually _matches_ "noxsaves" in
      the same way that "foo" matches "foo=bar".  If you boot an old
      kernel that does not know about "noxsaves" with "noxsaves" on the
      command line, it will interpret the argument as "noxsave", which
      is not what you want at all.
      
      This makes the "noxsave" handler only return success when it finds
      an *exact* match.
      
      [ tglx: We really need to make __setup() more robust. ]
      
      Signed-off-by: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
      Cc: Dave Hansen <dave@xxxxxxxx>
      Cc: Fenghua Yu <fenghua.yu@xxxxxxxxx>
      Cc: x86@xxxxxxxxxx
      Cc: stable@xxxxxxxxxxxxxxx
      Link: http://lkml.kernel.org/r/20141111220133.FE053984@xxxxxxxxxxxxxxxxxx
      Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>


For bisection revision-tuple graph see:
   
http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.linux-linus.test-amd64-i386-xl.guest-saverestore.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 31858 fail [host=rice-weevil] / 31766 [host=field-cricket] 31683 
[host=gall-mite] 31665 ok.
Failure / basis pass flights: 31858 / 31665
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 5d01410fe4d92081f349b013a2e7a95429e4f2c9 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
Basis pass fc14f9c1272f62c3e8d01300f52467c0d9af50f9 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 
e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#fc14f9c1272f62c3e8d01300f52467c0d9af50f9-5d01410fe4d92081f349b013a2e7a95429e4f2c9
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22
 
git://xenbits.xen.org/staging/qemu-upstream-unstable.git#0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51-a230ec3101ddda868252c036ea960af2b2d6cd5a
 
git://xenbits.xen.org/xen.git#e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2-6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-2.6
+ git remote set-url origin 
git://drall.uk.xensource.com:9419/git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git remote set-url origin 
git://drall.uk.xensource.com:9419/git://xenbits.xen.org/staging/qemu-upstream-unstable.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin 
git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-2.6
+ git remote set-url origin 
git://drall.uk.xensource.com:9419/git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/qemu-upstream-unstable
+ git remote set-url origin 
git://drall.uk.xensource.com:9419/git://xenbits.xen.org/staging/qemu-upstream-unstable.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin 
git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 382257 nodes in revision graph
Searching for test results:
 31683 [host=gall-mite]
 31665 pass fc14f9c1272f62c3e8d01300f52467c0d9af50f9 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 
e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31766 [host=field-cricket]
 31858 fail 5d01410fe4d92081f349b013a2e7a95429e4f2c9 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31850 fail irrelevant
 31914 pass fc14f9c1272f62c3e8d01300f52467c0d9af50f9 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 
e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31920 pass 788ec2fc2ca295a2d929986e95231214ecd8d142 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31937 pass 8b2ed21e846c63d8f1bdee0d8df0645721a604a1 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31929 pass 8b2ed21e846c63d8f1bdee0d8df0645721a604a1 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31918 fail 5d01410fe4d92081f349b013a2e7a95429e4f2c9 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31923 fail e6a588d086a75dc20afb8ffbcbe23a50d4a1ca37 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31919 fail 9a7e4f5633f0c733820091cc9c643cc0c257c349 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31926 pass fc14f9c1272f62c3e8d01300f52467c0d9af50f9 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
0f25d1b324b7922094c9e1bde78d7df01d57dadc
 31924 pass fc14f9c1272f62c3e8d01300f52467c0d9af50f9 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 
dbdd03d0ad4ad93f1db50341fac56a514c726552
 31927 pass a64bb02f4a62a604d8dd62decb559b9c6adfb40c 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31930 fail c6c9161d064d30e78904f3affe5184487493e0fc 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31936 fail c6c9161d064d30e78904f3affe5184487493e0fc 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31933 pass 8b2ed21e846c63d8f1bdee0d8df0645721a604a1 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31938 fail c6c9161d064d30e78904f3affe5184487493e0fc 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
Searching for interesting versions
 Result found: flight 31665 (pass), for basis pass
 Result found: flight 31858 (fail), for basis failure
 Repro found: flight 31914 (pass), for basis pass
 Repro found: flight 31918 (fail), for basis failure
 0 revisions at 8b2ed21e846c63d8f1bdee0d8df0645721a604a1 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
No revisions left to test, checking graph state.
 Result found: flight 31929 (pass), for last pass
 Result found: flight 31930 (fail), for first failure
 Repro found: flight 31933 (pass), for last pass
 Repro found: flight 31936 (fail), for first failure
 Repro found: flight 31937 (pass), for last pass
 Repro found: flight 31938 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  c6c9161d064d30e78904f3affe5184487493e0fc
  Bug not present: 8b2ed21e846c63d8f1bdee0d8df0645721a604a1

+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-2.6
+ git remote set-url origin 
git://drall.uk.xensource.com:9419/git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*

  commit c6c9161d064d30e78904f3affe5184487493e0fc
  Merge: 8b2ed21 b5e212a
  Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
  Date:   Fri Nov 21 15:46:17 2014 -0800
  
      Merge branch 'x86-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
      
      Pull x86 fixes from Thomas Gleixner:
       "Misc fixes:
         - gold linker build fix
         - noxsave command line parsing fix
         - bugfix for NX setup
         - microcode resume path bug fix
         - _TIF_NOHZ versus TIF_NOHZ bugfix as discussed in the mysterious
           lockup thread"
      
      * 'x86-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86, syscall: Fix _TIF_NOHZ handling in syscall_trace_enter_phase1
        x86, kaslr: Handle Gold linker for finding bss/brk
        x86, mm: Set NX across entire PMD at boot
        x86, microcode: Update BSPs microcode on resume
        x86: Require exact match for 'noxsave' command line option
  
  commit b5e212a3051b65e426a513901d9c7001681c7215
  Author: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
  Date:   Wed Nov 19 13:56:19 2014 -0800
  
      x86, syscall: Fix _TIF_NOHZ handling in syscall_trace_enter_phase1
      
      TIF_NOHZ is 19 (i.e. _TIF_SYSCALL_TRACE | _TIF_NOTIFY_RESUME |
      _TIF_SINGLESTEP), not (1<<19).
      
      This code is involved in Dave's trinity lockup, but I don't see why
      it would cause any of the problems he's seeing, except inadvertently
      by causing a different path through entry_64.S's syscall handling.
      
      Signed-off-by: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
      Cc: Don Zickus <dzickus@xxxxxxxxxx>
      Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
      Cc: Dave Jones <davej@xxxxxxxxxx>
      Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
      Link: 
http://lkml.kernel.org/r/a6cd3b60a3f53afb6e1c8081b0ec30ff19003dd7.1416434075.git.luto@xxxxxxxxxxxxxx
      Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
  
  commit 70b61e362187b5fccac206506d402f3424e3e749
  Author: Kees Cook <keescook@xxxxxxxxxxxx>
  Date:   Mon Nov 17 16:16:04 2014 -0800
  
      x86, kaslr: Handle Gold linker for finding bss/brk
      
      When building with the Gold linker, the .bss and .brk areas of vmlinux
      are shown as consecutive instead of having the same file offset. Allow
      for either state, as long as things add up correctly.
      
      Fixes: e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd")
      Reported-by: Markus Trippelsdorf <markus@xxxxxxxxxxxxxxx>
      Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx>
      Cc: Junjie Mao <eternal.n08@xxxxxxxxx>
      Link: http://lkml.kernel.org/r/20141118001604.GA25045@xxxxxxxxxxxxxxx
      Cc: stable@xxxxxxxxxxxxxxx
      Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
  
  commit 45e2a9d4701d8c624d4a4bcdd1084eae31e92f58
  Author: Kees Cook <keescook@xxxxxxxxxxxx>
  Date:   Fri Nov 14 11:47:37 2014 -0800
  
      x86, mm: Set NX across entire PMD at boot
      
      When setting up permissions on kernel memory at boot, the end of the
      PMD that was split from bss remained executable. It should be NX like
      the rest. This performs a PMD alignment instead of a PAGE alignment to
      get the correct span of memory.
      
      Before:
      ---[ High Kernel Mapping ]---
      ...
      0xffffffff8202d000-0xffffffff82200000  1868K     RW       GLB NX pte
      0xffffffff82200000-0xffffffff82c00000    10M     RW   PSE GLB NX pmd
      0xffffffff82c00000-0xffffffff82df5000  2004K     RW       GLB NX pte
      0xffffffff82df5000-0xffffffff82e00000    44K     RW       GLB x  pte
      0xffffffff82e00000-0xffffffffc0000000   978M                     pmd
      
      After:
      ---[ High Kernel Mapping ]---
      ...
      0xffffffff8202d000-0xffffffff82200000  1868K     RW       GLB NX pte
      0xffffffff82200000-0xffffffff82e00000    12M     RW   PSE GLB NX pmd
      0xffffffff82e00000-0xffffffffc0000000   978M                     pmd
      
      [ tglx: Changed it to roundup(_brk_end, PMD_SIZE) and added a comment.
              We really should unmap the reminder along with the holes
              caused by init,initdata etc. but thats a different issue ]
      
      Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx>
      Cc: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
      Cc: Toshi Kani <toshi.kani@xxxxxx>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@xxxxxxxxxxxxxx>
      Cc: David Vrabel <david.vrabel@xxxxxxxxxx>
      Cc: Wang Nan <wangnan0@xxxxxxxxxx>
      Cc: Yinghai Lu <yinghai@xxxxxxxxxx>
      Cc: stable@xxxxxxxxxxxxxxx
      Link: http://lkml.kernel.org/r/20141114194737.GA3091@xxxxxxxxxxxxxxx
      Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
  
  commit fb86b97300d930b57471068720c52bfa8622eab7
  Author: Borislav Petkov <bp@xxxxxxx>
  Date:   Tue Nov 18 10:46:57 2014 +0100
  
      x86, microcode: Update BSPs microcode on resume
      
      In the situation when we apply early microcode but do *not* apply late
      microcode, we fail to update the BSP's microcode on resume because we
      haven't initialized the uci->mc microcode pointer. So, in order to
      alleviate that, we go and dig out the stashed microcode patch during
      early boot. It is basically the same thing that is done on the APs early
      during boot so do that too here.
      
      Tested-by: alex.schnaidt@xxxxxxxxx
      Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=88001
      Cc: Henrique de Moraes Holschuh <hmh@xxxxxxxxxx>
      Cc: Fenghua Yu <fenghua.yu@xxxxxxxxx>
      Cc: <stable@xxxxxxxxxxxxxxx> # v3.9
      Signed-off-by: Borislav Petkov <bp@xxxxxxx>
      Link: http://lkml.kernel.org/r/20141118094657.GA6635@xxxxxxx
      Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
  
  commit 2cd3949f702692cf4c5d05b463f19cd706a92dd3
  Author: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
  Date:   Tue Nov 11 14:01:33 2014 -0800
  
      x86: Require exact match for 'noxsave' command line option
      
      We have some very similarly named command-line options:
      
      arch/x86/kernel/cpu/common.c:__setup("noxsave", x86_xsave_setup);
      arch/x86/kernel/cpu/common.c:__setup("noxsaveopt", x86_xsaveopt_setup);
      arch/x86/kernel/cpu/common.c:__setup("noxsaves", x86_xsaves_setup);
      
      __setup() is designed to match options that take arguments, like
      "foo=bar" where you would have:
      
        __setup("foo", x86_foo_func...);
      
      The problem is that "noxsave" actually _matches_ "noxsaves" in
      the same way that "foo" matches "foo=bar".  If you boot an old
      kernel that does not know about "noxsaves" with "noxsaves" on the
      command line, it will interpret the argument as "noxsave", which
      is not what you want at all.
      
      This makes the "noxsave" handler only return success when it finds
      an *exact* match.
      
      [ tglx: We really need to make __setup() more robust. ]
      
      Signed-off-by: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
      Cc: Dave Hansen <dave@xxxxxxxx>
      Cc: Fenghua Yu <fenghua.yu@xxxxxxxxx>
      Cc: x86@xxxxxxxxxx
      Cc: stable@xxxxxxxxxxxxxxx
      Link: http://lkml.kernel.org/r/20141111220133.FE053984@xxxxxxxxxxxxxxxxxx
      Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>

Revision graph left in 
/home/xc_osstest/results/bisect.linux-linus.test-amd64-i386-xl.guest-saverestore.{dot,ps,png,html}.
----------------------------------------
31938: tolerable ALL FAIL

flight 31938 linux-linus real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31938/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl           11 guest-saverestore       fail baseline untested


jobs:
 test-amd64-i386-xl                                           fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.