From: Matt Mackall <mpm@selenic.com>
To: linux-kernel@vger.kernel.org
Cc: s0be <s0be@DrunkenCodePoets.com>
Subject: handle_vm86_fault may fault? was Re: Kernel Oops in 2.6.0-test2-mm4
Date: Tue, 5 Aug 2003 21:54:50 -0500 [thread overview]
Message-ID: <20030806025450.GA31810@waste.org> (raw)
In-Reply-To: <20030805201056.2b8c9f22.s0be@DrunkenCodePoets.com>
On Tue, Aug 05, 2003 at 08:10:56PM -0400, s0be wrote:
> On Tue, 5 Aug 2003 19:05:24 -0500
> Matt Mackall <mpm@selenic.com> wrote:
>
> > On Tue, Aug 05, 2003 at 05:05:58PM -0400, s0be wrote:
> > > here's the oops from dmesg and the surrounding messages. I'm guessing it was caused by smb, but I can't confirm it. trying to recreate it.
> ..snip..
> > > Debug: sleeping function called from invalid context at include/asm/uaccess.h:512Call Trace:
> > > [<c011fd3c>] __might_sleep+0x5c/0x5e
> > > [<c010da1a>] save_v86_state+0x6a/0x200
> > > [<c010e565>] handle_vm86_fault+0xa5/0x8c0
> > > [<c0170a23>] dput+0x23/0x200
> > > [<c010c030>] do_general_protection+0x0/0xa0
> > > [<c032519f>] error_code+0x2f/0x38
> > > [<c0324733>] syscall_call+0x7/0xb
> ..snip..
> >
> > This is not an oops, just a debug trace that says something tried to
> > do something unsafe (namely calling copy_from_user while in_atomic()
> > was true).
> >
> > Looks like we've got:
> >
> > do_general_protection
> > handle_vm86_fault
> > return_to_32bit
> > save_v86_state
> > copy_to_user
> >
> > and the destination of the copy is current->thread.vm86_info->regs,
> > which is labelled __user. Presuming this is actually in userspace,
> > this could be a problem.
> >
>
> I'd have to agree. I wrote a script that sits here mounting a samba
> mount, then, either writing to it, and unmount, write to it and
> no,unmount, just unmount it, or nothing, pseudo randomly, and it
> pissed off my windows machine it was connecting to, but could NOT
> reproduce this problem. I can't seem to get it to happen again
> though. I'm sort of at a loss. I can provide any extra info that
> might help.
This appears to be a video driver running a card's video BIOS in vm86
mode and hitting one of many possible faults. The fault handler saves
a subset of the state to userspace with copy_to_user. This could
potentially cause a second fault and I don't see any guarantees that
this page is locked or anything.
So a) is this safe, somehow? And b) if so, what check can might_sleep use
to avoid false positives?
--
Matt Mackall : http://www.selenic.com : of or relating to the moon
prev parent reply other threads:[~2003-08-06 2:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-05 21:05 Kernel Oops in 2.6.0-test2-mm4 s0be
2003-08-06 0:05 ` Matt Mackall
2003-08-06 0:10 ` s0be
2003-08-06 2:54 ` Matt Mackall [this message]
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=20030806025450.GA31810@waste.org \
--to=mpm@selenic.com \
--cc=linux-kernel@vger.kernel.org \
--cc=s0be@DrunkenCodePoets.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox