Messages in this thread | | | Date | Mon, 18 Aug 2003 20:27:22 -0500 | From | Matt Mackall <> | Subject | Re: Debug: sleeping function called from invalid context |
| |
On Mon, Aug 18, 2003 at 05:15:45PM -0700, Andrew Morton wrote: > Dave Jones <davej@redhat.com> wrote: > > > > How spooky. now I got one too, (minus the noise). > > > > Call Trace: > > [<c0120022>] __might_sleep+0x5b/0x5f > > It would be useful to know whether this was triggered by in_atomic() or by > irqs_disabled(). We're suspecting the latter.
Everything points to it being a fault handler.
Here's my current understanding:
some part of X calls sys_vm86() sys_vm86 stashes pointer to userspace structure do_sys_vm86 fiddles with register structures to setup 16-bit transition do_sys_vm86 goes to 16-bit mode _through the userspace return path_ fault occurs in 16-bit code handle_vm86_fault invoked through interrupt save_v86_state writes into stashed userspace structure (might_sleep) return_to_32bit swaps register sets around return_to_32bit returns to the original userspace context
Because we never return to the context of the sys_vm86 syscall, we're never again in an appropriate place to copy the registers over. A cleaner way to do this is to setup return_to_32bit to return to the point just after where sys_vm86 returns to 16bit mode and copy the registers to userspace in normal process context.
-- 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/
| |