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 9F940C7618A for ; Mon, 20 Mar 2023 17:11:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 37B436B0074; Mon, 20 Mar 2023 13:11:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 32B496B0078; Mon, 20 Mar 2023 13:11:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F3906B007B; Mon, 20 Mar 2023 13:11:11 -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 104686B0074 for ; Mon, 20 Mar 2023 13:11:11 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id D3E09120463 for ; Mon, 20 Mar 2023 17:11:10 +0000 (UTC) X-FDA: 80589917100.15.F1CDC36 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by imf20.hostedemail.com (Postfix) with ESMTP id 0B2A61C000D for ; Mon, 20 Mar 2023 17:11:08 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="Y/OfDbho"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.52 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=1679332269; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=p6hM6Lvhv87HAw4RvrkjFZdg7J8s1VPPzl4VJgkthUE=; b=HML1N7fuM5fmZcIVEK8xxucEWUdMjQ/x6FLgDby5yck9P5MvLZ7UCEp1MDamJobIuv+sZu 5oT7v5ZCYPDtnNsigcXJaWBUKFtxuKGYOdqbwRC+796sGFE09G0v+UPz3kouHymTF7Kp3a nr3+OEEb+1pNHV6mPFftBtYsSfjCzpE= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="Y/OfDbho"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.52 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679332269; a=rsa-sha256; cv=none; b=HA73ab5eK9f8QorZImtDRya9YBq5v30O1ZyZ259O2yqQwbxAyc/qaJzaFmL/wI8+bUsrb+ bwENK+ErKi4gqlTqCmKWsPxZ6zvbW67H0unmlpCpX5eFehGZADy3KkNK1K0IgxrOT3q1WV b1saYJ4rF6BeAPhY/ROCiR0VfIduns8= Received: by mail-wm1-f52.google.com with SMTP id o32so1638230wms.1 for ; Mon, 20 Mar 2023 10:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679332268; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=p6hM6Lvhv87HAw4RvrkjFZdg7J8s1VPPzl4VJgkthUE=; b=Y/OfDbho9Rpcjz3vWiiKM1Mym9R9k/L0UETaR7VJvM0zLAXF4Y7LNiTRmR/iq8aNf3 ArasbHETILNPYq/lTUM/E/G8xWvvfIROA3zOGJb0PzVFPUglWNvWfCT0cT65Mtz+h92S MPcpI0vWwR1xE1+Vt40NLQwvXPWpaycvv1DCOQ4LeVzQGJFgzX+3nmnj0ypzcp0bhEzD LeA9Kd9Y8RFMX3I9DtTziErzNSuifGnqz2zj4Y+S/ClgwkVk0bq3AhTvdFuaVdZB/oPx dqt2sBKGDnUBsMQRV5CwwJPnrnTNiBfodxaNtLOaXhdLc6ozoRz6gsejdnji5GoAzqJm 733A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679332268; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=p6hM6Lvhv87HAw4RvrkjFZdg7J8s1VPPzl4VJgkthUE=; b=CLyP8q+RlGFUqDdQaBJd4Z0xMm2rRv2jMaoBH+AsAqKgI9Fpn61YXaNIOYk+9DQwLB ipdIVSEjNt/bHUTKatObZc7ASXbJJc46b/8fsF0Mc5vCF//0J606XOMKFjiqNPeqmFH5 PDBOiO+9/c2re2Dtb3MhWa0GpuK4wXu1RxxpqirTzUwDqGZK/EB8zz2pAsXG63Keocln mvurLrun63Zi6hX4gAlMTmiQYBFNrdqaeHGFqnpk59YQBDGa5z36Sh7gFwOJ/hq8QZos BJPgQztk7hV0esl/wRIR6WMg4OAQqXnBAlCI4R8q1jc3ldlqAunCJ8bYDgVASZ567wHr RZMw== X-Gm-Message-State: AO0yUKV6KVK7JKrmelRYvckIDplzx9l65oZYjTpa8IwSp47aFujymU3f aWk38/hOIyfKg48Ap9DSSoo= X-Google-Smtp-Source: AK7set9D2JCOPOq+Q3kqgYPbsRDk8SwPhwusBMHWz8EnIyW9aZ3DBESEGgcEQqc8GXB/PnCFv19vZg== X-Received: by 2002:a05:600c:290:b0:3eb:37ce:4c3d with SMTP id 16-20020a05600c029000b003eb37ce4c3dmr187022wmk.38.1679332267628; Mon, 20 Mar 2023 10:11:07 -0700 (PDT) Received: from localhost (host86-146-209-214.range86-146.btcentralplus.com. [86.146.209.214]) by smtp.gmail.com with ESMTPSA id n13-20020a05600c3b8d00b003e8dcc67bdesm17587266wms.30.2023.03.20.10.11.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Mar 2023 10:11:06 -0700 (PDT) Date: Mon, 20 Mar 2023 17:11:06 +0000 From: Lorenzo Stoakes To: "Liam R. Howlett" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , David Hildenbrand , Matthew Wilcox , Vlastimil Babka , maple-tree@lists.infradead.org Subject: Re: [PATCH 2/4] mm/mmap/vma_merge: set next to NULL if not applicable Message-ID: <3d4bcc71-dfab-44c1-a3aa-c5d7437b6a0d@lucifer.local> References: <4d717269303d8a6fe1d837968c252eeb6ff1d7e5.1679137163.git.lstoakes@gmail.com> <20230320162708.xq64y4ig6f3sf747@revolver> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230320162708.xq64y4ig6f3sf747@revolver> X-Rspamd-Queue-Id: 0B2A61C000D X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: wg6zrshd7cfmuh1ttn31m5ixoaoa7kxr X-HE-Tag: 1679332268-31639 X-HE-Meta: U2FsdGVkX1+71+rJozjboSH9ddvBzHbt/g34qvG5bYj3+8Ij0XHdUMaGl3ML28RIfneiZnz1DpBKUGEotdJ3XaX4c5yDk0Rl1tSQk7GHYwJjZquD0QBx8QKSY5wD6Q2vqQx9P37PI09YoiTxbZtTANLB4nPdigcEBr0RDpni7OdBOOakA5bixS21+Un9HKHDs4JXWqSGvOklxKZ48vjplDkh5aCL/7DtPtliV3NTBSvDl49/16IXD6WdexXzKFsheYGGFFoVCcSPAu9Ii42gwnqBLBxwPCyMIlW0PcP98vyyA0atDeEE4SMcl0GBVpnRINJma6u0ivYv+qjnPxFgoEjhdfVn8WrEZkL+SWzraGecj5dv/nuqeHpFZAW7mPCqMh7oue4qGSuM8LPL6q8pNBWNxYMAc4IM0dchKzxdr3xep2dURie22Hi5zHdEaBLWHxsfeE04/5UuLmAY5sVb/uCTZOrgAviDqbHKYUdijDuAABWx7yLNreDxzlI4OyKGvMmzsyDMQuFqef+O+9jTGjgg5dDM9+8Oe9fsZImjVxZAACX1vWFRpv6UkTKKMmRg91q5VqfBcvpx6tVuljdTkEqTaQG0myil3ZsrVSROfwhCZ37UjmKc0+dYIkGpK9ZybHuiGQlrVN8TKU595kv6lseB+PtBR6p5AE8Zp/l9kmrOGi+X6pF5SLuI6yv3y7TBLlfeRTbwf+z6EaIDOTcH+MyvB/PoTDl8PsuUP7VfNS/oJAZ1qSfKWDFi4XHDcrKneH0XZh2PRe4TPeAtO94gT08RFRExzAdr1Jav9HuDpfAmdEPHanqSBhsopYyaFi1592G97+zWTG5WovI2Tj+PsCtbtI6erj1CpQB5eGsrTmP5XNZ2uNF5Z/ezU+V2mAGzmjfFUDUhUjUWfyNkoheyLGAgo+9UVmjNfsbXvnYZ+WENK8nofV4xdvYevkctBNVhHqYk+9biBsv7k+/yxqf Rr9e4P06 /8iWhcs/zOdAES2XP+gyqwZrcaPOgC1H6IcNhRi0e7MMH62zG1rvZNvXIIRz9v7Z3GXnqtNT2Sa1InXvlnU1oaHWcVGOXtyN6PnKThVbmMVqG2DBIFmnfbGFKhQ5n20q2CtAMqiWwNlwYHyC3WFBfhRWE9/wKU8f97VzYX7vpBkaqQFfCtQJQLOqiuOufWRrwtIzePqeyB/H/jTVya00VBkVmYpE4p6i8Y5CvrJ00sXiBfSOu68cdE1ofLUBY1jdNV/pwUtMe/56IHTTUvmL0cV2c1FLntgzwpUr1HF/WG3bOvwm+vU3KmdgDG1bSFhxh38AZg4Ut2o7o41R12WvA1N1qc+0jYAqGUBvp80gUDr2ttevwiL0LYdSmppMwYeMC+pyNhZuly6LVnm1PUkbqvnUeUCthOn1MI0NkUjc0FZSNYlo3gsemInF+mLNA1rBdYrUBg2x4dUUkE2fTM/Lcq+Jbrmvkie2kKX2v 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: On Mon, Mar 20, 2023 at 12:27:08PM -0400, Liam R. Howlett wrote: > * Lorenzo Stoakes [230318 07:15]: > > We are only interested in next if end == next->vm_start (in which case we > > check to see if we can set merge_next), so perform this check alongside > > checking whether curr should be set. > > > > This groups all of the simple range checks together and establishes the > > invariant that, if prev, curr or next are non-NULL then their positions are > > as expected. > > > > Additionally, use the abstract 'vma' object to look up the possible curr or > > next VMA in order to avoid any confusion as to what these variables > > represent - now curr and next are assigned once and only once. > > > > This has no functional impact. > > > > Signed-off-by: Lorenzo Stoakes > > --- > > mm/mmap.c | 61 ++++++++++++++++++++++++++++++++++++++++++++----------- > > 1 file changed, 49 insertions(+), 12 deletions(-) > > > > diff --git a/mm/mmap.c b/mm/mmap.c > > index c9834364ac98..66893fc72e03 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -930,15 +930,53 @@ struct vm_area_struct *vma_merge(struct vma_iterator *vmi, struct mm_struct *mm, > > if (vm_flags & VM_SPECIAL) > > return NULL; > > > > - 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 = curr; > > + /* > > + * If there is a previous VMA specified, find the next, otherwise find > > + * the first. > > + */ > > + vma = find_vma(mm, prev ? prev->vm_end : 0); > > + > > + /* > > + * Does the input range span an existing VMA? If so, we designate this > > + * VMA 'curr'. The caller will have ensured that curr->vm_start == addr. > > + * > > + * Cases 5 - 8. > > + */ > > + if (vma && end > vma->vm_start) { > > + curr = vma; > > It might be better to set: > curr = find_vma_intersection(mm, prev ? prev->vm_end : 0, end); > > > > > - /* In cases 1 - 4 there's no CCCC vma */ > > - if (curr && end <= curr->vm_start) > > + /* > > + * If the addr - end range spans this VMA entirely, then we > > + * check to see if another VMA follows it. > > + * > > + * If it is _immediately_ adjacent (checked below), then we > > + * designate it 'next' (cases 6 - 8). > > + */ > > + if (curr->vm_end == end) > > + vma = find_vma(mm, curr->vm_end); > > You can change this to: > next = vma_lookup(mm, curr->vm_end); > Then you don't need to validate below, in this case. > > > + else > > + /* Case 5. */ > > + vma = NULL; > > > > + } else { > > + /* > > + * The addr - end range either spans the end of prev or spans no > > + * VMA at all - in either case we dispense with 'curr' and > > + * maintain only 'prev' and (possibly) 'next'. > > Possibly next here would be: > next = vma_lookup(mm, end); > I think? > > > + * > > + * Cases 1 - 4. > > + */ > > curr = NULL; > > + } > > + > > + /* > > + * We only actually examine the next VMA if it is immediately adjacent > > + * to end which sits either at the end of a hole (cases 1 - 3), PPPP > > + * (case 4) or CCCC (cases 6 - 8). > > + */ > > + if (vma && end == vma->vm_start) > > + next = vma; > > + else > > + next = NULL; > > If I'm correct above, then we can drop this next checking. > > > > > /* verify some invariant that must be enforced by the caller */ > > VM_WARN_ON(prev && addr <= prev->vm_start); > > @@ -959,11 +997,10 @@ struct vm_area_struct *vma_merge(struct vma_iterator *vmi, struct mm_struct *mm, > > } > > } > > /* Can we merge the successor? */ > > - if (next && end == next->vm_start && > > - mpol_equal(policy, vma_policy(next)) && > > - can_vma_merge_before(next, vm_flags, > > - anon_vma, file, pgoff+pglen, > > - vm_userfaultfd_ctx, anon_name)) { > > + if (next && mpol_equal(policy, vma_policy(next)) && > > + can_vma_merge_before(next, vm_flags, > > + anon_vma, file, pgoff+pglen, > > + vm_userfaultfd_ctx, anon_name)) { > > I think we can keep this chunk with the next = vma_lookup() changes as > well. > > > merge_next = true; > > } > > > > -- > > 2.39.2 > > Thanks, I will investigate all of these and will try to apply everything that is workable from here + respin.