Messages in this thread | | | Date | Mon, 18 Aug 2003 23:26:44 -0500 | From | Matt Mackall <> | Subject | Re: Debug: sleeping function called from invalid context |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |