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 493C4EB64D9 for ; Tue, 27 Jun 2023 06:59:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 526728D0002; Tue, 27 Jun 2023 02:59:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D5F48D0001; Tue, 27 Jun 2023 02:59:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 39D9B8D0002; Tue, 27 Jun 2023 02:59:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 2722D8D0001 for ; Tue, 27 Jun 2023 02:59:44 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D4A39C08E9 for ; Tue, 27 Jun 2023 06:59:43 +0000 (UTC) X-FDA: 80947627446.24.32907DF Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf13.hostedemail.com (Postfix) with ESMTP id 5A94C20004 for ; Tue, 27 Jun 2023 06:59:41 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=c94nvBps; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf13.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687849181; a=rsa-sha256; cv=none; b=HgyPQm0wB1D5Z0aDlsRkfmy/If7gnUM3xJdqKFdCVZPykcgQPuffQHAWJgHfbJf0lBWK/h 8hqnu28uT3+1Gaa1/tlfGdHEL/+5mtmbVE6iC1pqxANF3uBTJeXj10fbgVS7eT7DQ8e0r6 75LNjs7g/62V48vL9FuvwuFnIAK6YR0= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=c94nvBps; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf13.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687849181; 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-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=RbthhMj/2jM694BPdz2+B/9xEDc+NPAbla6OKLGCX4M=; b=tI/JOqKik3Nc0HlU9Q8QBEH4HLO930EM3d7UssxZLWptCki2lcPKjyB6ZKEP2xA8d/3Gn1 aQ6PxtxECvVcddqfYCKyFc7e4s0CvDqp5lXF0DIvnRw8yGx6KN/xtxZH7xJXy0bg7JwJlq 2Af/756RWVKGvdNabQG22agtK9C1iBE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1687849180; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RbthhMj/2jM694BPdz2+B/9xEDc+NPAbla6OKLGCX4M=; b=c94nvBpsPjbYC6BG6nISIPGJh9nvKAkg3JLw6q6ApeMVmga4dvnBknMOF6MJTe8iZeRfml EVNZE+2+ms1JUzRrI36ABpjwH+P7c+kGc2moU7uwlSQPo5TiKew+hyXsJXOkSs31YJ9to5 im05kTTbeCbeRYI/TAOWcE3F4uNMSdc= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-350-7gA50btmNhG__NPx37enXg-1; Tue, 27 Jun 2023 02:59:36 -0400 X-MC-Unique: 7gA50btmNhG__NPx37enXg-1 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-3f7e7cfcae4so23844565e9.1 for ; Mon, 26 Jun 2023 23:59:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687849175; x=1690441175; h=content-transfer-encoding:in-reply-to:subject:organization:from :content-language:references:cc:to:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RbthhMj/2jM694BPdz2+B/9xEDc+NPAbla6OKLGCX4M=; b=NEESB4+Nrjrt/ISzBCeXG08F1tJrCdm/GRgZl46/H5f64UXZvgRlHwh0U9p3mLHfWl XsZ2vaTNvjsvDb5Svz4KYeIEcjih/aC5+ZC9tB4NY6QeDZSkq89ERgWCALn1OlrtuvFK +rYs5jmp6v3ZPakjyuWY5jujWUJab/3yhMzK58isuEbCED0pCKiMwIul3myvk6KE9qPJ lZSWDp7pyyv0DTeRRpTuvIVH7ceZBNSmKytG+rRBlvK9bqtJONZi1e/b1om9m3NL748G Gx5/VFqnpRfXnxks3ILOsMh/q1ZqvmavKaOw62iUNqV2v2gw7S4TyYxFKB0wuSP+BLzT aLqg== X-Gm-Message-State: AC+VfDyB3lULb9CPw1qkefv1tlwQv31PAUbl/FCKyUmAIDQv3oPEG/sF OZMsIz6brXiq7/Fflu5d6OrFIq+IjasYnDc85KfH/juMQ4zxPuw/WgI+qbbcSQDyKwL9LIneTR/ r5RcP2xRXI5s= X-Received: by 2002:adf:ed4c:0:b0:313:feeb:e0b8 with SMTP id u12-20020adfed4c000000b00313feebe0b8mr943289wro.17.1687849175575; Mon, 26 Jun 2023 23:59:35 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4rif8dQqcKrQPmhI4s/cS2VNYASx5to1xUWMtXcwVTk0sw4zYXFdycBSGL5PdYLo7viwMMsw== X-Received: by 2002:adf:ed4c:0:b0:313:feeb:e0b8 with SMTP id u12-20020adfed4c000000b00313feebe0b8mr943268wro.17.1687849175111; Mon, 26 Jun 2023 23:59:35 -0700 (PDT) Received: from ?IPV6:2003:cb:c737:4900:68b3:e93b:e07a:558b? (p200300cbc737490068b3e93be07a558b.dip0.t-ipconnect.de. [2003:cb:c737:4900:68b3:e93b:e07a:558b]) by smtp.gmail.com with ESMTPSA id x11-20020adfdd8b000000b00313ecd3714csm6555759wrl.19.2023.06.26.23.59.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jun 2023 23:59:34 -0700 (PDT) Message-ID: <1832a772-93b4-70ad-3a2c-d8da104ce8dd@redhat.com> Date: Tue, 27 Jun 2023 08:59:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 To: Vlastimil Babka , Lorenzo Stoakes , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton Cc: Mike Rapoport , "Liam R . Howlett" References: <20230626204612.106165-1-lstoakes@gmail.com> <074fc253-beb4-f7be-14a1-ee5f4745c15b@suse.cz> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH] mm/mprotect: allow unfaulted VMAs to be unaccounted on mprotect() In-Reply-To: <074fc253-beb4-f7be-14a1-ee5f4745c15b@suse.cz> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 5A94C20004 X-Stat-Signature: 5ea7o5fmioy9t67gpo5qnb5rw7ouf5hb X-HE-Tag: 1687849181-508871 X-HE-Meta: U2FsdGVkX1/xUbHolIuuxRLNOi5hZydIe+pUN6/ownluv4Ohln/GCQDP+1BmbC5hvXrTrT4+iDW8LyxMCX1NJ1/ca8NhM+XQ8H7eSFKfDu3009HU33aaMGVC2bOtemn32OpQqC0+NJUZAb/ft0mBpnKvanrBXLqoKkjW0i/G4OGLJRPAzXs1hZnjF65VVWV/8NRS3MOZBBRCqfy/6Fsd0qeMSkwYinvZRnggCXRkswTjH3jqEsQiDzfWFozVHsiRDtCEOVSRvl/rhutLB0kqB6yvk2lAWcjQAGXhxZ4hXBi5m8PcLHjE2/faf+sCtIcTWY06fz2CcyZtz7EX23FrF/j1Mo4keTRzF77fJnIkOpGVXJCiXkMrkGBY5hftTbwY9r7HSNd53DIhNrgwvPiobagz8VpU5gQIuG8HSgGX1PS5IfM2gQeI+EfEuz5GeAje9hcXWQvtQC1dpwZMV0D/ht+XBa+F9EKz1NGbFBFY26c2kjDqV7lT1slxdC+kLBljcq+Bc3GYRa6CfyinSOYpNccjq97aIgmPT41cSReGM/XPiNgiHrZt4ZEke4uoSVuCabdNZTbqQBL4ZN3lyf3f/wQHygRnXHJDRW3QTaM4lSR1Gf5g+AMGcWa9jzgsmV6xuH62vagxFd4cFOyjoLCBo8Y7+M+wB7peuS9SKWRun3HHAh6QPUMrUspAR11MnexQvSgjtIAq8jG+wvYN8+ucCgxhj4G0hxgdSSQNNPQZpNhX224clsAZRUKmD5glPIaxu3F5wZg3LkpP2FzMo6e32yEaiWGqf20YC2FneOxMjZq2NCjWJTwXWLywbHcbxDVOwaOy/oc4TI+LMFBZtNZAVwF0x52RbE0f3StDIq7fYcFtlMWO1Q1/BeFOy+9Tv5fgOe1jR+XQ82vft3XT7cUUJbSSfzrlWWY1UFf7vpXC6DpNL0lC5IImy7JftJ77LcqL5nmOkiINXH1q7xKv9cH GlWt4EOZ wO63pEHshKfypXw6qUZ0ZVjphJX7yFFLqMehJWIbf4UmG6MnNAqNkAu7auUKH+Mv/sjvQgbPim8nHHpOaqh9LOmQQlpD4jGE33PAm6/km4T9h1pc8cHp8MrYYKJbXN7FDixPySCF4CFgeTRzZhEe61ukqgO0M4fqZ0T8KUAbOn6XkpbLhSGMgqSS1hkShPJaIKoiu3K2MY03QJ7nA59BsF3/uxLMkFgAQyVRINH/VCeNY7apMdHtpXIzwtBVhwqrlvXdSSHbd3bIsyi8KA5CpoSKDa7HVLvh/soyQ8fJPNZk/bURY+4/4Alx3sH/fMnFHsMoJijtYRP04pi7xXakibW9MMybQOUFdCICdn6TQcnlbn4wscRubTePZO3ginY6FVfZ19oF1TzLul0rifXTu89UdNw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi all, On 27.06.23 08:28, Vlastimil Babka wrote: > On 6/26/23 22:46, Lorenzo Stoakes wrote: >> 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); > > In the original Mike's example there were actual pages populated, in that > case we still won't merge the vma's, right? Guess that can't be helped. > I am clearly missing the motivation for this patch: above is a artificial reproducer that I cannot really imagine being relevant in practice. So is there any sane workload that does random mprotect() without even touching memory once? Sure, fuzzing, ... artificial reproducers ... but is there any real-life problem we're solving here? IOW, why did you (Lorenzo) invest time optimizing for this andcrafting this patch and why should reviewer invest time to understand if it's correct? :) >> 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 remain >> conservative and account all pages or none at all. >> >> Signed-off-by: Lorenzo Stoakes > > So in practice programs will likely do the PROT_WRITE in order to actually > populate the area, so this won't trigger as I commented above. But it can > still help in some cases and is cheap to do, so: IMHO we should much rather look into getting hugetlb ranges merged. Mt recollection is that we'll never end up merging hugetlb VMAs once split. This patch adds code without a clear motivation. Maybe there is a good motivation? -- Cheers, David / dhildenb