Permalink
Switch branches/tags
Commits on Aug 16, 2012
  1. debugfs: make __create_file static

    chriswright authored and gregkh committed Aug 9, 2012
    It's only used locally, no need to pollute global namespace.
    
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commits on Dec 27, 2011
  1. KVM: MMU: remove KVM host pv mmu support

    chriswright authored and Avi Kivity committed Nov 2, 2011
    The host side pv mmu support has been marked for feature removal in
    January 2011.  It's not in use, is slower than shadow or hardware
    assisted paging, and a maintenance burden.  It's November 2011, time to
    remove it.
    
    Signed-off-by: Chris Wright <chrisw@redhat.com>
    Signed-off-by: Avi Kivity <avi@redhat.com>
  2. KVM guest: remove KVM guest pv mmu support

    chriswright authored and Avi Kivity committed Nov 2, 2011
    This has not been used for some years now.  It's time to remove it.
    
    Signed-off-by: Chris Wright <chrisw@redhat.com>
    Signed-off-by: Avi Kivity <avi@redhat.com>
Commits on Jul 26, 2011
  1. mm/huge_memory.c: minor lock simplification in __khugepaged_exit

    chriswright authored and torvalds committed Jul 26, 2011
    The lock is released first thing in all three branches.  Simplify this by
    unconditionally releasing lock and remove else clause which was only there
    to be sure lock was released.
    
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Reviewed-by: Michal Hocko <mhocko@suse.cz>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Acked-by: Johannes Weiner <jweiner@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commits on Jul 22, 2011
  1. PCI: ARI is a PCIe v2 feature

    chriswright authored and jbarnes993 committed Jul 13, 2011
    The function pci_enable_ari() may mistakenly set the downstream port
    of a v1 PCIe switch in ARI Forwarding mode.  This is a PCIe v2 feature,
    and with an SR-IOV device on that switch port believing the switch above
    is ARI capable it may attempt to use functions 8-255, translating into
    invalid (non-zero) device numbers for that bus.  This has been seen
    to cause Completion Timeouts and general misbehaviour including hangs
    and panics.
    
    Cc: stable@kernel.org
    Acked-by: Don Dutile <ddutile@redhat.com>
    Tested-by: Don Dutile <ddutile@redhat.com>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Commits on Jun 1, 2011
  1. intel-iommu: Dont cache iova above 32bit

    chriswright authored and dwmw2 committed May 28, 2011
    Mike Travis and Mike Habeck reported an issue where iova allocation
    would return a range that was larger than a device's dma mask.
    
    https://lkml.org/lkml/2011/3/29/423
    
    The dmar initialization code will reserve all PCI MMIO regions and copy
    those reservations into a domain specific iova tree.  It is possible for
    one of those regions to be above the dma mask of a device.  It is typical
    to allocate iovas with a 32bit mask (despite device's dma mask possibly
    being larger) and cache the result until it exhausts the lower 32bit
    address space.  Freeing the iova range that is >= the last iova in the
    lower 32bit range when there is still an iova above the 32bit range will
    corrupt the cached iova by pointing it to a region that is above 32bit.
    If that region is also larger than the device's dma mask, a subsequent
    allocation will return an unusable iova and cause dma failure.
    
    Simply don't cache an iova that is above the 32bit caching boundary.
    
    Reported-by: Mike Travis <travis@sgi.com>
    Reported-by: Mike Habeck <habeck@sgi.com>
    Cc: stable@kernel.org
    Acked-by: Mike Travis <travis@sgi.com>
    Tested-by: Mike Habeck <habeck@sgi.com>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
  2. intel-iommu: Check for identity mapping candidate using system dma mask

    chriswright authored and dwmw2 committed May 28, 2011
    The identity mapping code appears to make the assumption that if the
    devices dma_mask is greater than 32bits the device can use identity
    mapping.  But that is not true: take the case where we have a 40bit
    device in a 44bit architecture. The device can potentially receive a
    physical address that it will truncate and cause incorrect addresses
    to be used.
    
    Instead check to see if the device's dma_mask is large enough
    to address the system's dma_mask.
    
    Signed-off-by: Mike Travis <travis@sgi.com>
    Reviewed-by: Mike Habeck <habeck@sgi.com>
    Cc: stable@kernel.org
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Commits on Feb 15, 2011
  1. pci: use security_capable() when checking capablities during config s…

    chriswright authored and James Morris committed Feb 15, 2011
    …pace read
    
    This reintroduces commit 47970b1 which was subsequently reverted
    as f00eaee.  The original change was broken and caused X startup
    failures and generally made privileged processes incapable of reading
    device dependent config space.  The normal capable() interface returns
    true on success, but the LSM interface returns 0 on success.  This thinko
    is now fixed in this patch, and has been confirmed to work properly.
    
    So, once again...Eric Paris noted that commit de139a3 ("pci: check caps
    from sysfs file open to read device dependent config space") caused the
    capability check to bypass security modules and potentially auditing.
    Rectify this by calling security_capable() when checking the open file's
    capabilities for config space reads.
    
    Reported-by: Eric Paris <eparis@redhat.com>
    Tested-by: Dave Young <hidave.darkstar@gmail.com>
    Acked-by: James Morris <jmorris@namei.org>
    Cc: Dave Airlie <airlied@gmail.com>
    Cc: Alex Riesen <raa.lkml@gmail.com>
    Cc: Sedat Dilek <sedat.dilek@googlemail.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: James Morris <jmorris@namei.org>
Commits on Feb 11, 2011
  1. pci: use security_capable() when checking capablities during config s…

    chriswright authored and James Morris committed Feb 10, 2011
    …pace read
    
    Eric Paris noted that commit de139a3 ("pci: check caps from sysfs file
    open to read device dependent config space") caused the capability check
    to bypass security modules and potentially auditing.  Rectify this by
    calling security_capable() when checking the open file's capabilities
    for config space reads.
    
    Reported-by: Eric Paris <eparis@redhat.com>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: James Morris <jmorris@namei.org>
  2. security: add cred argument to security_capable()

    chriswright authored and James Morris committed Feb 10, 2011
    Expand security_capable() to include cred, so that it can be usable in a
    wider range of call sites.
    
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
    Signed-off-by: James Morris <jmorris@namei.org>
Commits on Sep 10, 2010
  1. tracing: t_start: reset FTRACE_ITER_HASH in case of seek/pread

    chriswright authored and rostedt committed Sep 9, 2010
    Be sure to avoid entering t_show() with FTRACE_ITER_HASH set without
    having properly started the iterator to iterate the hash.  This case is
    degenerate and, as discovered by Robert Swiecki, can cause t_hash_show()
    to misuse a pointer.  This causes a NULL ptr deref with possible security
    implications.  Tracked as CVE-2010-3079.
    
    Cc: Robert Swiecki <swiecki@google.com>
    Cc: Eugene Teo <eugene@redhat.com>
    Cc: <stable@kernel.org>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Commits on Aug 11, 2010
  1. blkdev: cgroup whitelist permission fix

    chriswright authored and torvalds committed Aug 11, 2010
    The cgroup device whitelist code gets confused when trying to grant
    permission to a disk partition that is not currently open.  Part of
    blkdev_open() includes __blkdev_get() on the whole disk.
    
    Basically, the only ways to reliably allow a cgroup access to a partition
    on a block device when using the whitelist are to 1) also give it access
    to the whole block device or 2) make sure the partition is already open in
    a different context.
    
    The patch avoids the cgroup check for the whole disk case when opening a
    partition.
    
    Addresses https://bugzilla.redhat.com/show_bug.cgi?id=589662
    
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Acked-by: Serge E. Hallyn <serue@us.ibm.com>
    Tested-by: Serge E. Hallyn <serue@us.ibm.com>
    Reported-by: Vivek Goyal <vgoyal@redhat.com>
    Cc: Al Viro <viro@ZenIV.linux.org.uk>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: "Daniel P. Berrange" <berrange@redhat.com>
    Cc: <stable@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commits on May 21, 2010
  1. pci: check caps from sysfs file open to read device dependent config …

    chriswright authored and gregkh committed May 13, 2010
    …space
    
    The PCI config space bin_attr read handler has a hardcoded CAP_SYS_ADMIN
    check to verify privileges before allowing a user to read device
    dependent config space.  This is meant to protect from an unprivileged
    user potentially locking up the box.
    
    When assigning a PCI device directly to a guest with libvirt and KVM,
    the sysfs config space file is chown'd to the unprivileged user that
    the KVM guest will run as.  The guest needs to have full access to the
    device's config space since it's responsible for driving the device.
    However, despite being the owner of the sysfs file, the CAP_SYS_ADMIN
    check will not allow read access beyond the config header.
    
    With this patch we check privileges against the capabilities used when
    openining the sysfs file.  The allows a privileged process to open the
    file and hand it to an unprivileged process, and the unprivileged process
    can still read all of the config space.
    
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  2. sysfs: add struct file* to bin_attr callbacks

    chriswright authored and gregkh committed May 13, 2010
    This allows bin_attr->read,write,mmap callbacks to check file specific data
    (such as inode owner) as part of any privilege validation.
    
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Commits on May 16, 2010
  1. rtnetlink: make SR-IOV VF interface symmetric

    chriswright authored and davem330 committed May 16, 2010
    Now we have a set of nested attributes:
    
      IFLA_VFINFO_LIST (NESTED)
        IFLA_VF_INFO (NESTED)
          IFLA_VF_MAC
          IFLA_VF_VLAN
          IFLA_VF_TX_RATE
    
    This allows a single set to operate on multiple attributes if desired.
    Among other things, it means a dump can be replayed to set state.
    
    The current interface has yet to be released, so this seems like
    something to consider for 2.6.34.
    
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
Commits on Apr 7, 2010
  1. x86/amd-iommu: use for_each_pci_dev

    chriswright authored and Joerg Roedel committed Apr 3, 2010
    Replace open coded version with for_each_pci_dev
    
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
  2. Revert "x86: disable IOMMUs on kernel crash"

    chriswright authored and Joerg Roedel committed Apr 3, 2010
    This effectively reverts commit 61d047b.
    
    Disabling the IOMMU can potetially allow DMA transactions to
    complete without being translated.  Leave it enabled, and allow
    crash kernel to do the IOMMU reinitialization properly.
    
    Cc: stable@kernel.org
    Cc: Joerg Roedel <joerg.roedel@amd.com>
    Cc: Eric Biederman <ebiederm@xmission.com>
    Cc: Neil Horman <nhorman@tuxdriver.com>
    Cc: Vivek Goyal <vgoyal@redhat.com>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
  3. x86/amd-iommu: warn when issuing command to uninitialized cmd buffer

    chriswright authored and Joerg Roedel committed Apr 3, 2010
    To catch future potential issues we can add a warning whenever we issue
    a command before the command buffer is fully initialized.
    
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
  4. x86/amd-iommu: enable iommu before attaching devices

    chriswright authored and Joerg Roedel committed Apr 3, 2010
    Hit another kdump problem as reported by Neil Horman.  When initializaing
    the IOMMU, we attach devices to their domains before the IOMMU is
    fully (re)initialized.  Attaching a device will issue some important
    invalidations.  In the context of the newly kexec'd kdump kernel, the
    IOMMU may have stale cached data from the original kernel.  Because we
    do the attach too early, the invalidation commands are placed in the new
    command buffer before the IOMMU is updated w/ that buffer.  This leaves
    the stale entries in the kdump context and can renders device unusable.
    Simply enable the IOMMU before we do the attach.
    
    Cc: stable@kernel.org
    Cc: Neil Horman <nhorman@tuxdriver.com>
    Cc: Vivek Goyal <vgoyal@redhat.com>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Commits on Mar 1, 2010
  1. x86/amd-iommu: Pt mode fix for domain_destroy

    chriswright authored and Joerg Roedel committed Feb 17, 2010
    After a guest is shutdown, assigned devices are not properly
    returned to the pt domain.  This can leave the device using
    stale cached IOMMU data, and result in a non-functional
    device after it's re-bound to the host driver.  For example,
    I see this upon rebinding:
    
     AMD-Vi: Event logged [IO_PAGE_FAULT device=02:00.0 domain=0x0000 address=0x000000007e2a8000 flags=0x0050]
     AMD-Vi: Event logged [IO_PAGE_FAULT device=02:00.0 domain=0x0000 address=0x000000007e2a8040 flags=0x0050]
     AMD-Vi: Event logged [IO_PAGE_FAULT device=02:00.0 domain=0x0000 address=0x000000007e2a8080 flags=0x0050]
     AMD-Vi: Event logged [IO_PAGE_FAULT device=02:00.0 domain=0x0000 address=0x000000007e2a80c0 flags=0x0050]
     0000:02:00.0: eth2: Detected Hardware Unit Hang:
     ...
    
    The amd_iommu_destroy_domain() function calls do_detach()
    which doesn't reattach the pt domain to the device.
    Use __detach_device() instead.
    
    Cc: stable@kernel.org
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Commits on Dec 8, 2009
  1. intel-iommu: ignore page table validation in pass through mode

    chriswright authored and dwmw2 committed Dec 2, 2009
    We are seeing a bug when booting w/ iommu=pt with current upstream
    (bisect blames 19943b0 "intel-iommu:
    Unify hardware and software passthrough support).
    
    The issue is specific to this loop during identity map initialization
    of each device:
    
    domain_context_mapping_one(si_domain, ..., CONTEXT_TT_PASS_THROUGH)
    ...
    		/* Skip top levels of page tables for
    		* iommu which has less agaw than default.
    		*/
    		for (agaw = domain->agaw; agaw != iommu->agaw; agaw--) {
    			pgd = phys_to_virt(dma_pte_addr(pgd));
    			if (!dma_pte_present(pgd)) {      <------ failing here
    				spin_unlock_irqrestore(&iommu->lock, flags);
    			return -ENOMEM;
    		}
    
    This box has 2 iommu's in it.  The catchall iommu has MGAW == 48, and
    SAGAW == 4.  The other iommu has MGAW == 39, SAGAW == 2.
    
    The device that's failing the above pgd test is the only device connected
    to the non-catchall iommu, which has a smaller address width than the
    domain default.  This test is not necessary since the context is in PT
    mode and the ASR is ignored.
    
    Thanks to Don Dutile for discovering and debugging this one.
    
    Cc: stable@kernel.org
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
  2. intel-iommu: Detect DMAR in hyperspace at probe time.

    chriswright authored and dwmw2 committed Dec 2, 2009
    Many BIOSes will lie to us about the existence of an IOMMU, and claim
    that there is one at an address which actually returns all 0xFF.
    
    We need to detect this early, so that we know we don't have a viable
    IOMMU and can set up swiotlb before it's too late.
    
    Cc: stable@kernel.org
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Commits on Dec 5, 2009
  1. PCI: add pci_request_acs

    chriswright authored and jbarnes993 committed Dec 4, 2009
    Commit ae21ee6 "PCI: acs p2p upsteram
    forwarding enabling" doesn't actually enable ACS.
    
    Add a function to pci core to allow an IOMMU to request that ACS
    be enabled.  The existing mechanism of using iommu_found() in the pci
    core to know when ACS should be enabled doesn't actually work due to
    initialization order;  iommu has only been detected not initialized.
    
    Have Intel and AMD IOMMUs request ACS, and Xen does as well during early
    init of dom0.
    
    Cc: Allen Kay <allen.m.kay@intel.com>
    Cc: David Woodhouse <dwmw2@infradead.org>
    Cc: Jeremy Fitzhardinge <jeremy@goop.org>
    Cc: Joerg Roedel <joerg.roedel@amd.com>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Commits on Aug 30, 2009
  1. PCI SR-IOV: correct broken resource alignment calculations

    chriswright authored and jbarnes993 committed Aug 28, 2009
    An SR-IOV capable device includes an SR-IOV PCIe capability which
    describes the Virtual Function (VF) BAR requirements.  A typical SR-IOV
    device can support multiple VFs whose BARs must be in a contiguous region,
    effectively an array of VF BARs.  The BAR reports the size requirement
    for a single VF.  We calculate the full range needed by simply multiplying
    the VF BAR size with the number of possible VFs and create a resource
    spanning the full range.
    
    This all seems sane enough except it artificially inflates the alignment
    requirement for the VF BAR.  The VF BAR need only be aligned to the size
    of a single BAR not the contiguous range of VF BARs.  This can cause us
    to fail to allocate resources for the BAR despite the fact that we
    actually have enough space.
    
    This patch adds a thin PCI specific layer over the generic
    resource_alignment() function which is aware of the special nature of
    VF BARs and does sorting and allocation based on the smaller alignment
    requirement.
    
    I recognize that while resource_alignment is generic, it's basically a
    PCI helper.  An alternative to this patch is to add PCI VF BAR specific
    information to struct resource.  I opted for the extra layer rather than
    adding such PCI specific information to struct resource.  This does
    have the slight downside that we don't cache the BAR size and re-read
    for each alignment query (happens a small handful of times during boot
    for each VF BAR).
    
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Matthew Wilcox <matthew@wil.cx>
    Cc: Yu Zhao <yu.zhao@intel.com>
    Cc: stable@kernel.org
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Commits on Jun 16, 2009
  1. amd-iommu: resume cleanup

    chriswright authored and Joerg Roedel committed Jun 16, 2009
    Now that enable_iommus() will call iommu_disable() for each iommu,
    the call to disable_iommus() during resume is redundant.  Also, the order
    for an invalidation is to invalidate device table entries first, then
    domain translations.
    
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Commits on Jun 15, 2009
  1. amd-iommu: disable cmd buffer and evt logging before reprogramming iommu

    chriswright authored and Joerg Roedel committed Jun 15, 2009
    The IOMMU spec states that IOMMU behavior may be undefined when the
    IOMMU registers are rewritten while command or event buffer is enabled.
    Disable them in IOMMU disable path.
    
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
  2. amd-iommu: flush domain tlb when attaching a new device

    chriswright authored and Joerg Roedel committed Jun 15, 2009
    When kexec'ing to a new kernel (for example, when crashing and launching
    a kdump session), the AMD IOMMU may have cached translations.  The kexec'd
    kernel, during initialization, will invalidate the IOMMU device table
    entries, but not the domain translations.  These stale entries can cause
    a device's DMA to fail, makes it rough to write a dump to disk when the
    disk controller can't DMA ;-)
    
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Commits on Jun 10, 2009
  1. KVM: Trivial format fix in setup_routing_entry()

    chriswright authored and Avi Kivity committed May 1, 2009
    Remove extra tab.
    
    Signed-off-by: Chris Wright <chrisw@redhat.com>
    Signed-off-by: Avi Kivity <avi@redhat.com>
Commits on May 28, 2009
  1. amd iommu: properly detach from protection domain on ->remove

    chriswright authored and Joerg Roedel committed May 21, 2009
    Some drivers may use the dma api during ->remove which will
    cause a protection domain to get reattached to a device.  Delay the
    detach until after the driver is completely unbound.
    
    [ joro: added a little merge helper ]
    
    [ Impact: fix too early device<->domain removal ]
    
    Signed-off-by: Chris Wright <chrisw@redhat.com>
    Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Commits on May 14, 2009
  1. intel-iommu: dmar_set_interrupt return error value

    chriswright authored and dwmw2 committed May 13, 2009
    dmar_set_interrupt feigns success when arch_setup_dmar_msi
    fails, return error value.
    
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Commits on May 6, 2009
  1. cfg80211: remove superfluous !last_request check in reg_device_remove()

    chriswright authored and linvjw committed Apr 24, 2009
    Commit 0ad8aca "cfg80211: fix NULL pointer deference in
    reg_device_remove()" added a check that last_request is non-NULL,
    rendering the 2nd check superfluous.  While there, rearrange the code a
    bit so it's a little more straight forward.
    
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commits on Apr 24, 2009
  1. x86: use native register access for native tlb flushing

    chriswright authored and rostedt committed Apr 23, 2009
    currently these are paravirtulaized, doesn't appear any callers rely on
    this (no pv_ops backends are using native_tlb and overriding cr3/4
    access).
    
    [ Impact: fix lockdep warning with paravirt and function tracer ]
    
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    LKML-Reference: <20090423172138.GR3036@sequoia.sous-sol.org>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Commits on Apr 22, 2009
  1. drm/i915: fix up error path leak in i915_cmdbuffer

    chriswright authored and anholt committed Apr 17, 2009
    Commit 201361a introduces a leak when unwinding on error.  Reorder
    unwind, and eliminate leak.
    
    Cc: Eric Anholt <eric@anholt.net>
    Cc: Keith Packard <keithp@keithp.com>
    Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    [anholt: fixed uninit variable use introduced in original patch]
    Signed-off-by: Eric Anholt <eric@anholt.net>
Commits on Mar 20, 2009
  1. PCI: add remove_id sysfs entry

    chriswright authored and jbarnes993 committed Feb 24, 2009
    This adds a remove_id sysfs entry to allow users of new_id to later
    remove the added dynid.  One use case is management tools that want to
    dynamically bind/unbind devices to pci-stub driver while devices are
    assigned to KVM guests.  Rather than having to track which driver was
    originally bound to the driver, a mangement tool can simply:
    
    Guest uses device
    
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Commits on Feb 24, 2009
  1. PCI: add some sysfs ABI docs

    chriswright authored and Jesse Barnes committed Feb 24, 2009
    Add sysfs ABI docs for driver entries bind, unbind and new_id.  These
    entries are pretty old, from 2.6.0 onwards AFAIK, so this documents
    current behaviour.
    
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Jesse Barnes <jbarnes@hobbes.lan>