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

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
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 -
how to resolve the lock order reversal between drmdev lock and user map lock
(which both would be sx).

[*] http://www.ukuug.org/events/eurobsdcon2009/papers/dvb_driver_paper.pdf
-- 
Andriy Gapon