1. 17 2月, 2010 2 次提交
  2. 12 2月, 2010 7 次提交
  3. 11 2月, 2010 23 次提交
  4. 10 2月, 2010 7 次提交
    • N
      md: fix some lockdep issues between md and sysfs. · ef286f6f
      NeilBrown 提交于
      ======
      This fix is related to
          http://bugzilla.kernel.org/show_bug.cgi?id=15142
      but does not address that exact issue.
      ======
      
      sysfs does like attributes being removed while they are being accessed
      (i.e. read or written) and waits for the access to complete.
      
      As accessing some md attributes takes the same lock that is held while
      removing those attributes a deadlock can occur.
      
      This patch addresses 3 issues in md that could lead to this deadlock.
      
      Two relate to calling flush_scheduled_work while the lock is held.
      This is probably a bad idea in general and as we use schedule_work to
      delete various sysfs objects it is particularly bad.
      
      In one case flush_scheduled_work is called from md_alloc (called by
      md_probe) called from do_md_run which holds the lock.  This call is
      only present to ensure that ->gendisk is set.  However we can be sure
      that gendisk is always set (though possibly we couldn't when that code
      was originally written.  This is because do_md_run is called in three
      different contexts:
        1/ from md_ioctl.  This requires that md_open has succeeded, and it
           fails if ->gendisk is not set.
        2/ from writing a sysfs attribute.  This can only happen if the
           mddev has been registered in sysfs which happens in md_alloc
           after ->gendisk has been set.
        3/ from autorun_array which is only called by autorun_devices, which
           checks for ->gendisk to be set before calling autorun_array.
      So the call to md_probe in do_md_run can be removed, and the check on
      ->gendisk can also go.
      
      
      In the other case flush_scheduled_work is being called in do_md_stop,
      purportedly to wait for all md_delayed_delete calls (which delete the
      component rdevs) to complete.  However there really isn't any need to
      wait for them - they have already been disconnected in all important
      ways.
      
      The third issue is that raid5->stop() removes some attribute names
      while the lock is held.  There is already some infrastructure in place
      to delay attribute removal until after the lock is released (using
      schedule_work).  So extend that infrastructure to remove the
      raid5_attrs_group.
      
      This does not address all lockdep issues related to the sysfs
      "s_active" lock.  The rest can be address by splitting that lockdep
      context between symlinks and non-symlinks which hopefully will happen.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      ef286f6f
    • M
      drm/nv50: make the pgraph irq handler loop like the pre-nv50 version · b1d37aa0
      Maarten Maathuis 提交于
      Unset the bit that indicates that a ctxprog can continue at the end.
      Signed-off-by: NMaarten Maathuis <madman2003@gmail.com>
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      b1d37aa0
    • M
      drm/nv50: delete ramfc object after disabling fifo, not before · a87ff62a
      Maarten Maathuis 提交于
      ramfc is zero'ed upon destruction, so it's safer to do things in the right
      order.
      Signed-off-by: NMaarten Maathuis <madman2003@gmail.com>
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      a87ff62a
    • M
      drm/nv50: avoid unloading pgraph context when ctxprog is running · a51a3bf5
      Maarten Maathuis 提交于
      - We need to disable pgraph fifo access before checking the current channel,
        otherwise we could still hit a running ctxprog.
      - The writes to 0x400500 are already handled by pgraph->fifo_access and are
        therefore redundant, moreover pgraph fifo access should not be reenabled
        before current context is set as invalid. So remove them altogether.
      Signed-off-by: NMaarten Maathuis <madman2003@gmail.com>
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      a51a3bf5
    • M
      drm/nv50: align size of buffer object to the right boundaries. · eb1dba0e
      Maarten Maathuis 提交于
      - In the current situation the padding that is added is dangerous to write
        to, userspace could potentially overwrite parts of another bo.
      - Depth and stencil buffers are supposed to be large enough in general so
        the waste of memory should be acceptable.
      - Alternatives are hiding the padding from users or splitting vram into 2
        zones.
      Signed-off-by: NMaarten Maathuis <madman2003@gmail.com>
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      eb1dba0e
    • B
      drm/nv50: disregard dac outputs in nv50_sor_dpms() · 5025b431
      Ben Skeggs 提交于
      Fixes DVI+VGA on my 9400, and likely a lot of other configurations that
      got broken by the previos DVI-over-DP fix.
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      5025b431
    • B
      drm/nv50: prevent multiple init tables being parsed at the same time · 39c9bfb4
      Ben Skeggs 提交于
      With DVI and DP plugged, the DVI clock change interrupts being run can
      cause DP link training to fail.  This adds a spinlock around init table
      parsing to prevent this.
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      39c9bfb4
  5. 09 2月, 2010 1 次提交