Re: Debug: sleeping function called from invalid context

[Matt Mackall <mpm@selenic.com>]

On Mon, Aug 18, 2003 at 08:39:29PM -0700, Randy.Dunlap wrote:
> > "Randy.Dunlap" <rddunlap@osdl.org> wrote:
> >>
> >> Debug: sleeping function called with interrupts disabled at
> >>  include/asm/uaccess.h:473
> >
> > OK, now my vague understanding of what's going on is that the app has chosen
> > to disable local interupts (via iopl()) and has taken a vm86 trap.  I guess
> > we'd see the same thing if the app performed some sleeping syscall while
> > interrupts are disabled.
> >
> > If that is correct then it really is just a false positive.
> >
> > It could also point at a bug in the application; it is presumably disabling
> > interrupts for some form of locking, atomicity or timing guarantee.  But it
> > will not lock against other CPUs and the fact that it trapped into the
> > kernel indicates tat it may not be getting the atomicity which it desires.
> 
> Call Trace:
>  [<c0120d93>] __might_sleep+0x53/0x74
>  [<c010d001>] save_v86_state+0x71/0x1f0
>  [<c010dbd5>] handle_vm86_fault+0xc5/0xa90
>  [<c019cac8>] ext3_file_write+0x28/0xc0
>  [<c011cd96>] __change_page_attr+0x26/0x220
>  [<c010b310>] do_general_protection+0x0/0x90
>  [<c010a69d>] error_code+0x2d/0x40
>  [<c0109657>] syscall_call+0x7/0xb
> 
> My (more) vague understanding is that X(?) got the kernel to
> do_general_protection() somehow, but change_page_attr() does this:
> 	spin_lock_irqsave(&cpa_lock, flags);
> in arch/i386/mm/pageattr.c (I'm on a UP box),
> so irqs are disabled by the kernel and then we calls put_user()
> with a spinlock held.

My suspicion is that the X driver (MGA, right?) copies its BIOS into
its address space, sets up io permissions for it to fiddle with your
card, and then calls sys_vm86 with the appropriate registers to call
into the interrupt handler when sys_vm86 swaps those registers in and
does "jmp resume_userspace". When the video BIOS software interrupt
handler does iret, we get the fault, copy the registers to our 32-bit
usermode (tripping might_sleep), and then swap the 32-bit registers
back in for another jump to resume_userspace.

The fix is making return_to_32_bit return back to the end of
do_sys_vm86 rather than straight to userspace, at which point we can
safely handle the registers.

-- 
Matt Mackall : http://www.selenic.com : of or relating to the moon