1. 29 5月, 2013 3 次提交
  2. 28 5月, 2013 1 次提交
  3. 21 5月, 2013 3 次提交
  4. 15 5月, 2013 10 次提交
  5. 08 5月, 2013 2 次提交
  6. 01 5月, 2013 4 次提交
  7. 19 4月, 2013 1 次提交
  8. 17 4月, 2013 3 次提交
  9. 03 4月, 2013 1 次提交
  10. 28 3月, 2013 2 次提交
    • D
      xen/events: avoid race with raising an event in unmask_evtchn() · c26377e6
      David Vrabel 提交于
      In unmask_evtchn(), when the mask bit is cleared after testing for
      pending and the event becomes pending between the test and clear, then
      the upcall will not become pending and the event may be lost or
      delayed.
      
      Avoid this by always clearing the mask bit before checking for
      pending.  If a hypercall is needed, remask the event as
      EVTCHNOP_unmask will only retrigger pending events if they were
      masked.
      
      This fixes a regression introduced in 3.7 by
      b5e57923 (xen/events: fix
      unmask_evtchn for PV on HVM guests) which reordered the clear mask and
      check pending operations.
      
      Changes in v2:
      - set mask before hypercall.
      
      Cc: stable@vger.kernel.org
      Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      c26377e6
    • K
      xen/acpi-stub: Disable it b/c the acpi_processor_add is no longer called. · 76fc2537
      Konrad Rzeszutek Wilk 提交于
      With the Xen ACPI stub code (CONFIG_XEN_STUB=y) enabled, the power
      C and P states are no longer uploaded to the hypervisor.
      
      The reason is that the Xen CPU hotplug code: xen-acpi-cpuhotplug.c
      and the xen-acpi-stub.c register themselves as the "processor" type object.
      
      That means the generic processor (processor_driver.c) stops
      working and it does not call (acpi_processor_add) which populates the
      
               per_cpu(processors, pr->id) = pr;
      
      structure. The 'pr' is gathered from the acpi_processor_get_info function
      which does the job of finding the C-states and figuring out PBLK address.
      
      The 'processors->pr' is then later used by xen-acpi-processor.c (the one that
      uploads C and P states to the hypervisor). Since it is NULL, we end
      skip the gathering of _PSD, _PSS, _PCT, etc and never upload the power
      management data.
      
      The end result is that enabling the CONFIG_XEN_STUB in the build means that
      xen-acpi-processor is not working anymore.
      
      This temporary patch fixes it by marking the XEN_STUB driver as
      BROKEN until this can be properly fixed.
      
      CC: jinsong.liu@intel.com
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      76fc2537
  11. 22 3月, 2013 2 次提交
    • J
      xen-pciback: notify hypervisor about devices intended to be assigned to guests · 909b3fdb
      Jan Beulich 提交于
      For MSI-X capable devices the hypervisor wants to write protect the
      MSI-X table and PBA, yet it can't assume that resources have been
      assigned to their final values at device enumeration time. Thus have
      pciback do that notification, as having the device controlled by it is
      a prerequisite to assigning the device to guests anyway.
      
      This is the kernel part of hypervisor side commit 4245d33 ("x86/MSI:
      add mechanism to fully protect MSI-X table from PV guest accesses") on
      the master branch of git://xenbits.xen.org/xen.git.
      
      CC: stable@vger.kernel.org
      Signed-off-by: NJan Beulich <jbeulich@suse.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      909b3fdb
    • K
      xen/acpi-processor: Don't dereference struct acpi_processor on all CPUs. · 949dd8c1
      Konrad Rzeszutek Wilk 提交于
      With git commit c705c78c
      "acpi: Export the acpi_processor_get_performance_info" we are now
      using a different mechanism to access the P-states.
      
      The acpi_processor per-cpu structure is set and filtered by the
      core ACPI code which shrinks the per_cpu contents to only online CPUs.
      In the past we would call acpi_processor_register_performance()
      which would have not tried to dereference offline cpus.
      
      With the new patch and the fact that the loop we take is for
      for_all_possible_cpus we end up crashing on some machines.
      We could modify the loop to be for online_cpus - but all the other
      loops in the code use possible_cpus (for a good reason) - so lets
      leave it as so and just check if per_cpu(processor) is NULL.
      
      With this patch we will bypass the !online but possible CPUs.
      This fixes:
      
      IP: [<ffffffffa00d13b5>] xen_acpi_processor_init+0x1b6/0xe01 [xen_acpi_processor]
      PGD 4126e6067 PUD 4126e3067 PMD 0
      Oops: 0002 [#1] SMP
      Pid: 432, comm: modprobe Not tainted 3.9.0-rc3+ #28 To be filled by O.E.M. To be filled by O.E.M./M5A97
      RIP: e030:[<ffffffffa00d13b5>]  [<ffffffffa00d13b5>] xen_acpi_processor_init+0x1b6/0xe01 [xen_acpi_processor]
      RSP: e02b:ffff88040c8a3ce8  EFLAGS: 00010282
      .. snip..
      Call Trace:
       [<ffffffffa00d11ff>] ? read_acpi_id+0x12b/0x12b [xen_acpi_processor]
       [<ffffffff8100215a>] do_one_initcall+0x12a/0x180
       [<ffffffff810c42c3>] load_module+0x1cd3/0x2870
       [<ffffffff81319b70>] ? ddebug_proc_open+0xc0/0xc0
       [<ffffffff810c4f37>] sys_init_module+0xd7/0x120
       [<ffffffff8166ce19>] system_call_fastpath+0x16/0x1b
      
      on some machines.
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      949dd8c1
  12. 12 3月, 2013 1 次提交
  13. 06 3月, 2013 2 次提交
    • K
      acpi: Export the acpi_processor_get_performance_info · c705c78c
      Konrad Rzeszutek Wilk 提交于
      The git commit d5aaffa9
      (cpufreq: handle cpufreq being disabled for all exported function)
      tightens the cpufreq API by returning errors when disable_cpufreq()
      had been called.
      
      The problem we are hitting is that the module xen-acpi-processor which
      uses the ACPI's functions: acpi_processor_register_performance,
      acpi_processor_preregister_performance, and acpi_processor_notify_smm
      fails at acpi_processor_register_performance with -22.
      
      Note that earlier during bootup in arch/x86/xen/setup.c there is also
      an call to cpufreq's API: disable_cpufreq().
      
      This is b/c we want the Linux kernel to parse the ACPI data, but leave
      the cpufreq decisions to the hypervisor.
      
      In v3.9 all the checks that d5aaffa9
      added are now hit and the calls to cpufreq_register_notifier will now
      fail. This means that acpi_processor_ppc_init ends up printing:
      
      "Warning: Processor Platform Limit not supported"
      
      and the acpi_processor_ppc_status is not set.
      
      The repercussions of that is that the call to
      acpi_processor_register_performance fails right away at:
      
      	if (!(acpi_processor_ppc_status & PPC_REGISTERED))
      
      and we don't progress any further on parsing and extracting the _P*
      objects.
      
      The only reason the Xen code called that function was b/c it was
      exported and the only way to gather the P-states. But we can also
      just make acpi_processor_get_performance_info be exported and not
      use acpi_processor_register_performance. This patch does so.
      Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      c705c78c
    • K
      xen/pciback: Don't disable a PCI device that is already disabled. · bdc5c181
      Konrad Rzeszutek Wilk 提交于
      While shuting down a HVM guest with pci devices passed through we
      get this:
      
      pciback 0000:04:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100002)
      ------------[ cut here ]------------
      WARNING: at drivers/pci/pci.c:1397 pci_disable_device+0x88/0xa0()
      Hardware name: MS-7640
      Device pciback
      disabling already-disabled device
      Modules linked in:
      Pid: 53, comm: xenwatch Not tainted 3.9.0-rc1-20130304a+ #1
      Call Trace:
       [<ffffffff8106994a>] warn_slowpath_common+0x7a/0xc0
       [<ffffffff81069a31>] warn_slowpath_fmt+0x41/0x50
       [<ffffffff813cf288>] pci_disable_device+0x88/0xa0
       [<ffffffff814554a7>] xen_pcibk_reset_device+0x37/0xd0
       [<ffffffff81454b6f>] ? pcistub_put_pci_dev+0x6f/0x120
       [<ffffffff81454b8d>] pcistub_put_pci_dev+0x8d/0x120
       [<ffffffff814582a9>] __xen_pcibk_release_devices+0x59/0xa0
      
      This fixes the bug.
      
      CC: stable@vger.kernel.org
      Reported-and-Tested-by: NSander Eikelenboom <linux@eikelenboom.it>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      bdc5c181
  14. 04 3月, 2013 1 次提交
    • E
      fs: Limit sys_mount to only request filesystem modules. · 7f78e035
      Eric W. Biederman 提交于
      Modify the request_module to prefix the file system type with "fs-"
      and add aliases to all of the filesystems that can be built as modules
      to match.
      
      A common practice is to build all of the kernel code and leave code
      that is not commonly needed as modules, with the result that many
      users are exposed to any bug anywhere in the kernel.
      
      Looking for filesystems with a fs- prefix limits the pool of possible
      modules that can be loaded by mount to just filesystems trivially
      making things safer with no real cost.
      
      Using aliases means user space can control the policy of which
      filesystem modules are auto-loaded by editing /etc/modprobe.d/*.conf
      with blacklist and alias directives.  Allowing simple, safe,
      well understood work-arounds to known problematic software.
      
      This also addresses a rare but unfortunate problem where the filesystem
      name is not the same as it's module name and module auto-loading
      would not work.  While writing this patch I saw a handful of such
      cases.  The most significant being autofs that lives in the module
      autofs4.
      
      This is relevant to user namespaces because we can reach the request
      module in get_fs_type() without having any special permissions, and
      people get uncomfortable when a user specified string (in this case
      the filesystem type) goes all of the way to request_module.
      
      After having looked at this issue I don't think there is any
      particular reason to perform any filtering or permission checks beyond
      making it clear in the module request that we want a filesystem
      module.  The common pattern in the kernel is to call request_module()
      without regards to the users permissions.  In general all a filesystem
      module does once loaded is call register_filesystem() and go to sleep.
      Which means there is not much attack surface exposed by loading a
      filesytem module unless the filesystem is mounted.  In a user
      namespace filesystems are not mounted unless .fs_flags = FS_USERNS_MOUNT,
      which most filesystems do not set today.
      Acked-by: NSerge Hallyn <serge.hallyn@canonical.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Reported-by: NKees Cook <keescook@google.com>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      7f78e035
  15. 01 3月, 2013 1 次提交
  16. 25 2月, 2013 2 次提交
  17. 23 2月, 2013 1 次提交
新手
引导
客服 返回
顶部