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 7A7A8C48BC4 for ; Sun, 18 Feb 2024 23:06:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E36A8D0003; Sun, 18 Feb 2024 18:06:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 793338D0002; Sun, 18 Feb 2024 18:06:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 630DA8D0003; Sun, 18 Feb 2024 18:06:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 522268D0002 for ; Sun, 18 Feb 2024 18:06:19 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B7902160175 for ; Sun, 18 Feb 2024 23:06:18 +0000 (UTC) X-FDA: 81806460036.15.53D1DC7 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by imf23.hostedemail.com (Postfix) with ESMTP id 01C1814000C for ; Sun, 18 Feb 2024 23:06:15 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=lChnGi6G; spf=pass (imf23.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.50 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=1708297576; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=hZYwbs0hT6XgKoPOkjoQHSc7t5jEfrmq2mFVWPjwFrA=; b=aRAkTwHGgs9JhlA9Ic8YC5Jrr73RhV3YSMnCdp5d+oTQBC4+QnJIi4KkTIZOFWDxYG2xKW im/oVwKdFmzbQZNT8utiTAVqbvOjoEs8Rv6JmrBGC4BONQt8Lb/iIYOt5oZkOKPPsqBPK0 sZ9W66OwfQ7OBZTV7JArPlA5NJJQcYs= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=lChnGi6G; spf=pass (imf23.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.50 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=1708297576; a=rsa-sha256; cv=none; b=Gs9Q+I5PjexwBemnXjjVgFDtXf0u6vunU+4X76heiW2PekezlPxJAvgw4PmT4UKlbS6ouh hu4L0nQdzmJHfNJYdp78vXZIDxLxxPrMylABrlbEg1HPSmmwdpgQS0yEeQxk51FMh7pkaq sDOqqahV5jZX6ViDuxLvoduYRE6MYRM= Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4125edd1433so9280325e9.3 for ; Sun, 18 Feb 2024 15:06:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708297574; x=1708902374; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=hZYwbs0hT6XgKoPOkjoQHSc7t5jEfrmq2mFVWPjwFrA=; b=lChnGi6GI+cVoBlfEopqBNZ6jr5aId3e+jelS66RXv6EdBQMlRLMypdCbcXONGqh/X GOMV+KZOGpJl+oxChqvhprfmGUuKPlAwd8B5Nit9d0bn6onZMeB5nCQ7EIz2wWWZwYbt M1j8Y/6yYuAqsBtjvJf7EbgIgokWexn0Q/6velkvQfaVfCt8I7GlKjEA5choyZU5PVcf 5kiLn6gw6tPPVgpkyTv+A/oEwl59YHs3/iGelgVGCX77aTVTeDNeqzZxXd47yyuXiAln YDNYoX1RsG7DGl+Irkf7DYtz5ekZSlX7l99PrfjjvvgPReLyVsROJzLWeXyock6nQ0ia MZPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708297574; x=1708902374; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hZYwbs0hT6XgKoPOkjoQHSc7t5jEfrmq2mFVWPjwFrA=; b=YzRIK7wakeNENGUyHn6SM8ALjvLLcPx78iNdRce11SNTDTR5rfVARv1srPIi5VUQcI yVgDPPipWQmmgruCsBucF4AOExfcSw0ONtrXXybbiMikU0N+WP2S3s4U3//H9ZEcusyj /GGEMGijKn0QGqSSVhA3RLfipvnq5vE1LWZHEuJ54km9KI7QD0fvMoUvGJaIzzNU07gL OaALJze/5py4ZkWReIewr7g1VMSF7iEklp3O9AFS3tz3uKk1us5JMCDi6xrIK48CF7Z4 88ggnXboe46ACSyicl+LQ8zXdFA1dB2xSquxg0lq6S+2/K/F/4IRcESu0Gn2LR8Z5LYU jv6A== X-Forwarded-Encrypted: i=1; AJvYcCUnUwaXny4Tk2M3vYXDGNRti3XPbQBltrjs2zut9LpphWyLE5z1RxqWyLIZjIgqTml2F9q11FLeDtgcEyMJBns3ZO0= X-Gm-Message-State: AOJu0YyL0btohtCg7zuKl38HwhoswIgUu5jzHEldZB4628jria0HK7KC sRM+fllvEknO/r1+9Rd6MLE4laWqZ/AbZEw4O3Q4bvzSS7+2efth X-Google-Smtp-Source: AGHT+IFfsgFbsxq4soP1Z2GRcSLOZ+0kTntkGcPP34eWmwvFtWvoL+zVmEaUlO+++jirsuRbhXzAsQ== X-Received: by 2002:a05:6000:1ac6:b0:33b:1bcc:7ed9 with SMTP id i6-20020a0560001ac600b0033b1bcc7ed9mr7854417wry.44.1708297574149; Sun, 18 Feb 2024 15:06:14 -0800 (PST) Received: from localhost (host86-164-109-77.range86-164.btcentralplus.com. [86.164.109.77]) by smtp.gmail.com with ESMTPSA id i3-20020a05600011c300b0033cf453f2bbsm8544712wrx.35.2024.02.18.15.06.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 18 Feb 2024 15:06:13 -0800 (PST) Date: Sun, 18 Feb 2024 23:03:58 +0000 From: Lorenzo Stoakes To: Yajun Deng Cc: akpm@linux-foundation.org, Liam.Howlett@oracle.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, vbabka@suse.cz Subject: Re: [PATCH] mm/mmap: Add case 9 in vma_merge() Message-ID: References: <20240218085028.3294332-1-yajun.deng@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240218085028.3294332-1-yajun.deng@linux.dev> X-Rspamd-Queue-Id: 01C1814000C X-Rspam-User: X-Stat-Signature: nzzsybpbu7f9jtrtnjbnsub5jh68rcpo X-Rspamd-Server: rspam01 X-HE-Tag: 1708297575-775813 X-HE-Meta: U2FsdGVkX18EcxZiM1GTtW1loYjFId8jpHJqHswIIlKDUb/RhLp2O25m7ukG/IcXqau9d+ey+vyeIvaOI1l+jkWRdNQB+ZmUqJ6X2Hyr7PpDrwisTwrXzN6gCaCuCkGzA7Y2jsArG4sE9ts2HTPtDohCuvUUuEH3zIMhtolpgGatdth1ydot0ezjrnMddDR/m8WhHYgIL46xzHbbJD7C0DkogC0l9DLMNdxxwp96DXKUrJw6uB6N06sz+rAnzDrDuGk+/ZAqZuNAViizF/FbxuzYoH8/eCUgpFsJ92rBu4bmTiuadzPeX8GpQTFgycruawvg7DlHLCHEwGhriB5bF7AN/fZt/sgJBdnKrIsSoX7tWVMLriNmcbG+wW1p98Dz257jWPW+lHngavtNEUiG3qZQglHXLW/iAsoncXbKfaINN7mBWK9VXxK1eddSpL6L/SqDgyHGUOPAJ+5Ql5f7xtpRedw4t9Qu5KeoiScYtuIRgLgC1dwCR+Ex0GihTXFBXxHcpohjfXvYleKJPEti9dDSqLggDOGfr5Lmz3Q8lmq73q3ee9Gv7md26hUgenGofzWcZqY6TNo46psys+wl0jyVeKv8IFpVP7Eutq+ox/egZ2KLdjdOiiAq3QEAtlc1pm/sYiWIh6yLK5g08blIZeSe+Zg3sWoPXIfrFAEVEj6c8nRyjVKsqPLLUiXaYtZwjVihpgjrDeV6q+q+vL6E8FT1pRn0DymegZN79vxZN//fHYlBolsxIP7JQEv+TW2jD3p/gzK0OqnRyfbJ13ylNPVDNuG94NRhDIUi0mTtWHixUQKnL/IHHgrXrJ9tTjTQighSfFdIB/vCFR34z4UnvV+zrFWe1OgrfRbRyTL2U0v2v6rv89zSqli+1bpMQpBx8+YCQxPBNriqsUzId6pUGVazoQJbqZmUU3sridpBm5JNb6zWhIpxBrBWNRLqLTw+ggpYNXdoWMvniT3yiBW e8X2YCog N6QQMu04W6w/WNc39kMbhDtb1iOOl7rS2nbAEW6/VTOBA41ftFEPBdFUivwYGSICYjwfGSprUvrGS6zQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.070258, 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 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! > --- > 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). > * 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. 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 >