Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752063Ab1EEBSP (ORCPT ); Wed, 4 May 2011 21:18:15 -0400 Received: from smtp-out.google.com ([74.125.121.67]:61976 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751252Ab1EEBSO (ORCPT ); Wed, 4 May 2011 21:18:14 -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; b=Wz0GcTFH0cs+Pbrd5A/ZDBsPEVjITAtauLQcj236FKPQzKxv7OE0GlCtov0id5bv4F vnkFNK+5ze2HSdZQkRuA== MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 4 May 2011 18:18:09 -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 X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2054 Lines: 44 On Wed, May 4, 2011 at 5:38 PM, Linus Torvalds wrote: >> 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... > > How about only doing that only for FOLL_MLOCK? Sounds reasonable. > Also, looking at mm/mlock.c, why _do_ we call get_user_pages() even if > the vma isn't mlocked? That looks bogus. Since we have dropped the > mm_semaphore, an unlock may have happened, and afaik we should *not* > try to bring those pages back in at all. There's this whole comment > about that in the caller ("__mlock_vma_pages_range() double checks the > vma flags, so that it won't mlock pages if the vma was already > munlocked."), but despite that it would actually call > __get_user_pages() even if the VM_LOCKED bit had been cleared (it just > wouldn't call it with the FOLL_MLOCK flag). There are two reasons VM_LOCKED might be cleared in __mlock_vma_pages_range(). It could be that one of the VM_SPECIAL flags were set on the VMA, in which case mlock() won't set VM_LOCKED but it still must make the pages present. Or, there is an munlock() executing concurrently with mlock() - in that case, the conservative thing to do is to give the same results as if the mlock() had completed before the munlock(). That is, the mlock() would have broken COW / made the pages present and the munlock() would have cleared the VM_LOCKED and PageMlocked flags. > UNTESTED! And maybe there was some really subtle reason to still call > __get_user_pages() without that FOLL_MLOCK thing that I'm missing. I think we want the mm/memory.c part of this proposal without the mm/mlock.c part. -- 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/