linux-kernel - [git pull] drm fixes for linux-2.6.25-rc6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Mon, 17 Mar 2008 00:36:55 +0000 (GMT)
From:	Dave Airlie <airlied@...ux.ie>
To:	torvalds@...ux-foundation.org,
	Andrew Morton <akpm@...ux-foundation.org>
cc:	linux-kernel@...r.kernel.org, dri-devel@...ts.sf.net
Subject: [git pull] drm fixes for linux-2.6.25-rc6


Hi Linus,

Please pull the 'drm-fixes' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes

Sorry this is so late, but a number of things cropped up in the last week 
I thought were urgent enough to get into 2.6.25 final.

The PCI GART changes should fix
'2.6.25-rc3 + RS690 + DRM + xf86-video-ati hang'

The VIA fixes are for a number of upstream bugs, along with the pci ids 
fixups so we work properly on a new series of ATI cards.

Dave.

 drivers/char/drm/ati_pcigart.c |   91 ++++++++++------------------------------
 drivers/char/drm/drmP.h        |    3 +
 drivers/char/drm/drm_fops.c    |    7 ++-
 drivers/char/drm/drm_lock.c    |   35 +++++++++-------
 drivers/char/drm/drm_pciids.h  |    7 ++-
 drivers/char/drm/r128_cce.c    |    1 +
 drivers/char/drm/radeon_cp.c   |    1 +
 drivers/char/drm/via_dma.c     |   59 +++++++++++++++++++++++---
 drivers/char/drm/via_dmablit.c |    2 +-
 9 files changed, 110 insertions(+), 96 deletions(-)

commit b05c23851ab820b1957cd2f322eaa1ac44c196bd
Author: Dave Airlie <airlied@...hat.com>
Date:   Mon Mar 17 10:24:24 2008 +1000

    drm/ati_pcigart: fix the PCIGART to use drm_pci to allocate GART table.
    
    This fixes a problem on 64-bit with 4GB with ATI RS690 chipsets. It
    makes sure the pcigart table is allocated in coherent memory for DMA operations.
    
    Signed-off-by: Dave Airlie <airlied@...hat.com>

commit 16d3be46d9ffbc2c562b25d66d59666db2cf2cd5
Author: Alex Deucher <alexdeucher@...il.com>
Date:   Mon Mar 17 10:22:12 2008 +1000

    drm/radeon: fixup RV550 chip family
    
    This fixes up the RV550 chips which are based on RV515, not RV530.
    It also adds another RS690 PCI ID.
    
    Signed-off-by: Dave Airlie <airlied@...hat.com>

commit f0fb6d7798e7e2d1f37a2c15892910661bdaba55
Author: Thomas Hellstrom <thomas-at-tungstengraphics-dot-com>
Date:   Mon Mar 17 10:07:20 2008 +1000

    drm/via: attempt again to stabilise the AGP DMA command submission.
    
    It's worth remembering that all new bright ideas on how to make this command reader work properly and according to docs will probably fail :( Bring in some old code.
    
    Also allow a larger SG-DMA download stride, and remove unnecessary waits for
    command regulators pauses.
    
    Signed-off-by: Dave Airlie <airlied@...hat.com>

commit 9df5808cca52f33e1deb52b5010c68c6ed1656fe
Author: Mike Isely <isely@...ly.net>
Date:   Thu Mar 13 15:30:35 2008 -0500

    drm: Fix race that can lockup the kernel
    
    The i915_vblank_swap() function schedules an automatic buffer swap
    upon receipt of the vertical sync interrupt.  Such an operation is
    lengthy so it can't be allowed to happen in normal interrupt context,
    thus the DRM implements this by scheduling the work in a kernel
    softirq-scheduled tasklet.  In order for the buffer swap to work
    safely, the DRM's central lock must be taken, via a call to
    drm_lock_take() located in drivers/char/drm/drm_irq.c within the
    function drm_locked_tasklet_func().  The lock-taking logic uses a
    non-interrupt-blocking spinlock to implement the manipulations needed
    to take the lock.  This semantic would be safe if all attempts to use
    the spinlock only happen from process context.  However this buffer
    swap happens from softirq context which is really a form of interrupt
    context.  Thus we have an unsafe situation, in that
    drm_locked_tasklet_func() can block on a spinlock already taken by a
    thread in process context which will never get scheduled again because
    of the blocked softirq tasklet.  This wedges the kernel hard.
    
    To trigger this bug, run a dual-head cloned mode configuration which
    uses the i915 drm, then execute an opengl application which
    synchronizes buffer swaps against the vertical sync interrupt.  In my
    testing, a lockup always results after running anywhere from 5 minutes
    to an hour and a half.  I believe dual-head is needed to really
    trigger the problem because then the vertical sync interrupt handling
    is no longer predictable (due to being interrupt-sourced from two
    different heads running at different speeds).  This raises the
    probability of the tasklet trying to run while the userspace DRI is
    doing things to the GPU (and manipulating the DRM lock).
    
    The fix is to change the relevant spinlock semantics to be the
    interrupt-blocking form.  After this change I am no longer able to
    trigger the lockup; the longest test run so far was 20 hours (test
    stopped after that point).
    
    Note: I have examined the places where this spinlock is being
    employed; all are reasonably short bounded sequences and should be
    suitable for interrupts being blocked without impacting overall kernel
    interrupt response latency.
    
    Signed-off-by: Mike Isely <isely@...ox.com>
    Signed-off-by: Dave Airlie <airlied@...hat.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/