Skip to content
  1. Apr 24, 2011
  2. Apr 23, 2011
  3. Apr 22, 2011
  4. Apr 21, 2011
    • Jan Kara's avatar
      vfs: Pass setxattr(2) flags properly · df7e1303
      Jan Kara authored
      
      
      For some reason generic_setxattr() did not pass flags (XATTR_CREATE,
      XATTR_REPLACE) to the filesystem specific helper. This caused that
      setxattr(2) syscall just ignored these flags.
      
      Fix the bug by passing flags correctly.
      
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Acked-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      df7e1303
    • Amit Shah's avatar
      virtio: console: Enable call to hvc_remove() on console port remove · afa2689e
      Amit Shah authored
      
      
      This call was disabled as hot-unplugging one virtconsole port led to
      another virtconsole port freezing.
      
      Upon testing it again, this now works, so enable it.
      
      In addition, a bug was found in qemu wherein removing a port of one type
      caused the guest output from another port to stop working.  I doubt it
      was just this bug that caused it (since disabling the hvc_remove() call
      did allow other ports to continue working), but since it's all solved
      now, we're fine with hot-unplugging of virtconsole ports.
      
      Signed-off-by: default avatarAmit Shah <amit.shah@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      afa2689e
    • Amit Shah's avatar
      virtio_pci: Prevent double-free of pci regions after device hot-unplug · 31a3ddda
      Amit Shah authored
      
      
      In the case where a virtio-console port is in use (opened by a program)
      and a virtio-console device is removed, the port is kept around but all
      the virtio-related state is assumed to be gone.
      
      When the port is finally released (close() called), we call
      device_destroy() on the port's device.  This results in the parent
      device's structures to be freed as well.  This includes the PCI regions
      for the virtio-console PCI device.
      
      Once this is done, however, virtio_pci_release_dev() kicks in, as the
      last ref to the virtio device is now gone, and attempts to do
      
           pci_iounmap(pci_dev, vp_dev->ioaddr);
           pci_release_regions(pci_dev);
           pci_disable_device(pci_dev);
      
      which results in a double-free warning.
      
      Move the code that releases regions, etc., to the virtio_pci_remove()
      function, and all that's now left in release_dev is the final freeing of
      the vp_dev.
      
      Signed-off-by: default avatarAmit Shah <amit.shah@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      31a3ddda
    • Amit Shah's avatar
      virtio: Decrement avail idx on buffer detach · b3258ff1
      Amit Shah authored
      
      
      When detaching a buffer from a vq, the avail.idx value should be
      decremented as well.
      
      This was noticed by hot-unplugging a virtio console port and then
      plugging in a new one on the same number (re-using the vqs which were
      just 'disowned').  qemu reported
      
         'Guest moved used index from 0 to 256'
      
      when any IO was attempted on the new port.
      
      CC: stable@kernel.org
      Reported-by: default avatarjuzhang <juzhang@redhat.com>
      Signed-off-by: default avatarAmit Shah <amit.shah@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      b3258ff1
    • Joseph Cihula's avatar
      intel_iommu: disable all VT-d PMRs when TXT launched · 51a63e67
      Joseph Cihula authored
      
      
      Intel VT-d Protected Memory Regions (PMRs) are supposed to be disabled,
      on each VT-d engine, after DMA remapping is enabled on the engines.
      This is because the behavior of having both enabled is not deterministic
      and because, if TXT has been used to launch the kernel, the PMRs may be
      programmed to cover memory regions that will be used for DMA.
      
      Under some circumstances (certain quirks detected, lack of multiple
      devices, etc.), the current code does not set up DMA remapping on some
      VT-d engines.  In such cases it also skips disabling the PMRs.  This
      causes failures when the kernel is launched with TXT (most often this
      occurs on the graphics engine and results in colored vertical bars on
      the display).
      
      This patch detects when the kernel has been launched with TXT and then
      disables the PMRs on all VT-d engines.  In some cases where the reason
      that remapping is not being enabled is due to possible ACPI DMAR table
      errors, the VT-d engine addresses may not be correct and thus not able
      to be safely programmed even to disable PMRs.  Because part of the TXT
      launch process is the verification of these addresses, it will always be
      safe to disable PMRs if the TXT launch has succeeded and hence only
      doing this in such cases.
      
      Signed-off-by: default avatarJoseph Cihula <joseph.cihula@intel.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      51a63e67
    • Takashi Iwai's avatar
      Merge branch 'fix/hda' into for-linus · 6a9a6f23
      Takashi Iwai authored
      6a9a6f23
    • David Rientjes's avatar
      x86, numa: Fix cpu nodemasks for NUMA emulation and CONFIG_DEBUG_PER_CPU_MAPS · 7a6c6547
      David Rientjes authored
      
      
      The cpu<->node mappings under CONFIG_DEBUG_PER_CPU_MAPS=y
      when NUMA emulation is enabled is currently broken because it does
      not iterate through every emulated node and bind cpus that have
      affinity to it.
      
      NUMA emulation should bind each cpu to every local node to
      accurately represent the true NUMA topology of the underlying
      machine.
      
      debug_cpumask_set_cpu() needs to be fixed at the same time so
      that the debugging information that it emits shows the new
      cpumask of the node being assigned when the cpu is being added
      or removed.
      
      It can now take responsibility of setting or clearing the cpu
      itself to remove the need for duplicate code.
      
      Also change its last parameter, "enable", to have the correct bool
      type since it can only be true or false.
      
       -v2: Fix the return statements, by Kosaki Motohiro
      
      Acked-and-Tested-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.00.1104201918470.12634@chino.kir.corp.google.com
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      7a6c6547
    • David Rientjes's avatar
      Revert "x86, NUMA: Fix fakenuma boot failure" · 37f8527d
      David Rientjes authored
      Andreas Herrmann reported that 7d6b4670
      
       ("x86, NUMA: Fix fakenuma
      boot failure") causes certain physical NUMA topologies (for example
      AMD Magny-Cours) to move sibling cpus to a single node when in reality
      they are in separate domains.
      
      This may result in some nodes being completely void of cpus, which
      doesn't accurately represent the correct topology. The system will
      boot, but will have suboptimal NUMA performance.
      
      This commit was intended as a fix for NUMA emulation, but should
      not cause a regression for real NUMA machines as a side effect.
      
      ( There will be a separate fix for the numa-debug code, which
        will not affect physical topologies. )
      
      Reported-by: default avatarAndreas Herrmann <herrmann.der.user@googlemail.com>
      Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Acked-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.00.1104201918110.12634@chino.kir.corp.google.com
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      37f8527d
    • Vasiliy Kulikov's avatar
      agp: fix arbitrary kernel memory writes · 194b3da8
      Vasiliy Kulikov authored
      
      
      pg_start is copied from userspace on AGPIOC_BIND and AGPIOC_UNBIND ioctl
      cmds of agp_ioctl() and passed to agpioc_bind_wrap().  As said in the
      comment, (pg_start + mem->page_count) may wrap in case of AGPIOC_BIND,
      and it is not checked at all in case of AGPIOC_UNBIND.  As a result, user
      with sufficient privileges (usually "video" group) may generate either
      local DoS or privilege escalation.
      
      Signed-off-by: default avatarVasiliy Kulikov <segoon@openwall.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      194b3da8