All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Mackall <mpm@selenic.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Dave Jones <davej@redhat.com>,
	rddunlap@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: Debug: sleeping function called from invalid context
Date: Mon, 18 Aug 2003 20:27:22 -0500	[thread overview]
Message-ID: <20030819012722.GH16387@waste.org> (raw)
In-Reply-To: <20030818171545.5aa630a0.akpm@osdl.org>

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

  reply	other threads:[~2003-08-19  1:28 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-15 17:18 Debug: sleeping function called from invalid context Randy.Dunlap
2003-08-15 17:32 ` Dave Jones
2003-08-15 17:42   ` Randy.Dunlap
2003-08-15 19:30   ` Randy.Dunlap
2003-08-16  7:06     ` Matt Mackall
2003-08-18 21:07       ` Randy.Dunlap
2003-08-18 21:26         ` Matt Mackall
2003-08-19  0:13         ` Dave Jones
2003-08-19  0:15           ` Randy.Dunlap
2003-08-19  1:02             ` Zwane Mwaikambo
2003-08-19  0:15           ` Andrew Morton
2003-08-19  1:27             ` Matt Mackall [this message]
2003-08-19  3:24             ` Randy.Dunlap
2003-08-19  3:35               ` Andrew Morton
2003-08-19  3:39                 ` Randy.Dunlap
2003-08-19  4:26                   ` Matt Mackall
2003-08-19  4:29                   ` Andrew Morton
2003-08-19  4:14                 ` Matt Mackall
2003-08-19  5:14                 ` Matt Mackall
2003-08-19  1:01           ` Matt Mackall
2003-08-19  1:04             ` Dave Jones
2003-08-19  1:09               ` Matt Mackall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030819012722.GH16387@waste.org \
    --to=mpm@selenic.com \
    --cc=akpm@osdl.org \
    --cc=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rddunlap@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.