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 26407C48BF8 for ; Tue, 20 Feb 2024 03:00:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AC9F26B007B; Mon, 19 Feb 2024 22:00:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A7A946B0092; Mon, 19 Feb 2024 22:00:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 91B616B0093; Mon, 19 Feb 2024 22:00:43 -0500 (EST) 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 7BECC6B007B for ; Mon, 19 Feb 2024 22:00:43 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 13249140572 for ; Tue, 20 Feb 2024 03:00:43 +0000 (UTC) X-FDA: 81810679566.12.3A8928F Received: from out-175.mta0.migadu.com (out-175.mta0.migadu.com [91.218.175.175]) by imf23.hostedemail.com (Postfix) with ESMTP id 23C9714001D for ; Tue, 20 Feb 2024 03:00:40 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=nsT3mVFg; spf=pass (imf23.hostedemail.com: domain of yajun.deng@linux.dev designates 91.218.175.175 as permitted sender) smtp.mailfrom=yajun.deng@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708398041; 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=62UrT3cpno7hjOTET/L8V6znazoo6gcdnhOZELLpvOg=; b=Oa9Yli/AnR+1i5tvrn4U8pVqhi46MB5sEDwYhm1qXVTitj9G3R3TkJjWDAhaCQ6dSVkE2S kE5gR1lvuhZxtxRKE/3l21vMl/qSITCnXiktrKKIE//+JyxNmZOZZDW6oL+ZTZ6juTCKvg 6eM/wSzqLPmO9gvSsYhKhjBrXA5fDCs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708398041; a=rsa-sha256; cv=none; b=dfIIgILRJzPPN0rTP5RAhM8iVS2vgJMPaSS3J0kfIyQVVJ+lF7A9Vj/SJ1sHj8v8wP0C02 kSrZOaRMt0LhDM542ZWWEvxV7QFccZtR5E/W9g2LtnU+9wuth6yWXNsqH97PAzEs0GlKVT EPhBcgG7rkQV8Xy0GH31nKLdP6VGNbg= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=nsT3mVFg; spf=pass (imf23.hostedemail.com: domain of yajun.deng@linux.dev designates 91.218.175.175 as permitted sender) smtp.mailfrom=yajun.deng@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1708398038; 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=62UrT3cpno7hjOTET/L8V6znazoo6gcdnhOZELLpvOg=; b=nsT3mVFgyVJ0bpvazA4AAzDjc6tKuQNkUFJ3C0+h2znZUJLLt9m74fQfduAIyqsvPqC6TN sZJEicTasuFWRdnh5ChoMlRLb4rPd5XexpsclW+/i0b0uL/P0tgKJ9DxHzdoQ/I5QC8FcV 7tujUbBsrxw3+9vrGzBKScL+pL9VGgE= Date: Tue, 20 Feb 2024 11:00:30 +0800 MIME-Version: 1.0 Subject: Re: [PATCH] mm/mmap: Add case 9 in vma_merge() Content-Language: en-US To: Lorenzo Stoakes Cc: akpm@linux-foundation.org, Liam.Howlett@oracle.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, vbabka@suse.cz References: <20240218085028.3294332-1-yajun.deng@linux.dev> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Yajun Deng In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 23C9714001D X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: ux9c6hsn6idyqxo8rr94tc59szpo99ty X-HE-Tag: 1708398040-727331 X-HE-Meta: U2FsdGVkX1935cVczaiS3BiIIwyolHaqyW7SOPJSq/ratZPPjjQGOlNMDr2IPJRtgqej8BMISKo8y8Ahz/uf/9QMZh8of6YBpdgjXaqRm//0Y1kdQvXaXcobqfwegEeBcrjU+vqoKz2Flqx6uaCIiuChJD4GzYSG6DvaINoq+8sU3Et5ar0d8mQHfkhIRwz6L1ZCq3frO1zHaXnpG3glnotKF7KLJcZ7rWWLa0fwcAMc50iDj/8qB97wHR8+b99cXSeCsg8V7LzFWijmW9kZnvsFuVCOfOnVzAmL6xODXJegMkFaV8gT8N3Z3j3pLx7U9gqWAEGas+m1Q/HjTcpKQikyxuzx23WmPw2IEXPYWgp4y/UYrKZsNtAaYZtPbXTEEHsL4FBrBDMu+6vsw6WXk+zjgE/UphX2q8r7S00xrPlM40ZHk8aCEvRUWvfbjByrdptUyNpoOfYWi3pimFjWYwCr7IQc+VV3vve0Z8t6aHWpvuFSYBIylWpM0xnTGWDzlcqEzRFN98Wy4svNO+CYhLKKmYNwbX72crDf+OUF7AsOWE0UZMY8aIbMaYhBxIDPfMSXjN7Uv3yb2CqLw8Fw6+M8XpywfYM0GauDU8yDzXRJJtskk5ctJl4gNijN9KMMod4zcMq+9+gbleossldFZeGjEOV4LUfhhiXkPMw2qgAv0m3RipBoTyRN/bzfhkH0yQjULGxJVI1obzLiuouZs0nA0+g2GkU2TXoOLMpa5KOIryIuZ4c15fbOlvup22ChCD3yGIDxOwvIz5rkF4O8lqA0F+rF6kfnxNO+2II6LvH8CwKA1vBRyhnKuLIGigCep4Sb0UjRPhifpaTYXcV0vomnKY6C1iHIC3d+3FXAaDXr2JZz82jz5FsKCD0VKt5cv0t+S/zB/u7cbkxvjnZrKrk/LCCX7lEaezOB665igUpqh36v6GkJ/vAkIx1RBnf7TDxMokvSW98D6T8h+S6 BqDrlmjv aQZmY/5NB30QY6YkogmGlUavSWpI/ft2LMReMoZW/xkeZDccmmzROWkSyDS56LajkscCx+FxEk/DAsQcpAo71yvUe/faSYakBAPoZm3BcPh7XdJmdUfTKxND2cjrNFMLQpEN6a5ewlAI67ZE= 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: List-Subscribe: List-Unsubscribe: On 2024/2/19 07:03, Lorenzo Stoakes wrote: > On Sun, Feb 18, 2024 at 04:50:28PM +0800, Yajun Deng wrote: >> If the prev vma exists and the end is less than the end of prev, we >> can return NULL immediately. This reduces unnecessary operations. >> >> Signed-off-by: Yajun Deng > Adding Vlastimil, while get_maintainers.pl might not show it very clearly, > myself, Vlastimil and Liam often work with vma_merge() so it's handy to cc > us on these if you can! Okay. >> --- >> mm/mmap.c | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/mm/mmap.c b/mm/mmap.c >> index 8f176027583c..b738849321c0 100644 >> --- a/mm/mmap.c >> +++ b/mm/mmap.c >> @@ -827,7 +827,7 @@ can_vma_merge_after(struct vm_area_struct *vma, unsigned long vm_flags, >> * >> * **** **** **** >> * PPPPPPNNNNNN PPPPPPNNNNNN PPPPPPCCCCCC >> - * cannot merge might become might become >> + * cannot merge 9 might become might become > While I welcome your interest here :) I am not a fan of the 'case' approach > to this function as-is and plan to heavily refactor this when I get a chance. > > But at any rate, an early-exit situation is not a merge case, merge cases > describe cases where we _can_ merge, so we can drop this case 9 stuff (this > is not your fault, it's understandable why you would label this, this > function is just generally unclear). Yes, it's not a merge case. I label this to make it easier to understand. >> * PPNNNNNNNNNN PPPPPPPPPPCC >> * mmap, brk or case 4 below case 5 below >> * mremap move: >> @@ -890,6 +890,9 @@ static struct vm_area_struct >> if (vm_flags & VM_SPECIAL) >> return NULL; >> >> + if (prev && end < prev->vm_end) /* case 9 */ >> + return NULL; >> + > I need to get back into vma_merge() head space, but I don't actually think > a caller that's behaving correctly should ever do this. I know the ASCII > diagram above lists it as a thing that can happen, but I think we > implicitly avoid this from the way we invoke callers. Either prev == vma as > per vma_merge_extend(), or the loops that invoke vma_merge_new_vma() > wouldn't permit this to occur. No, it will actually happen. That's why I submitted this patch. > Let me look into it more deeply + reply again a bit later, I mean we could > perhaps do with asserting this somehow, but I don't think it's useful to do > an early exit for something that ostensibly _shouldn't_ happen. > >> /* Does the input range span an existing VMA? (cases 5 - 8) */ >> curr = find_vma_intersection(mm, prev ? prev->vm_end : 0, end); >> >> -- >> 2.25.1 >>