Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756307Ab1EEAJq (ORCPT ); Wed, 4 May 2011 20:09:46 -0400 Received: from smtp-out.google.com ([216.239.44.51]:32455 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756266Ab1EEAJn convert rfc822-to-8bit (ORCPT ); Wed, 4 May 2011 20:09:43 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bE7+MT0FVEB00EpBMAH2ANBUugF/rs95tpdDsiEU+hqSlJpT9KCYsVBl+puWNVL2bS FuxvIeeIbooW7n4mqNjQ== MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 4 May 2011 17:09:40 -0700 Message-ID: Subject: Re: [PATCH] mm: fix possible cause of a page_mapped BUG From: Michel Lespinasse To: Linus Torvalds Cc: =?UTF-8?B?Um9iZXJ0IMWad2nEmWNraQ==?= , Hugh Dickins , Andrew Morton , Miklos Szeredi , "Eric W. Biederman" , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Peter Zijlstra , Rik van Riel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2402 Lines: 67 FYI, the attached code causes an infinite loop in kernels that have the 95042f9eb7 commit: #include #include #include #include #include int *get_stack_guard(void) { FILE *map; char buf[1000]; map = fopen("/proc/self/maps", "r"); if (!map) return NULL; while(fgets(buf, 1000, map)) { long a, b; char c[1000], d[1000], e[1000], f[1000], g[1000]; if (sscanf(buf, "%lx-%lx %s %s %s %s %s", &a, &b, c, d, e, f, g) == 7 && !strcmp(g, "[stack]")) { fclose(map); return (int *)(a - 4096); } } fclose(map); return NULL; } int main(void) { int *uaddr = get_stack_guard(); syscall(SYS_futex, uaddr, FUTEX_LOCK_PI_PRIVATE, 0, NULL, NULL, 0); return 0; } Linus, I am not sure as to what would be the preferred way to fix this. One option could be to modify fault_in_user_writeable so that it passes a non-NULL page pointer, and just does a put_page on it afterwards. While this would work, this is kinda ugly and would slow down futex operations somewhat. A more conservative alternative could be to enable the guard page special case under an new GUP flag, but this loses much of the elegance of your original proposal... On Mon, Apr 18, 2011 at 2:15 PM, Michel Lespinasse wrote: > This second patch looks more attractive than the first, but is also > harder to prove correct. Hugh looked at all gup call sites and > convinced himself that the change was safe, except for the > fault_in_user_writeable() site in futex.c which he asked me to look > at. I am worried that we would have an issue there, as places like > futex_wake_op() or fixup_pi_state_owner() operate on user memory with > page faults disabled, and expect fault_in_user_writeable() to set up > the user page so that they can retry if the initial access failed. > With this proposal, fault_in_user_writeable() would become inoperative > when the ?address is within the guard page; this could cause some > malicious futex operation to create an infinite loop. -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- 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/