All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Lorenzo Stoakes <lstoakes@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Matthew Wilcox <willy@infradead.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	patches@lists.linux.dev, maple-tree@lists.infradead.org
Subject: Re: [PATCH 09/10] mm/mmap: start distinguishing if vma can be removed in mergeability test
Date: Thu, 16 Mar 2023 11:57:01 +0100	[thread overview]
Message-ID: <74f2ea6c-f1a9-6dd7-260c-25e660f42379@suse.cz> (raw)
In-Reply-To: <7e0e33a7-4e9b-4714-8d4b-9487c8d1f799@lucifer.local>


On 3/15/23 23:05, Lorenzo Stoakes wrote:
> On Thu, Mar 09, 2023 at 12:12:57PM +0100, Vlastimil Babka wrote:
>> --- a/mm/mmap.c
>> +++ b/mm/mmap.c
>> @@ -742,12 +742,13 @@ int vma_shrink(struct vma_iterator *vmi, struct vm_area_struct *vma,
>>
>>  /*
>>   * If the vma has a ->close operation then the driver probably needs to release
>> - * per-vma resources, so we don't attempt to merge those.
>> + * per-vma resources, so we don't attempt to merge those in case the caller
>> + * indicates the current vma may be removed as part of the merge.
> 
> Nit: 'in case the caller indicates' -> 'if the caller indicates'

Ok, -fix patch below.
 
...

>> -	if (is_mergeable_vma(vma, file, vm_flags, vm_userfaultfd_ctx, anon_name) &&
>> +	if (is_mergeable_vma(vma, file, vm_flags, vm_userfaultfd_ctx, anon_name, false) &&
>>  	    is_mergeable_anon_vma(anon_vma, vma->anon_vma, vma)) {
>>  		pgoff_t vm_pglen;
>>  		vm_pglen = vma_pages(vma);
>> --
>> 2.39.2
>>
> 
> I wonder whether this might be moved later into the actual vma_merge() logic so
> we only abort a merge at the point a VMA with ->close() would otherwise be
> removed? But obviously that would probably need some further clean up to make it
> not add yet more complexity to an already very complicated bit of logic.

Yeah, can try that later to cover the remaining cases where
->close prevents merging unnecessarily.

> Otherwise, very nice, clear + conservative so,
> 
> Reviewed-By: Lorenzo Stoakes <lstoakes@gmail.com>

Thanks!

----8<----
From b8072720288491bdc887ebebbb099babcfb108a5 Mon Sep 17 00:00:00 2001
From: Vlastimil Babka <vbabka@suse.cz>
Date: Thu, 16 Mar 2023 11:54:27 +0100
Subject: [PATCH] mm/mmap: start distinguishing if vma can be removed in
 mergeability test-fix

Adjust comment as suggested by Lorenzo.

Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
 mm/mmap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index 4259095a2982..b255e6352710 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -742,8 +742,8 @@ int vma_shrink(struct vma_iterator *vmi, struct vm_area_struct *vma,
 
 /*
  * If the vma has a ->close operation then the driver probably needs to release
- * per-vma resources, so we don't attempt to merge those in case the caller
- * indicates the current vma may be removed as part of the merge.
+ * per-vma resources, so we don't attempt to merge those if the caller indicates
+ * the current vma may be removed as part of the merge.
  */
 static inline bool is_mergeable_vma(struct vm_area_struct *vma,
 		struct file *file, unsigned long vm_flags,
-- 
2.39.2



  reply	other threads:[~2023-03-16 10:57 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-09 11:12 [PATCH 00/10] cleanup vma_merge() and improve mergeability tests Vlastimil Babka
2023-03-09 11:12 ` [PATCH 01/10] mm/mmap/vma_merge: use only primary pointers for preparing merge Vlastimil Babka
2023-03-14 22:52   ` Lorenzo Stoakes
2023-03-09 11:12 ` [PATCH 02/10] mm/mmap/vma_merge: use the proper vma pointer in case 3 Vlastimil Babka
2023-03-15 19:04   ` Lorenzo Stoakes
2023-03-09 11:12 ` [PATCH 03/10] mm/mmap/vma_merge: use the proper vma pointers in cases 1 and 6 Vlastimil Babka
2023-03-15 19:43   ` Lorenzo Stoakes
2023-03-09 11:12 ` [PATCH 04/10] mm/mmap/vma_merge: use the proper vma pointer in case 4 Vlastimil Babka
2023-03-15 19:54   ` Lorenzo Stoakes
2023-03-09 11:12 ` [PATCH 05/10] mm/mmap/vma_merge: initialize mid and next in natural order Vlastimil Babka
2023-03-15 20:10   ` Lorenzo Stoakes
2023-03-09 11:12 ` [PATCH 06/10] mm/mmap/vma_merge: set mid to NULL if not applicable Vlastimil Babka
2023-03-15 21:34   ` Lorenzo Stoakes
2023-03-16 10:11     ` Vlastimil Babka
2023-03-09 11:12 ` [PATCH 07/10] mm/mmap/vma_merge: rename adj_next to adj_start Vlastimil Babka
2023-03-14 22:36   ` Lorenzo Stoakes
2023-03-15 21:38   ` Lorenzo Stoakes
2023-03-09 11:12 ` [PATCH 08/10] mm/mmap/vma_merge: convert mergeability checks to return bool Vlastimil Babka
2023-03-15 21:43   ` Lorenzo Stoakes
2023-03-09 11:12 ` [PATCH 09/10] mm/mmap: start distinguishing if vma can be removed in mergeability test Vlastimil Babka
2023-03-15 22:05   ` Lorenzo Stoakes
2023-03-16 10:57     ` Vlastimil Babka [this message]
2023-03-09 11:12 ` [PATCH 10/10] mm/mremap: simplify vma expansion again Vlastimil Babka
2023-03-15 22:20   ` Lorenzo Stoakes
2023-03-16  8:35     ` Vlastimil Babka
2023-03-20 14:16 ` [PATCH 00/10] cleanup vma_merge() and improve mergeability tests Liam R. Howlett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=74f2ea6c-f1a9-6dd7-260c-25e660f42379@suse.cz \
    --to=vbabka@suse.cz \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lstoakes@gmail.com \
    --cc=maple-tree@lists.infradead.org \
    --cc=patches@lists.linux.dev \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.