1. 19 5月, 2016 1 次提交
  2. 09 5月, 2016 1 次提交
  3. 19 2月, 2016 1 次提交
  4. 18 2月, 2016 1 次提交
    • D
      x86/mm/pkeys: Add arch-specific VMA protection bits · 8f62c883
      Dave Hansen 提交于
      Lots of things seem to do:
      
              vma->vm_page_prot = vm_get_page_prot(flags);
      
      and the ptes get created right from things we pull out
      of ->vm_page_prot.  So it is very convenient if we can
      store the protection key in flags and vm_page_prot, just
      like the existing permission bits (_PAGE_RW/PRESENT).  It
      greatly reduces the amount of plumbing and arch-specific
      hacking we have to do in generic code.
      
      This also takes the new PROT_PKEY{0,1,2,3} flags and
      turns *those* in to VM_ flags for vma->vm_flags.
      
      The protection key values are stored in 4 places:
      	1. "prot" argument to system calls
      	2. vma->vm_flags, filled from the mmap "prot"
      	3. vma->vm_page prot, filled from vma->vm_flags
      	4. the PTE itself.
      
      The pseudocode for these for steps are as follows:
      
      	mmap(PROT_PKEY*)
      	vma->vm_flags 	  = ... | arch_calc_vm_prot_bits(mmap_prot);
      	vma->vm_page_prot = ... | arch_vm_get_page_prot(vma->vm_flags);
      	pte = pfn | vma->vm_page_prot
      
      Note that this provides a new definitions for x86:
      
      	arch_vm_get_page_prot()
      Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave@sr71.net>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/20160212210210.FE483A42@viggo.jf.intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      8f62c883
  5. 17 2月, 2016 4 次提交
    • A
      x86/signal/64: Re-add support for SS in the 64-bit signal context · 6c25da5a
      Andy Lutomirski 提交于
      This is a second attempt to make the improvements from c6f20629
      ("x86/signal/64: Fix SS handling for signals delivered to 64-bit
      programs"), which was reverted by 51adbfbba5c6 ("x86/signal/64: Add
      support for SS in the 64-bit signal context").
      
      This adds two new uc_flags flags.  UC_SIGCONTEXT_SS will be set for
      all 64-bit signals (including x32).  It indicates that the saved SS
      field is valid and that the kernel supports the new behavior.
      
      The goal is to fix a problems with signal handling in 64-bit tasks:
      SS wasn't saved in the 64-bit signal context, making it awkward to
      determine what SS was at the time of signal delivery and making it
      impossible to return to a non-flat SS (as calling sigreturn clobbers
      SS).
      
      This also made it extremely difficult for 64-bit tasks to return to
      fully-defined 16-bit contexts, because only the kernel can easily do
      espfix64, but sigreturn was unable to set a non-flag SS:ESP.
      (DOSEMU has a monstrous hack to partially work around this
      limitation.)
      
      If we could go back in time, the correct fix would be to make 64-bit
      signals work just like 32-bit signals with respect to SS: save it
      in signal context, reset it when delivering a signal, and restore
      it in sigreturn.
      
      Unfortunately, doing that (as I tried originally) breaks DOSEMU:
      DOSEMU wouldn't reset the signal context's SS when clearing the LDT
      and changing the saved CS to 64-bit mode, since it predates the SS
      context field existing in the first place.
      
      This patch is a bit more complicated, and it tries to balance a
      bunch of goals.  It makes most cases of changing ucontext->ss during
      signal handling work as expected.
      
      I do this by special-casing the interesting case.  On sigreturn,
      ucontext->ss will be honored by default, unless the ucontext was
      created from scratch by an old program and had a 64-bit CS
      (unfortunately, CRIU can do this) or was the result of changing a
      32-bit signal context to 64-bit without resetting SS (as DOSEMU
      does).
      
      For the benefit of new 64-bit software that uses segmentation (new
      versions of DOSEMU might), the new behavior can be detected with a
      new ucontext flag UC_SIGCONTEXT_SS.
      
      To avoid compilation issues, __pad0 is left as an alias for ss in
      ucontext.
      
      The nitty-gritty details are documented in the header file.
      
      This patch also re-enables the sigreturn_64 and ldt_gdt_64 selftests,
      as the kernel change allows both of them to pass.
      Tested-by: NStas Sergeev <stsp@list.ru>
      Signed-off-by: NAndy Lutomirski <luto@kernel.org>
      Acked-by: NBorislav Petkov <bp@alien8.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/749149cbfc3e75cd7fcdad69a854b399d792cc6f.1455664054.git.luto@kernel.org
      [ Small readability edit. ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      6c25da5a
    • A
      x86/signal/64: Add a comment about sigcontext->fs and gs · e54fdcca
      Andy Lutomirski 提交于
      These fields have a strange history.  This tries to document it.
      
      This borrows from 9a036b93 ("x86/signal/64: Remove 'fs' and 'gs'
      from sigcontext"), which was reverted by ed596cde ("Revert x86
      sigcontext cleanups").
      Signed-off-by: NAndy Lutomirski <luto@kernel.org>
      Acked-by: NBorislav Petkov <bp@alien8.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stas Sergeev <stsp@list.ru>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/baa78f3c84106fa5acbc319377b1850602f5deec.1455664054.git.luto@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      e54fdcca
    • A
      drivers/hv: Move VMBus hypercall codes into Hyper-V UAPI header · 18f09861
      Andrey Smetanin 提交于
      VMBus hypercall codes inside Hyper-V UAPI header will
      be used by QEMU to implement VMBus host devices support.
      Signed-off-by: NAndrey Smetanin <asmetanin@virtuozzo.com>
      Acked-by: NK. Y. Srinivasan <kys@microsoft.com>
      Reviewed-by: NRoman Kagan <rkagan@virtuozzo.com>
      CC: Gleb Natapov <gleb@kernel.org>
      CC: Paolo Bonzini <pbonzini@redhat.com>
      CC: Joerg Roedel <joro@8bytes.org>
      CC: "K. Y. Srinivasan" <kys@microsoft.com>
      CC: Haiyang Zhang <haiyangz@microsoft.com>
      CC: Roman Kagan <rkagan@virtuozzo.com>
      CC: Denis V. Lunev <den@openvz.org>
      CC: qemu-devel@nongnu.org
      [Do not rename the constant at the same time as moving it, as that
       would cause semantic conflicts with the Hyper-V tree. - Paolo]
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      18f09861
    • A
      kvm/x86: Rename Hyper-V long spin wait hypercall · 8ed6d767
      Andrey Smetanin 提交于
      Rename HV_X64_HV_NOTIFY_LONG_SPIN_WAIT by HVCALL_NOTIFY_LONG_SPIN_WAIT,
      so the name is more consistent with the other hypercalls.
      Signed-off-by: NAndrey Smetanin <asmetanin@virtuozzo.com>
      Reviewed-by: NRoman Kagan <rkagan@virtuozzo.com>
      CC: Gleb Natapov <gleb@kernel.org>
      CC: Paolo Bonzini <pbonzini@redhat.com>
      CC: Joerg Roedel <joro@8bytes.org>
      CC: "K. Y. Srinivasan" <kys@microsoft.com>
      CC: Haiyang Zhang <haiyangz@microsoft.com>
      CC: Roman Kagan <rkagan@virtuozzo.com>
      CC: Denis V. Lunev <den@openvz.org>
      CC: qemu-devel@nongnu.org
      [Change name, Andrey used HV_X64_HCALL_NOTIFY_LONG_SPIN_WAIT. - Paolo]
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      8ed6d767
  6. 16 2月, 2016 1 次提交
  7. 17 12月, 2015 4 次提交
  8. 24 11月, 2015 1 次提交
  9. 10 11月, 2015 1 次提交
  10. 04 11月, 2015 1 次提交
  11. 12 10月, 2015 1 次提交
  12. 02 10月, 2015 1 次提交
  13. 01 10月, 2015 3 次提交
  14. 14 9月, 2015 1 次提交
  15. 08 9月, 2015 13 次提交
  16. 28 8月, 2015 1 次提交
  17. 19 8月, 2015 1 次提交
    • D
      libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option · 7a67832c
      Dan Williams 提交于
      We currently register a platform device for e820 type-12 memory and
      register a nvdimm bus beneath it.  Registering the platform device
      triggers the device-core machinery to probe for a driver, but that
      search currently comes up empty.  Building the nvdimm-bus registration
      into the e820_pmem platform device registration in this way forces
      libnvdimm to be built-in.  Instead, convert the built-in portion of
      CONFIG_X86_PMEM_LEGACY to simply register a platform device and move the
      rest of the logic to the driver for e820_pmem, for the following
      reasons:
      
      1/ Letting e820_pmem support be a module allows building and testing
         libnvdimm.ko changes without rebooting
      
      2/ All the normal policy around modules can be applied to e820_pmem
         (unbind to disable and/or blacklisting the module from loading by
         default)
      
      3/ Moving the driver to a generic location and converting it to scan
         "iomem_resource" rather than "e820.map" means any other architecture can
         take advantage of this simple nvdimm resource discovery mechanism by
         registering a resource named "Persistent Memory (legacy)"
      
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      7a67832c
  18. 14 8月, 2015 1 次提交
  19. 13 8月, 2015 1 次提交
  20. 06 8月, 2015 1 次提交