From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3D34FCD68ED for ; Tue, 10 Oct 2023 07:25:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE8CC8D00AE; Tue, 10 Oct 2023 03:25:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A98E38D006D; Tue, 10 Oct 2023 03:25:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 987B48D00AE; Tue, 10 Oct 2023 03:25:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 883BF8D006D for ; Tue, 10 Oct 2023 03:25:22 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4E597801B1 for ; Tue, 10 Oct 2023 07:25:22 +0000 (UTC) X-FDA: 81328716084.28.B3D9B30 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by imf03.hostedemail.com (Postfix) with ESMTP id 8A15C2000F for ; Tue, 10 Oct 2023 07:25:20 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Xt7JGvNv; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf03.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696922720; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=1TVFpVcIea+y33en3TIZ3rzGeaFl4qxAMi6FTjOi3KY=; b=TkEw6+d5oJOBC/tOjw5Y/0YHHujKxWjX9JI6NRR+HQKHfDy5XQzTNX+MwTSDX0r4uExqaY RCvcwe69cCi9ZhgijAV8CaOnsmUa030U0vQ9DYyIkycTbtwl5aicurUWZpuUCsuZN32GNS /dCCyAA4xLgvRDDmXj5kBBl6kWEhYDo= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Xt7JGvNv; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf03.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696922720; a=rsa-sha256; cv=none; b=ekhBZ5ftg5urgidRZ4OuTeroOC1ihijQTmbn3ktOs0q60uikoffI81dusUeug9vrWeH6Ww OA/AwFWZAomK3v9On1Cv75qi12k+mFwcmEnKHchtxOAWbRtNMfKoK4Z0Hx3+TrGgJArFRs OLn3pDAMPal/FYoIcUHsU1PW1jVkRtI= Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-406402933edso49568345e9.2 for ; Tue, 10 Oct 2023 00:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696922719; x=1697527519; darn=kvack.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=1TVFpVcIea+y33en3TIZ3rzGeaFl4qxAMi6FTjOi3KY=; b=Xt7JGvNvluOzdO5PJXXOfpAoQlsyIPlbWMtpvT1cApmXwJdjiYg15mW2UwpD+UQQ2i T3R2Zu7KF1pByk+TuViZL9NQabJMmeYi6ZCcaZMf/iIpt7NyvlOxAoB0I6ox+Dmnq0PC 6z98DgRf1g4LMVbB9lf7Sq3ulDQbHa0dbBhC+phBSzY8Gq9JzvDobEJ0T54T3zH2WMyl Jtf5tPch9U2b4vv3o6epRgUpG620aRO3hLgCpdcvmtfkDV32HaerSMsPg/u6MGcQAUpc J/q4LdSDSl2YdbcgAssCp4DVcNOX0XM/efpN8rMxTiAvjcGhSRVe/VvGo5zOykPPKdgR 8ZxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696922719; x=1697527519; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1TVFpVcIea+y33en3TIZ3rzGeaFl4qxAMi6FTjOi3KY=; b=ImAJy3Nzlacy38UXXG/rLnKGOfYJbZySQ14SeO+bvHBBjr85J0AXaecsGobbIB8r8E IWDFN5PObnygOCep8KpB5Poiaofbw+jx3N/3z0/z4xDQQkcQsuy88NLeLEkTLq5SsXYg 8Sp5vSeA70cG4xG57jSV4SZrcmCY3sCDyyepIu5A1tAx1DKbIDnYc/5cCtbsb7FXB3Ma /IEOMbYCC048Kz0vVwu+lpvfF2CfTid2PQjKcKSNhDc5OAvJ4OBQ08rKusipaIW8FrvO sdu0OMaYfS3iKtmpc0s/HOU5hzBcXlTkBAtqIlhL6fgwDDEFaEvcNAOp5BV1aZKQ1eLu VeQQ== X-Gm-Message-State: AOJu0Yxhot6OH3B8YlMrpTQqx+Swn4CfIDAuxPqAYRDCtZmUijZIwuYG nODNa921OipAjW/5FU07Y4PGaEqRF0A= X-Google-Smtp-Source: AGHT+IFxo0w3THdPczoWlufoCzZ9kMB0efXaXT51R2JbrDJy5/905oDyHQ7PAjVRsPG1hyT5ULsJXA== X-Received: by 2002:a05:600c:2248:b0:405:36d7:4582 with SMTP id a8-20020a05600c224800b0040536d74582mr15298259wmm.15.1696922718342; Tue, 10 Oct 2023 00:25:18 -0700 (PDT) Received: from lucifer.home ([2a00:23c5:dc8c:8701:1663:9a35:5a7b:1d76]) by smtp.googlemail.com with ESMTPSA id q5-20020a7bce85000000b0040596352951sm15570524wmj.5.2023.10.10.00.25.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Oct 2023 00:25:17 -0700 (PDT) From: Lorenzo Stoakes To: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton Cc: Mike Rapoport , David Hildenbrand , "=Liam R . Howlett" , Vlastimil Babka , Lorenzo Stoakes Subject: [RESEND PATCH v2] mm/mprotect: allow unfaulted VMAs to be unaccounted on mprotect() Date: Tue, 10 Oct 2023 08:25:02 +0100 Message-ID: X-Mailer: git-send-email 2.42.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 8A15C2000F X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: shebdqcma5jpicctx69nbykc5bzbj8cg X-HE-Tag: 1696922720-813996 X-HE-Meta: U2FsdGVkX1+yYnWORXQynP5X1/cGBfrcOaX+8uyh1+x/NTnHUH/LE0qc9klWhRUDnGp2NqMVzqMPDbROlzPYVDwHhItTLmaEHvIKnK8A8yQDN4ATxBbHE9ZUDITtyKLGVVZpgNQPpSZJIVBYNTmw23fy7BINiUuR7ONxN23rmt0DSkTFTeIPmvYNUobuUzYdTciVkhOP17ys8l8Hxwu9+tvugFuj3/AQOmI+a+7agB22ONZrJ+nHhyUmGIHxy8t7xNwQaauRXIFgMgv1Vyp76uz+Hpq5Cr3U1NU2NaGAY5Q6xjxNcFRfs58fFu2VUpfM4B8bXIjmGXorir6CEHNhwMFF5RvJZ0bzB14xU+5JTuVqERvPQv5+Z04mGBxLixwwOxblHUfxd2O5E1O94ZJuWoCu1byV2VaeCgPU54mbpaMwJeUsVuamtlH9pu64+Z6mpS24kmckpI55+X0tw9e2HLTIO9Geq0PzQbYtI7PIEhvNVKtmVN4E2kg3gNj5ob9gB9jmA5XMDM8T8z+WT/GeL05BvPKvv3VYweo4p3Rw+4bhKzYjuzwO0zwoojFmcLZP+Gcrg3yQJvSEIsAvDvUEX66ha8wdly5fejWfwo+4sJ8DHOH7LkUcHaIkc8oTsP/J2OzcmocQk7ez38PF6ykvVzF8k4IiS7U9HDn2QkkDdbqAB1WFPKP62BVrnillyPWEcWNx124DKUtlFSuwl7twXITmIj3tBC9vBiNbfFMQKuiF49Eq/kUBtcin683VRV17YWGR3UecYW0huWSp7Kb1nusilqgYM6gaARG1rKrrbDdObpMmWTp+CmHRb5EfbnPHftwQcQF7Bz7+qRwnD37Iml9i53UjSGXbHWuLkUf5X5CLScnr95ZS/dvvtj+ZO/V0r7ny7xpSyza3uN/1fDiNW33mDKmz1SCdQ28w8ANsbIFnCyVbR/M+amWpmnmTjAjjYlE6XRvhxK9BMAKPAql uBN3KHbK qvTqSoaaDL7MNzN5euxJApl0DXCxnFk7LrMgMc5kWgk/K3JKLqtWx0ZKPmXpvRectVpXFkaNpTUBSxSzPjSvsHc6sCyphkoGN5HHVx5gWgF9VyX1jaSNqGYZejWfWjIAGgFWb5w0pySARqrpH+SWbcsl+3TXPAlG6you3i1ARcGBflfGtCkiZ5EHFXb61p5EcTBMq7cFuawb33xoih5TLiI2h3WTSJPzYzpljoUMILKlN939Hy2a+hxfL//J9SxINk8Gsa4RzYj8TrLjBVvDjERc0V+21WHdw54OzG1Fi8jMovvHormHPkFBIpOXTmMBkcf6Da3PPEhXJTqUo3k1kN+HFpgcmjVuwz6hOw+sHpqNmR3PntwTxSgGuhSbZlXV9hfYElDFYN63q+93Xacsb89cSGxkJZ/06XvuZnDqzUQxbMQc= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: When mprotect() is used to make unwritable VMAs writable, they have the VM_ACCOUNT flag applied and memory accounted accordingly. If the VMA has had no pages faulted in and is then made unwritable once again, it will remain accounted for, despite not being capable of extending memory usage. Consider:- ptr = mmap(NULL, page_size * 3, PROT_READ, MAP_ANON | MAP_PRIVATE, -1, 0); mprotect(ptr + page_size, page_size, PROT_READ | PROT_WRITE); mprotect(ptr + page_size, page_size, PROT_READ); The first mprotect() splits the range into 3 VMAs and the second fails to merge the three as the middle VMA has VM_ACCOUNT set and the others do not, rendering them unmergeable. This is unnecessary, since no pages have actually been allocated and the middle VMA is not capable of utilising more memory, thereby introducing unnecessary VMA fragmentation (and accounting for more memory than is necessary). Since we cannot efficiently determine which pages map to an anonymous VMA, we have to be very conservative - determining whether any pages at all have been faulted in, by checking whether vma->anon_vma is NULL. We can see that the lack of anon_vma implies that no anonymous pages are present as evidenced by vma_needs_copy() utilising this on fork to determine whether page tables need to be copied. The only place where anon_vma is set NULL explicitly is on fork with VM_WIPEONFORK set, however since this flag is intended to cause the child process to not CoW on a given memory range, it is right to interpret this as indicating the VMA has no faulted-in anonymous memory mapped. If the VMA was forked without VM_WIPEONFORK set, then anon_vma_fork() will have ensured that a new anon_vma is assigned (and correctly related to its parent anon_vma) should any pages be CoW-mapped. The overall operation is safe against races as we hold a write lock against mm->mmap_lock. If we could efficiently look up the VMA's faulted-in pages then we would unaccount all those pages not yet faulted in. However as the original comment alludes this simply isn't currently possible, so we are conservative and account all pages or none at all. Acked-by: Vlastimil Babka Signed-off-by: Lorenzo Stoakes --- mm/mprotect.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/mm/mprotect.c b/mm/mprotect.c index 6f85d99682ab..6bae0de547b3 100644 --- a/mm/mprotect.c +++ b/mm/mprotect.c @@ -608,8 +608,11 @@ mprotect_fixup(struct vma_iterator *vmi, struct mmu_gather *tlb, /* * If we make a private mapping writable we increase our commit; * but (without finer accounting) cannot reduce our commit if we - * make it unwritable again. hugetlb mapping were accounted for - * even if read-only so there is no need to account for them here + * make it unwritable again except in the anonymous case where no + * anon_vma has yet to be assigned. + * + * hugetlb mapping were accounted for even if read-only so there is + * no need to account for them here. */ if (newflags & VM_WRITE) { /* Check space limits when area turns into data. */ @@ -623,6 +626,9 @@ mprotect_fixup(struct vma_iterator *vmi, struct mmu_gather *tlb, return -ENOMEM; newflags |= VM_ACCOUNT; } + } else if ((oldflags & VM_ACCOUNT) && vma_is_anonymous(vma) && + !vma->anon_vma) { + newflags &= ~VM_ACCOUNT; } merged = vma_modify_flags(vmi, *pprev, vma, start, end, newflags); @@ -638,6 +644,9 @@ mprotect_fixup(struct vma_iterator *vmi, struct mmu_gather *tlb, *pprev = vma; } + if ((oldflags & VM_ACCOUNT) && !(newflags & VM_ACCOUNT)) + vm_unacct_memory(nrpages); + /* * vm_flags and vm_page_prot are protected by the mmap_lock * held in write mode. -- 2.42.0