Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752828Ab1EEAjH (ORCPT ); Wed, 4 May 2011 20:39:07 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:41145 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752465Ab1EEAjF (ORCPT ); Wed, 4 May 2011 20:39:05 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Linus Torvalds Date: Wed, 4 May 2011 17:38:40 -0700 Message-ID: Subject: Re: [PATCH] mm: fix possible cause of a page_mapped BUG To: Michel Lespinasse 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: multipart/mixed; boundary=0016e65b54cc6a992604a27c99d1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4174 Lines: 82 --0016e65b54cc6a992604a27c99d1 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 4, 2011 at 5:09 PM, Michel Lespinasse wrote: > > FYI, the attached code causes an infinite loop in kernels that have > the 95042f9eb7 commit: Mmm. Yes. The atomic fault will never work, and the get_user_pages() thing won't either, so things will just loop forever. > 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. No, that's just ugly as hell. > 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? 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). So maybe something like the attached? UNTESTED! And maybe there was some really subtle reason to still call __get_user_pages() without that FOLL_MLOCK thing that I'm missing. Linus --0016e65b54cc6a992604a27c99d1 Content-Type: text/x-patch; charset=US-ASCII; name="patch.diff" Content-Disposition: attachment; filename="patch.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gnayw6oc0 IG1tL21lbW9yeS5jIHwgICAgMiArLQogbW0vbWxvY2suYyAgfCAgICA4ICsrKystLS0tCiAyIGZp bGVzIGNoYW5nZWQsIDUgaW5zZXJ0aW9ucygrKSwgNSBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQg YS9tbS9tZW1vcnkuYyBiL21tL21lbW9yeS5jCmluZGV4IDYwNzA5OGQ0N2U3NC4uZjdhNDg3Yzkw OGE1IDEwMDY0NAotLS0gYS9tbS9tZW1vcnkuYworKysgYi9tbS9tZW1vcnkuYwpAQCAtMTU1NSw3 ICsxNTU1LDcgQEAgaW50IF9fZ2V0X3VzZXJfcGFnZXMoc3RydWN0IHRhc2tfc3RydWN0ICp0c2ss IHN0cnVjdCBtbV9zdHJ1Y3QgKm1tLAogCQkgKiBJZiB3ZSBkb24ndCBhY3R1YWxseSB3YW50IHRo ZSBwYWdlIGl0c2VsZiwKIAkJICogYW5kIGl0J3MgdGhlIHN0YWNrIGd1YXJkIHBhZ2UsIGp1c3Qg c2tpcCBpdC4KIAkJICovCi0JCWlmICghcGFnZXMgJiYgc3RhY2tfZ3VhcmRfcGFnZSh2bWEsIHN0 YXJ0KSkKKwkJaWYgKCFwYWdlcyAmJiAoZ3VwX2ZsYWdzICYgRk9MTF9NTE9DSykgJiYgc3RhY2tf Z3VhcmRfcGFnZSh2bWEsIHN0YXJ0KSkKIAkJCWdvdG8gbmV4dF9wYWdlOwogCiAJCWRvIHsKZGlm ZiAtLWdpdCBhL21tL21sb2NrLmMgYi9tbS9tbG9jay5jCmluZGV4IDZiNTVlM2VmZTBkZi4uOGVk N2ZkMDlmODFjIDEwMDY0NAotLS0gYS9tbS9tbG9jay5jCisrKyBiL21tL21sb2NrLmMKQEAgLTE2 Miw3ICsxNjIsMTAgQEAgc3RhdGljIGxvbmcgX19tbG9ja192bWFfcGFnZXNfcmFuZ2Uoc3RydWN0 IHZtX2FyZWFfc3RydWN0ICp2bWEsCiAJVk1fQlVHX09OKGVuZCAgID4gdm1hLT52bV9lbmQpOwog CVZNX0JVR19PTighcndzZW1faXNfbG9ja2VkKCZtbS0+bW1hcF9zZW0pKTsKIAotCWd1cF9mbGFn cyA9IEZPTExfVE9VQ0g7CisJaWYgKCEodm1hLT52bV9mbGFncyAmIFZNX0xPQ0tFRCkpCisJCXJl dHVybiBucl9wYWdlczsKKworCWd1cF9mbGFncyA9IEZPTExfVE9VQ0ggfCBGT0xMX01MT0NLOwog CS8qCiAJICogV2Ugd2FudCB0byB0b3VjaCB3cml0YWJsZSBtYXBwaW5ncyB3aXRoIGEgd3JpdGUg ZmF1bHQgaW4gb3JkZXIKIAkgKiB0byBicmVhayBDT1csIGV4Y2VwdCBmb3Igc2hhcmVkIG1hcHBp bmdzIGJlY2F1c2UgdGhlc2UgZG9uJ3QgQ09XCkBAIC0xNzgsOSArMTgxLDYgQEAgc3RhdGljIGxv bmcgX19tbG9ja192bWFfcGFnZXNfcmFuZ2Uoc3RydWN0IHZtX2FyZWFfc3RydWN0ICp2bWEsCiAJ aWYgKHZtYS0+dm1fZmxhZ3MgJiAoVk1fUkVBRCB8IFZNX1dSSVRFIHwgVk1fRVhFQykpCiAJCWd1 cF9mbGFncyB8PSBGT0xMX0ZPUkNFOwogCi0JaWYgKHZtYS0+dm1fZmxhZ3MgJiBWTV9MT0NLRUQp Ci0JCWd1cF9mbGFncyB8PSBGT0xMX01MT0NLOwotCiAJcmV0dXJuIF9fZ2V0X3VzZXJfcGFnZXMo Y3VycmVudCwgbW0sIGFkZHIsIG5yX3BhZ2VzLCBndXBfZmxhZ3MsCiAJCQkJTlVMTCwgTlVMTCwg bm9uYmxvY2tpbmcpOwogfQo= --0016e65b54cc6a992604a27c99d1-- -- 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/