Re: radeon_cp_texture: page fault with non-sleepable locks held

From: Kostik Belousov <kostikbel_at_gmail.com>
Date: Tue, 9 Nov 2010 16:05:18 +0200
On Tue, Nov 09, 2010 at 11:25:49AM +0200, Andriy Gapon wrote:
> on 08/11/2010 14:04 Kostik Belousov said the following:
> > On Mon, Nov 08, 2010 at 01:50:25PM +0200, Andriy Gapon wrote:
> >> on 05/11/2010 09:27 Andriy Gapon said the following:
> >>>
> >>> I use FreeSBD head and KDE 4 with all the bells and whistles enabled.
> >>> Apparently recent KDE update has enabled even more of them, because I started to
> >>> have panics with a kernel that has INVARIANTS and WITNESS enabled.
> >>
> >> I tried to solve the problem by changing drmdev from mutex to sx:
> >> http://people.freebsd.org/~avg/drm-sx.diff
> > I remember that drm lock can be acquired from the interrupt thread, if
> > the card supports interrupts. Changing it to sx cannot work then, because
> > interrupt threads cannot sleep. Most likely, you are getting around it
> > since r600 not yet used interrupts on FreeBSD.
> > 
> > I think the solution is to drop drm lock around copyin.
> 
> Kostik,
> 
> I looked at this some more and now I think that using sx is a step in the right
> direction.
> 
> Rationale:
> 1. it seems that on Linux mutex is a sleepable lock and thus can be safely held
> across a page fault; and Linux mutex -> FreeBSD sx seems to be a porting
> technique used for kernel code before[*].
> 2. DRM interrupt code uses a different lock - irq_lock, which is locked via
> DRM_SPINLOCK macro (expands to FreeBSD mutex); apparently even on Linux a
"even on Linux". Heh.

> sleep-able lock can't be acquired in interrupt handler.
> 
> I use Linux this and Linux that as a justification, because the DRM code
> apparently originated with Linux model/idioms in mind, although the original
> purpose was for the code to be portable.
> 
> So, what do you think about this aspect?
> Should you agree with the usage of sx, then the previous question pops back -
I do not agree.

> how to resolve the lock order reversal between drmdev lock and user map lock
> (which both would be sx).
Easiest would be for DRM to provide wrappers for copyin/copyout that
unlock, do operation and lock.

Where is the reverse order (user map -> drm) ?
> 
> [*] http://www.ukuug.org/events/eurobsdcon2009/papers/dvb_driver_paper.pdf
> -- 
> Andriy Gapon

Received on Tue Nov 09 2010 - 13:05:22 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:09 UTC