Kernel Oops in 2.6.0-test2-mm4

DISCUSSION s0be 2 participants 4 messages Aug 5, 2003 – Aug 6, 2003

Share & tools

s0be

author

2003-08-05 21:09 UTC #0 lore raw

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

Matt Mackall

2003-08-06 00:05 UTC #1 lore raw

Quoted 19 lines · 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

Quoted 3 lines

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.

Signature · 1 line

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

s0be

author

2003-08-06 00:14 UTC #2 lore raw

Quoted 2 lines · On Tue, 5 Aug 2003 19:05:24 -0500 Matt Mackall <[email protected]> wrote:

Quoted 1 line · 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..

Quoted 8 lines

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..

Quoted 12 lines

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

Quoted 14 lines

    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.
Signature · 6 lines
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 [email protected]
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

Matt Mackall

2003-08-06 02:57 UTC #3 lore raw

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

Quoted 33 lines · On Tue, Aug 05, 2003 at 08:10:56PM -0400, s0be wrote:

Quoted 2 lines · On Tue, 5 Aug 2003 19:05:24 -0500 Matt Mackall <[email protected]> wrote:
Quoted 1 line · 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..
Quoted 8 lines
Quoted 8 lines
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..
Quoted 10 lines
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
Quoted 7 lines
    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.

Quoted 7 lines

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?

Signature · 1 line

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