From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S274830AbTHFC5o (ORCPT ); Tue, 5 Aug 2003 22:57:44 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S274815AbTHFC5e (ORCPT ); Tue, 5 Aug 2003 22:57:34 -0400 Received: from waste.org ([209.173.204.2]:62667 "EHLO waste.org") by vger.kernel.org with ESMTP id S274830AbTHFCy5 (ORCPT ); Tue, 5 Aug 2003 22:54:57 -0400 Date: Tue, 5 Aug 2003 21:54:50 -0500 From: Matt Mackall To: linux-kernel@vger.kernel.org Cc: s0be Subject: handle_vm86_fault may fault? was Re: Kernel Oops in 2.6.0-test2-mm4 Message-ID: <20030806025450.GA31810@waste.org> References: <20030805170558.3ee38204.s0be@DrunkenCodePoets.com> <20030806000524.GC26701@waste.org> <20030805201056.2b8c9f22.s0be@DrunkenCodePoets.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030805201056.2b8c9f22.s0be@DrunkenCodePoets.com> User-Agent: Mutt/1.3.28i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 05, 2003 at 08:10:56PM -0400, s0be wrote: > On Tue, 5 Aug 2003 19:05:24 -0500 > Matt Mackall 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: > > > [] __might_sleep+0x5c/0x5e > > > [] save_v86_state+0x6a/0x200 > > > [] handle_vm86_fault+0xa5/0x8c0 > > > [] dput+0x23/0x200 > > > [] do_general_protection+0x0/0xa0 > > > [] error_code+0x2f/0x38 > > > [] 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