Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2986989imu; Sun, 9 Dec 2018 14:21:44 -0800 (PST) X-Google-Smtp-Source: AFSGD/V8r7qFx6RXupoOh2I+K71tVtMbXoZs3pd0HMussnwLEFj+QioVeokYZjYdx4YtLVqz7rWw X-Received: by 2002:a17:902:7896:: with SMTP id q22mr10071772pll.280.1544394104656; Sun, 09 Dec 2018 14:21:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544394104; cv=none; d=google.com; s=arc-20160816; b=grzs1WGyqhWgoCmkzxy/7lcr0LDrMjYbFazTEjeAp1BrN3XljJvQPN4sG86pIOs//o joupIYU4yo3konARSBedEI5S1h4+QJzwO4rRhInyxwCziT3ueEQWhV4Q1J3MoHc8Uc3Q XTfuqdhZF3w03QAHezEVKWTzRx7aMu+TrOd23Pg8O+yo3nB+IrhdN8UoLJ6RwrYeBDCI kNYmO+mK9U5epTy/UayrxnHlSjIvkUdP1WBK+mnr0m9J7xCbBOugmrQwuRYPh7nM7npX LtG/zh42r+1mmsRrfkQDppey7kXbjqITCQ9q8n8O9pRVE0FCjAy9T+macrxkX/C3UocS xpWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=eW6PiDLJVc/sq0yFkICWV0QLT5AV6NUIGuFwf0dfyZk=; b=bK5UlLg5bukYkWKMaFEooOJGrCsdOlwZH21Cr6dblS+SDxkPHSomLAVqlpDaRAX/Xa RbuYWIZQOi+h8Rtv6RWR1klAbq4ZatzzFGIRBR/wPhdgTqyQ+vRQQiohtz+8vzznB9V9 T1BYw4+sv6FWsFaxOhTf0erHpD3w9YTPVFq6uDrRR22vmA/hZtdSqJK1wH74kCKz/a1i DXBXiktXTzooh5NaVeNHf9tRch2Y8c08qPKYuO/zWRMxWZq1RUbnWEExzq9NGsmQNOsc Ly9k8VymDJ7ZrfosVJenctpcMVxBRZr7YYM1EGbHa3ULUvRudK4b3jF+f97OWjO6Had7 XYqQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c10si8340171pll.271.2018.12.09.14.21.29; Sun, 09 Dec 2018 14:21:44 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727774AbeLIWS6 (ORCPT + 99 others); Sun, 9 Dec 2018 17:18:58 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:35630 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726592AbeLIVz2 (ORCPT ); Sun, 9 Dec 2018 16:55:28 -0500 Received: from pub.yeoldevic.com ([81.174.156.145] helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gW72r-0002ie-9t; Sun, 09 Dec 2018 21:55:25 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gW72k-0003fu-VC; Sun, 09 Dec 2018 21:55:18 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Daniel Black" , "Mike Kravetz" , "Kenneth Penza" , "Konstantin Khlebnikov" , "Greg Kroah-Hartman" Date: Sun, 09 Dec 2018 21:50:33 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 303/328] mm: madvise(MADV_DODUMP): allow hugetlbfs pages In-Reply-To: X-SA-Exim-Connect-IP: 81.174.156.145 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.62-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Daniel Black commit d41aa5252394c065d1f04d1ceea885b70d00c9c6 upstream. Reproducer, assuming 2M of hugetlbfs available: Hugetlbfs mounted, size=2M and option user=testuser # mount | grep ^hugetlbfs hugetlbfs on /dev/hugepages type hugetlbfs (rw,pagesize=2M,user=dan) # sysctl vm.nr_hugepages=1 vm.nr_hugepages = 1 # grep Huge /proc/meminfo AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 1 HugePages_Free: 1 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB Hugetlb: 2048 kB Code: #include #include #define SIZE 2*1024*1024 int main() { void *ptr; ptr = mmap(NULL, SIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_HUGETLB | MAP_ANONYMOUS, -1, 0); madvise(ptr, SIZE, MADV_DONTDUMP); madvise(ptr, SIZE, MADV_DODUMP); } Compile and strace: mmap(NULL, 2097152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_HUGETLB, -1, 0) = 0x7ff7c9200000 madvise(0x7ff7c9200000, 2097152, MADV_DONTDUMP) = 0 madvise(0x7ff7c9200000, 2097152, MADV_DODUMP) = -1 EINVAL (Invalid argument) hugetlbfs pages have VM_DONTEXPAND in the VmFlags driver pages based on author testing with analysis from Florian Weimer[1]. The inclusion of VM_DONTEXPAND into the VM_SPECIAL defination was a consequence of the large useage of VM_DONTEXPAND in device drivers. A consequence of [2] is that VM_DONTEXPAND marked pages are unable to be marked DODUMP. A user could quite legitimately madvise(MADV_DONTDUMP) their hugetlbfs memory for a while and later request that madvise(MADV_DODUMP) on the same memory. We correct this omission by allowing madvice(MADV_DODUMP) on hugetlbfs pages. [1] https://stackoverflow.com/questions/52548260/madvisedodump-on-the-same-ptr-size-as-a-successful-madvisedontdump-fails-wit [2] commit 0103bd16fb90 ("mm: prepare VM_DONTDUMP for using in drivers") Link: http://lkml.kernel.org/r/20180930054629.29150-1-daniel@linux.ibm.com Link: https://lists.launchpad.net/maria-discuss/msg05245.html Fixes: 0103bd16fb90 ("mm: prepare VM_DONTDUMP for using in drivers") Reported-by: Kenneth Penza Signed-off-by: Daniel Black Reviewed-by: Mike Kravetz Cc: Konstantin Khlebnikov Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings --- mm/madvise.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/madvise.c +++ b/mm/madvise.c @@ -75,7 +75,7 @@ static long madvise_behavior(struct vm_a new_flags |= VM_DONTDUMP; break; case MADV_DODUMP: - if (new_flags & VM_SPECIAL) { + if (!is_vm_hugetlb_page(vma) && new_flags & VM_SPECIAL) { error = -EINVAL; goto out; }