branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl-credit2
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 <torva...@linux-foundation.org>
  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 <l...@amacapital.net>
  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 <l...@amacapital.net>
      Cc: Don Zickus <dzic...@redhat.com>
      Cc: Peter Zijlstra <pet...@infradead.org>
      Cc: Dave Jones <da...@redhat.com>
      Cc: Linus Torvalds <torva...@linux-foundation.org>
      Link: 
http://lkml.kernel.org/r/a6cd3b60a3f53afb6e1c8081b0ec30ff19003dd7.1416434075.git.l...@amacapital.net
      Signed-off-by: Thomas Gleixner <t...@linutronix.de>
  
  commit 70b61e362187b5fccac206506d402f3424e3e749
  Author: Kees Cook <keesc...@chromium.org>
  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 <mar...@trippelsdorf.de>
      Signed-off-by: Kees Cook <keesc...@chromium.org>
      Cc: Junjie Mao <eternal....@gmail.com>
      Link: http://lkml.kernel.org/r/20141118001604.ga25...@www.outflux.net
      Cc: sta...@vger.kernel.org
      Signed-off-by: Thomas Gleixner <t...@linutronix.de>
  
  commit 45e2a9d4701d8c624d4a4bcdd1084eae31e92f58
  Author: Kees Cook <keesc...@chromium.org>
  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 <keesc...@chromium.org>
      Cc: Andy Lutomirski <l...@amacapital.net>
      Cc: Toshi Kani <toshi.k...@hp.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasu...@jp.fujitsu.com>
      Cc: David Vrabel <david.vra...@citrix.com>
      Cc: Wang Nan <wangn...@huawei.com>
      Cc: Yinghai Lu <ying...@kernel.org>
      Cc: sta...@vger.kernel.org
      Link: http://lkml.kernel.org/r/20141114194737.ga3...@www.outflux.net
      Signed-off-by: Thomas Gleixner <t...@linutronix.de>
  
  commit fb86b97300d930b57471068720c52bfa8622eab7
  Author: Borislav Petkov <b...@suse.de>
  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.schna...@gmail.com
      Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=88001
      Cc: Henrique de Moraes Holschuh <h...@hmh.eng.br>
      Cc: Fenghua Yu <fenghua...@intel.com>
      Cc: <sta...@vger.kernel.org> # v3.9
      Signed-off-by: Borislav Petkov <b...@suse.de>
      Link: http://lkml.kernel.org/r/20141118094657.ga6...@pd.tnic
      Signed-off-by: Thomas Gleixner <t...@linutronix.de>
  
  commit 2cd3949f702692cf4c5d05b463f19cd706a92dd3
  Author: Dave Hansen <dave.han...@linux.intel.com>
  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.han...@linux.intel.com>
      Cc: Dave Hansen <d...@sr71.net>
      Cc: Fenghua Yu <fenghua...@intel.com>
      Cc: x...@kernel.org
      Cc: sta...@vger.kernel.org
      Link: http://lkml.kernel.org/r/20141111220133.fe053...@viggo.jf.intel.com
      Signed-off-by: Thomas Gleixner <t...@linutronix.de>


For bisection revision-tuple graph see:
   
http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.linux-linus.test-amd64-i386-xl-credit2.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=lace-bug] 31683 [host=gall-mite] 
31665 [host=bush-cricket] 31564 [host=lace-bug] 31530 [host=moss-bug] 31507 ok.
Failure / basis pass flights: 31858 / 31507
(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 206c5f60a3d902bc4b56dab2de3e88de5eb06108 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
ca78cc83650b535d7e24baeaea32947be0141534 
e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#206c5f60a3d902bc4b56dab2de3e88de5eb06108-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#ca78cc83650b535d7e24baeaea32947be0141534-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 108292 nodes in revision graph
Searching for test results:
 31471 [host=itch-mite]
 31484 [host=bush-cricket]
 31507 pass 206c5f60a3d902bc4b56dab2de3e88de5eb06108 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
ca78cc83650b535d7e24baeaea32947be0141534 
e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31530 [host=moss-bug]
 31564 [host=lace-bug]
 31683 [host=gall-mite]
 31665 [host=bush-cricket]
 31766 [host=lace-bug]
 31894 fail 4fc82c0a766cf1d0bc098fb42d00b5292dde65f7 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31907 fail c6c9161d064d30e78904f3affe5184487493e0fc 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31859 pass 206c5f60a3d902bc4b56dab2de3e88de5eb06108 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
ca78cc83650b535d7e24baeaea32947be0141534 
e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2
 31880 pass 0c228e833c88e3aa029250f5db77d5968c5ce5b5 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31865 fail irrelevant
 31868 pass irrelevant
 31869 fail irrelevant
 31896 pass 00b4d9a14125f1e51874def2b9de6092e007412d 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
09ff8eadec09233b905f79579900006fb17dd55f
 31858 fail 5d01410fe4d92081f349b013a2e7a95429e4f2c9 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31908 pass 8b2ed21e846c63d8f1bdee0d8df0645721a604a1 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31870 fail irrelevant
 31884 fail 9a7e4f5633f0c733820091cc9c643cc0c257c349 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31887 fail 08685897b3586aad622cb48fe1fb07bc19bb78f5 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31850 fail irrelevant
 31898 pass 00b4d9a14125f1e51874def2b9de6092e007412d 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31909 fail c6c9161d064d30e78904f3affe5184487493e0fc 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31888 pass b0ab3f190e7331a83b397a0e772cbc01bf18201f 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
ca78cc83650b535d7e24baeaea32947be0141534 
934e7baa6c12d19cfaf24e8f8e27d6c6a8b8c5e4
 31879 fail 5d01410fe4d92081f349b013a2e7a95429e4f2c9 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31891 pass 5ae93760cbedda64eab0a7012cc3785c32399641 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
abbbc2f09a53f8f9ee565356ab11a78af006e45e 
902dfd33da08169f08a593a4ef2c45d825cca8c8
 31901 pass fc14f9c1272f62c3e8d01300f52467c0d9af50f9 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
4e1d1d097423aaeb2fb2f19ac4691bb326bd62d8
 31893 pass fc14f9c1272f62c3e8d01300f52467c0d9af50f9 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
405254bbb2fdbfa8a428fd144ea7585812af9e8a
 31910 pass 8b2ed21e846c63d8f1bdee0d8df0645721a604a1 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31903 pass a64bb02f4a62a604d8dd62decb559b9c6adfb40c 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31905 pass 8b2ed21e846c63d8f1bdee0d8df0645721a604a1 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
 31911 fail c6c9161d064d30e78904f3affe5184487493e0fc 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
Searching for interesting versions
 Result found: flight 31507 (pass), for basis pass
 Result found: flight 31858 (fail), for basis failure
 Repro found: flight 31859 (pass), for basis pass
 Repro found: flight 31879 (fail), for basis failure
 0 revisions at 8b2ed21e846c63d8f1bdee0d8df0645721a604a1 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
a230ec3101ddda868252c036ea960af2b2d6cd5a 
6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
No revisions left to test, checking graph state.
 Result found: flight 31905 (pass), for last pass
 Result found: flight 31907 (fail), for first failure
 Repro found: flight 31908 (pass), for last pass
 Repro found: flight 31909 (fail), for first failure
 Repro found: flight 31910 (pass), for last pass
 Repro found: flight 31911 (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 <torva...@linux-foundation.org>
  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 <l...@amacapital.net>
  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 <l...@amacapital.net>
      Cc: Don Zickus <dzic...@redhat.com>
      Cc: Peter Zijlstra <pet...@infradead.org>
      Cc: Dave Jones <da...@redhat.com>
      Cc: Linus Torvalds <torva...@linux-foundation.org>
      Link: 
http://lkml.kernel.org/r/a6cd3b60a3f53afb6e1c8081b0ec30ff19003dd7.1416434075.git.l...@amacapital.net
      Signed-off-by: Thomas Gleixner <t...@linutronix.de>
  
  commit 70b61e362187b5fccac206506d402f3424e3e749
  Author: Kees Cook <keesc...@chromium.org>
  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 <mar...@trippelsdorf.de>
      Signed-off-by: Kees Cook <keesc...@chromium.org>
      Cc: Junjie Mao <eternal....@gmail.com>
      Link: http://lkml.kernel.org/r/20141118001604.ga25...@www.outflux.net
      Cc: sta...@vger.kernel.org
      Signed-off-by: Thomas Gleixner <t...@linutronix.de>
  
  commit 45e2a9d4701d8c624d4a4bcdd1084eae31e92f58
  Author: Kees Cook <keesc...@chromium.org>
  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 <keesc...@chromium.org>
      Cc: Andy Lutomirski <l...@amacapital.net>
      Cc: Toshi Kani <toshi.k...@hp.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasu...@jp.fujitsu.com>
      Cc: David Vrabel <david.vra...@citrix.com>
      Cc: Wang Nan <wangn...@huawei.com>
      Cc: Yinghai Lu <ying...@kernel.org>
      Cc: sta...@vger.kernel.org
      Link: http://lkml.kernel.org/r/20141114194737.ga3...@www.outflux.net
      Signed-off-by: Thomas Gleixner <t...@linutronix.de>
  
  commit fb86b97300d930b57471068720c52bfa8622eab7
  Author: Borislav Petkov <b...@suse.de>
  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.schna...@gmail.com
      Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=88001
      Cc: Henrique de Moraes Holschuh <h...@hmh.eng.br>
      Cc: Fenghua Yu <fenghua...@intel.com>
      Cc: <sta...@vger.kernel.org> # v3.9
      Signed-off-by: Borislav Petkov <b...@suse.de>
      Link: http://lkml.kernel.org/r/20141118094657.ga6...@pd.tnic
      Signed-off-by: Thomas Gleixner <t...@linutronix.de>
  
  commit 2cd3949f702692cf4c5d05b463f19cd706a92dd3
  Author: Dave Hansen <dave.han...@linux.intel.com>
  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.han...@linux.intel.com>
      Cc: Dave Hansen <d...@sr71.net>
      Cc: Fenghua Yu <fenghua...@intel.com>
      Cc: x...@kernel.org
      Cc: sta...@vger.kernel.org
      Link: http://lkml.kernel.org/r/20141111220133.fe053...@viggo.jf.intel.com
      Signed-off-by: Thomas Gleixner <t...@linutronix.de>

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

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

Failures :-/ but no regressions.

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


jobs:
 test-amd64-i386-xl-credit2                                   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@lists.xen.org
http://lists.xen.org/xen-devel

Reply via email to