From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755855Ab1JNGa0 (ORCPT ); Fri, 14 Oct 2011 02:30:26 -0400 Received: from mail-wy0-f174.google.com ([74.125.82.174]:63015 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755520Ab1JNGaV convert rfc822-to-8bit (ORCPT ); Fri, 14 Oct 2011 02:30:21 -0400 MIME-Version: 1.0 In-Reply-To: References: <20111010114840.GC17079@elte.hu> <20111011062253.GA3589@elte.hu> <4E947BC9.7040805@mit.edu> From: Andrew Lutomirski Date: Thu, 13 Oct 2011 23:30:00 -0700 X-Google-Sender-Auth: o9ViDaGwuNTh23ocJy7Pg7sLbVY Message-ID: Subject: Re: [RFC] fixing the UML failure root cause To: Linus Torvalds Cc: Ingo Molnar , richard -rw- weinberger , Adrian Bunk , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , x86@kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 13, 2011 at 9:46 PM, Linus Torvalds wrote: > On Thu, Oct 13, 2011 at 8:40 PM, Andrew Lutomirski wrote: >> >> How does that work?  The tricky case is when one of those three words >> spans a page boundary if the access to the first page is valid, but >> the access to the second page is not.  When that happens, if we report >> the fault as coming from the first page, then UML is likely to get >> think the fault was spurious and enter an infinite loop. > > Hmm. Gaah, I just find that memcpy loop disgusting. > Yeah, it's not pretty. > We already have that ugly "uaccess_error" crap in handle_exception(), > we might as well do something like the attached and just say "hey, now > you can catch the page fault information for a get_user/put_user > fault". > > Isn't that much nicer? I actually tried this. To really get it right, though, I also need to either hook the access_ok failure paths (either every single one or just the ones that matter for those three syscalls, which could be fragile) or to check access_ok separately in the vsyscall emulation code. This also takes up 16 bytes of stack just to support a corner case of a legacy code path. Another idea is to have a flag that asks the fault handlers to call force_sig_info for us. That's just one bit of per-thread state. Then the vsyscall emulation code could check access_ok, force a signal if access is not ok, then set the flag and do the syscall. And maybe some processes would want to opt in to that mode anyway -- arguably EFAULT is a serious programmer error and should be dealt with more harshly than other syscall misuses. Admittedly, UML probably doesn't care about recovering vgettimeofday pointed at kernel space... --Andy