Kernel Oops in 2.6.0-test2-mm4

Kernel Oops in 2.6.0-test2-mm4

[s0be]

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.

SMB connection re-established (-5)
smb_errno: class ERRSRV, code 91 from command 0x80
SMB connection re-established (-5)
smb_errno: class ERRSRV, code 91 from command 0x80
SMB connection re-established (-5)
smb_errno: class ERRSRV, code 91 from command 0x80
SMB connection re-established (-5)
smb_errno: class ERRSRV, code 91 from command 0x80
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

SMB connection re-established (-5)
smb_errno: class ERRSRV, code 91 from command 0x80
XFS mounting filesystem hda1

pat

-- 

Re: Kernel Oops in 2.6.0-test2-mm4

[Matt Mackall]

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.
> 
> SMB connection re-established (-5)
> smb_errno: class ERRSRV, code 91 from command 0x80
> SMB connection re-established (-5)
> smb_errno: class ERRSRV, code 91 from command 0x80
> SMB connection re-established (-5)
> smb_errno: class ERRSRV, code 91 from command 0x80
> SMB connection re-established (-5)
> smb_errno: class ERRSRV, code 91 from command 0x80
> 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
> 
> SMB connection re-established (-5)
> smb_errno: class ERRSRV, code 91 from command 0x80
> XFS mounting filesystem hda1

Actually, Samba seems unconnected.

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.

-- 
Matt Mackall : http://www.selenic.com : of or relating to the moon

Re: Kernel Oops in 2.6.0-test2-mm4

[s0be]

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..
> 
> Actually, Samba seems unconnected.
> 
> 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.
> 
> -- 
> 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/

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.

pat

-- 

handle_vm86_fault may fault? was Re: Kernel Oops in 2.6.0-test2-mm4

[Matt Mackall]

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