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 50552C6FD1C for ; Wed, 22 Mar 2023 20:09:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A46176B0078; Wed, 22 Mar 2023 16:09:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9F76A6B007B; Wed, 22 Mar 2023 16:09:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7D2726B007D; Wed, 22 Mar 2023 16:09:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 6E5F36B0078 for ; Wed, 22 Mar 2023 16:09:33 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 2D10240611 for ; Wed, 22 Mar 2023 20:09:33 +0000 (UTC) X-FDA: 80597624226.01.1C92A47 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by imf10.hostedemail.com (Postfix) with ESMTP id 443CDC0026 for ; Wed, 22 Mar 2023 20:09:29 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Yy6NlxAp; spf=pass (imf10.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.49 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679515770; 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:in-reply-to:references:references:dkim-signature; bh=y7U4rZ5ngeaMtEfGvEeiH442bzXxl021xaQINSP+F4Q=; b=5PtNwF6upWju2pJs5BJxt2uiGeWH7DG7oPx7sV5PhTE5IbuXXC1P0AT3Td/AbUER2l1aC8 NY5x6qyKEIXgLN/O68mbEDa7a2ceEO+6x3hABvVJzDCKzqv78R23yuTjGrFmyhner+syiJ oclYwyz90YwLogJ3j+2mehCab0I/cqw= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Yy6NlxAp; spf=pass (imf10.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.49 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679515770; a=rsa-sha256; cv=none; b=mcGJVex91pJ2X4sN/QhP9RiEybz5lI/MWbytRjIJWQGBqiNLfaraJmSlVXI17o7rCtPV7Q cOxbb4uRfvB8Ip9+k4xqnolUbb8/TLExSpxooyH4yBX1pn6UouIZE6TvJBfe8m4zLBz5NR 58c4QiRS5vtVdUkODX9/s3Sk5FRT5Y4= Received: by mail-wm1-f49.google.com with SMTP id o32so5861719wms.1 for ; Wed, 22 Mar 2023 13:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679515768; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=y7U4rZ5ngeaMtEfGvEeiH442bzXxl021xaQINSP+F4Q=; b=Yy6NlxAp+t90djnlr0eKV1vtFIoIX7OHUPxsR1HJ3ftdUyCMx5/khrzPHAD+d7jdEU G1DSXbJK+DDYqs2RNZh6JIuYiiPX4CgTuYuqAQSpIOIwIJMTEdzfyevhTmxuUEND5sRs pE00bBiFEGLKsqOVZZqyzdT27HdQB6Sf/4cW5TDg5bF6QlfhtVkb3X6wkamlU8KVxnWP gLdPGDEP9tkOEHjadj8mtZX53YWG0SkG9NomSe7bBrOW0aL4eTJKLtXVk8Q9OgcB/Xk5 82T7/PMyibkSk76+S5r3k2MQx+RgqKpw+hUpCdqCrCm1Y69ZY7d5nM4XLYL0U56k7LaT jZ5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679515768; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=y7U4rZ5ngeaMtEfGvEeiH442bzXxl021xaQINSP+F4Q=; b=fFq7pOkxbH50bpo+tDQ7pr97tiPPp9qUrcHFjUEUJA0pfwrmuMWATAdptnhNidxWeu PMjlyGhSWh5KWJ9IOWEJQP+FGolVMiD0n8XJEI6s5Lc9IPaXKuumsp4dmKrWmbzTgCP9 gy36t0U/TYFGMJQudR1Ka7yXox4v67Bc7UJOYaB3/cUbskb22IxwYvr/TzOiFJTtkX86 nE0x8kTNuA+lRD/w6pva406MCt2gnJf/FyzPmRk397yUKvquWaOvo+FByA/97jlRgpDh rsfKe6CjHgKzHtBfBP+i9V7invpZfR7CCFEW+JMlnyOPZbqwSWH4XM8VTXEPFUTC0Hc4 Bw8g== X-Gm-Message-State: AO0yUKVrLy4fWoGMhQmLBglnuxQQq10psMojIIW/5zv7iWnPj4dkq7wR hLFUmL4VHBZnC0hPesz9UWRTfCjdUfQ= X-Google-Smtp-Source: AK7set+f58badNiN6DJ4tP10METXdPN2qjZAcVNqZ75G88ztSZtS34CbtuPl8EyvVLqkvQBmyrqXHQ== X-Received: by 2002:a7b:ce16:0:b0:3ee:d7f:6676 with SMTP id m22-20020a7bce16000000b003ee0d7f6676mr565890wmc.11.1679515768327; Wed, 22 Mar 2023 13:09:28 -0700 (PDT) Received: from lucifer.home ([2a00:23c5:dc8c:8701:1663:9a35:5a7b:1d76]) by smtp.googlemail.com with ESMTPSA id a7-20020adff7c7000000b002c70ce264bfsm14664342wrq.76.2023.03.22.13.09.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Mar 2023 13:09:27 -0700 (PDT) From: Lorenzo Stoakes To: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton Cc: David Hildenbrand , Matthew Wilcox , Vlastimil Babka , "Liam R . Howlett" , maple-tree@lists.infradead.org, Vernon Yang , Lorenzo Stoakes Subject: [PATCH v4 1/4] mm/mmap/vma_merge: further improve prev/next VMA naming Date: Wed, 22 Mar 2023 20:09:19 +0000 Message-Id: <98e8a31ab0f72e8fc31d6045efbc7eeac1c07e0a.1679515236.git.lstoakes@gmail.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 443CDC0026 X-Rspam-User: X-Stat-Signature: 489huuomtpzrikjwopt3wzjux5nfdc3n X-HE-Tag: 1679515769-556158 X-HE-Meta: U2FsdGVkX196euiN/L0/VspRTTeMn26S4m1aauJDTQxwk/CqHLJztHtXRspsiJk+ZiYQLlY8G/Ei4UEbPvMDOJcfqd6SJVUhDSpUXMOjrKn1anLrKCfig1Ubi6qalshXB2OI1DdebhEZhTFiupaTp8YYcCG9ExIWGUnPivHZymAGmOsOubGAvCJ3hBOVulWxlTeh1w+Ye6hhMp5iJKUb+kEPeAF5NhR3HMBdGT2m4pv46FlwHYFcrrtbs/yI6ubIAPdumkotJgOE2HiAmAUjAOrmwRJF7meIVXisKdHNwGxigoElyBTt+GtbOoKid1n/dh/Tb18NI8rORPWBhw2T4b+v82awYLclyZRBo/pSk01malfkf+81wg9BreD/3O/0S/e6n0qCk5PfdnSyE+IfM1cCQLMgnLctY1sHt6uD8hLioEvxzQvjbgGzxaHvajPFZASjU5WWymaVY4pF6PdR5Y2bvWBZpS5iuDVhQs1sk4IAFqQtNn7x8iQ1GF2ZlA75JPIwDluml5K4xQuaEl+EOdL1iqD8fkg29OMcn7cxW6JsMG9x+JHs1JPm30xwumM1wIhSALgZxCDOf+DT6Mxs4H11K05FCO7RREAewHiLC3oZ4uB4sRrB9WrM0IVO3JbC6z0wGs+2NsU+Os0yjTUtGauWFch5RoI5HO9hdpLq+bW4wik1qx86g/GYl0Zjon3Sy06ihwLpj29HLDI1RNcvx77snrJxC0Qc+Wdov7gZcfXzLeF5182e9gA1ScS+quv+Nj2k5CgXHLqXSkN3/abrvV6ha7j0yisZ775I/Ml39EWmnpOKR3862P+oMQHjpYlOEXgFqyzcQwM/rssvD6jJYjbBPTPjZbViU/34f5Y4ssJNg2arhyB1HwgiH0zOP82yBStW3sw5Bl5oesTlA4N6AwPGFBHrSic6itsyyr4FDX48W9+JHJ75EQSh+uUliJwMtlyhZ5er93Yo/mdg7oU qW/iVe7D 22b/9D5Ot+TWOP7b5Hmdh1gV5ede9kA2IULeOgOuJbSTvLJr3sKWgZIpcXGoy/tV5VjAqTqAUgPECkDUXZsC5ZKFOZpJfPC+zQHuMWNdPjq7f8SZ90Sm9hbr21HPZEN3jnIIrWZlQuiTQ4sxH+zBsEU/JYFAHsFNpe0NHcvNQGmD3eLn9X04WnR1Nha3sR61A379yQcq4tCjZgEaOxYcumxjDsSbm01/43TNw92nFTrceYb8xj5uOLUP0rmT4nN/FDpjSVlIPakQiEat5egPHfy5hBONC63z0jWZFuKyUcL7c7on+L6Ggyt3c5cpf0vV9Ty3YmzXhwgeCHsiMUS4nFRSfskG5n/647GaP7q3y6XjKVzWg9i8F/cUinQyIXxUPUg793mYIT71vSIRRme0deCIxOba2zro38ncCUb655IW/rmNFOcXbO+oBfsKKpYtrq1YMqTZ5GTnAq7Frm7tONG+zpcClCS1de4J4rz2dJtn2zp52Ad1+Keq554PCEY2BBJoFnftjqJAIoUM= 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: Previously the ASCII diagram above vma_merge() and the accompanying variable naming was rather confusing, however recent efforts by Liam Howlett and Vlastimil Babka have significantly improved matters. This patch goes a little further - replacing 'A' with '*' as it is clearer, 'X' with 'N', which feels more natural as this represents the _next_ VMA and infalyl 'N' with 'C' which represents the current VMA. No word quite describes a VMA that has coincident start as the input span, however 'concurrent' (or more simply 'current') abbreviated to 'curr' fits intuitions well alongside prev and next. This has no functional impact. Signed-off-by: Lorenzo Stoakes Reviewed-by: Vlastimil Babka Reviewed-by: Liam R. Howlett --- mm/mmap.c | 86 +++++++++++++++++++++++++++---------------------------- 1 file changed, 43 insertions(+), 43 deletions(-) diff --git a/mm/mmap.c b/mm/mmap.c index 042d22e63528..c9834364ac98 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -861,44 +861,44 @@ can_vma_merge_after(struct vm_area_struct *vma, unsigned long vm_flags, * this area are about to be changed to vm_flags - and the no-change * case has already been eliminated. * - * The following mprotect cases have to be considered, where AAAA is + * The following mprotect cases have to be considered, where **** is * the area passed down from mprotect_fixup, never extending beyond one - * vma, PPPP is the previous vma, NNNN is a vma that starts at the same - * address as AAAA and is of the same or larger span, and XXXX the next - * vma after AAAA: + * vma, PPPP is the previous vma, CCCC is a concurrent vma that starts + * at the same address as **** and is of the same or larger span, and + * NNNN the next vma after ****: * - * AAAA AAAA AAAA - * PPPPPPXXXXXX PPPPPPXXXXXX PPPPPPNNNNNN + * **** **** **** + * PPPPPPNNNNNN PPPPPPNNNNNN PPPPPPCCCCCC * cannot merge might become might become - * PPXXXXXXXXXX PPPPPPPPPPNN + * PPNNNNNNNNNN PPPPPPPPPPCC * mmap, brk or case 4 below case 5 below * mremap move: - * AAAA AAAA - * PPPP XXXX PPPPNNNNXXXX + * **** **** + * PPPP NNNN PPPPCCCCNNNN * might become might become * PPPPPPPPPPPP 1 or PPPPPPPPPPPP 6 or - * PPPPPPPPXXXX 2 or PPPPPPPPXXXX 7 or - * PPPPXXXXXXXX 3 PPPPXXXXXXXX 8 + * PPPPPPPPNNNN 2 or PPPPPPPPNNNN 7 or + * PPPPNNNNNNNN 3 PPPPNNNNNNNN 8 * - * It is important for case 8 that the vma NNNN overlapping the - * region AAAA is never going to extended over XXXX. Instead XXXX must - * be extended in region AAAA and NNNN must be removed. This way in + * It is important for case 8 that the vma CCCC overlapping the + * region **** is never going to extended over NNNN. Instead NNNN must + * be extended in region **** and CCCC must be removed. This way in * all cases where vma_merge succeeds, the moment vma_merge drops the * rmap_locks, the properties of the merged vma will be already * correct for the whole merged range. Some of those properties like * vm_page_prot/vm_flags may be accessed by rmap_walks and they must * be correct for the whole merged range immediately after the - * rmap_locks are released. Otherwise if XXXX would be removed and - * NNNN would be extended over the XXXX range, remove_migration_ptes + * rmap_locks are released. Otherwise if NNNN would be removed and + * CCCC would be extended over the NNNN range, remove_migration_ptes * or other rmap walkers (if working on addresses beyond the "end" - * parameter) may establish ptes with the wrong permissions of NNNN - * instead of the right permissions of XXXX. + * parameter) may establish ptes with the wrong permissions of CCCC + * instead of the right permissions of NNNN. * * In the code below: * PPPP is represented by *prev - * NNNN is represented by *mid or not represented at all (NULL) - * XXXX is represented by *next or not represented at all (NULL) - * AAAA is not represented - it will be merged and the vma containing the + * CCCC is represented by *curr or not represented at all (NULL) + * NNNN is represented by *next or not represented at all (NULL) + * **** is not represented - it will be merged and the vma containing the * area is returned, or the function will return NULL */ struct vm_area_struct *vma_merge(struct vma_iterator *vmi, struct mm_struct *mm, @@ -911,7 +911,7 @@ struct vm_area_struct *vma_merge(struct vma_iterator *vmi, struct mm_struct *mm, { pgoff_t pglen = (end - addr) >> PAGE_SHIFT; pgoff_t vma_pgoff; - struct vm_area_struct *mid, *next, *res = NULL; + struct vm_area_struct *curr, *next, *res = NULL; struct vm_area_struct *vma, *adjust, *remove, *remove2; int err = -1; bool merge_prev = false; @@ -930,19 +930,19 @@ struct vm_area_struct *vma_merge(struct vma_iterator *vmi, struct mm_struct *mm, if (vm_flags & VM_SPECIAL) return NULL; - mid = find_vma(mm, prev ? prev->vm_end : 0); - if (mid && mid->vm_end == end) /* cases 6, 7, 8 */ - next = find_vma(mm, mid->vm_end); + curr = find_vma(mm, prev ? prev->vm_end : 0); + if (curr && curr->vm_end == end) /* cases 6, 7, 8 */ + next = find_vma(mm, curr->vm_end); else - next = mid; + next = curr; - /* In cases 1 - 4 there's no NNNN vma */ - if (mid && end <= mid->vm_start) - mid = NULL; + /* In cases 1 - 4 there's no CCCC vma */ + if (curr && end <= curr->vm_start) + curr = NULL; /* verify some invariant that must be enforced by the caller */ VM_WARN_ON(prev && addr <= prev->vm_start); - VM_WARN_ON(mid && end > mid->vm_end); + VM_WARN_ON(curr && end > curr->vm_end); VM_WARN_ON(addr >= end); if (prev) { @@ -974,21 +974,21 @@ struct vm_area_struct *vma_merge(struct vma_iterator *vmi, struct mm_struct *mm, remove = next; /* case 1 */ vma_end = next->vm_end; err = dup_anon_vma(prev, next); - if (mid) { /* case 6 */ - remove = mid; + if (curr) { /* case 6 */ + remove = curr; remove2 = next; if (!next->anon_vma) - err = dup_anon_vma(prev, mid); + err = dup_anon_vma(prev, curr); } } else if (merge_prev) { err = 0; /* case 2 */ - if (mid) { - err = dup_anon_vma(prev, mid); - if (end == mid->vm_end) { /* case 7 */ - remove = mid; + if (curr) { + err = dup_anon_vma(prev, curr); + if (end == curr->vm_end) { /* case 7 */ + remove = curr; } else { /* case 5 */ - adjust = mid; - adj_start = (end - mid->vm_start); + adjust = curr; + adj_start = (end - curr->vm_start); } } } else if (merge_next) { @@ -1004,10 +1004,10 @@ struct vm_area_struct *vma_merge(struct vma_iterator *vmi, struct mm_struct *mm, vma_end = next->vm_end; vma_pgoff = next->vm_pgoff; err = 0; - if (mid) { /* case 8 */ - vma_pgoff = mid->vm_pgoff; - remove = mid; - err = dup_anon_vma(next, mid); + if (curr) { /* case 8 */ + vma_pgoff = curr->vm_pgoff; + remove = curr; + err = dup_anon_vma(next, curr); } } } -- 2.39.2