[lkml]   [2003]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Debug: sleeping function called from invalid context
On Mon, Aug 18, 2003 at 05:15:45PM -0700, Andrew Morton wrote:
> Dave Jones <> 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 : : of or relating to the moon
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:47    [W:0.074 / U:1.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site