All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harry Yoo <harry.yoo@oracle.com>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	"Liam R . Howlett" <Liam.Howlett@oracle.com>,
	Vlastimil Babka <vbabka@suse.cz>, Jann Horn <jannh@google.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/7] mm/mremap: correctly handle partial mremap() of VMA starting at 0
Date: Mon, 3 Mar 2025 22:26:08 +0900	[thread overview]
Message-ID: <Z8Wt8HrxZeMkKtF5@harry> (raw)
In-Reply-To: <195c3956c70a142b12465e09b4aa5e33a898b789.1740911247.git.lorenzo.stoakes@oracle.com>

On Mon, Mar 03, 2025 at 11:08:31AM +0000, Lorenzo Stoakes wrote:
> Consider the case of a a partial mremap() (that results in a VMA split) of
> an accountable VMA (i.e. which has the VM_ACCOUNT flag set) whose start
> address is zero, with the MREMAP_MAYMOVE flag specified and a scenario
> where a move does in fact occur:
> 
>        addr  end
>         |     |
>         v     v
>     |-------------|
>     |     vma     |
>     |-------------|
>     0
> 
> This move is affected by unmapping the range [addr, end). In order to
> prevent an incorrect decrement of accounted memory which has already been
> determined, the mremap() code in move_vma() clears VM_ACCOUNT from the VMA
> prior to doing so, before reestablishing it in each of the VMAs post-split:
> 
>     addr  end
>      |     |
>      v     v
>  |---|     |---|
>  | A |     | B |
>  |---|     |---|
> 
> Commit 6b73cff239e5 ("mm: change munmap splitting order and move_vma()")
> changed this logic such as to determine whether there is a need to do so by
> establishing account_start and account_end and, in the instance where such
> an operation is required, assigning them to vma->vm_start and vma->vm_end.
> 
> Later the code checks if the operation is required for 'A' referenced above
> thusly:
> 
> 	if (account_start) {
> 		...
> 	}
> 
> However, if the VMA described above has vma->vm_start == 0, which is now
> assigned to account_start, this branch will not be executed.
> 
> As a result, the VMA 'A' above will remain stripped of its VM_ACCOUNT flag,
> incorrectly.
> 
> The fix is to simply convert these variables to booleans and set them as
> required.
> 
> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Fixes: 6b73cff239e5 ("mm: change munmap splitting order and move_vma()")
> Cc: stable@vger.kernel.org
> ---

Looks good to me,
Reviewed-by: Harry Yoo <harry.yoo@oracle.com>

-- 
Cheers,
Harry

>  mm/mremap.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/mm/mremap.c b/mm/mremap.c
> index cff7f552f909..c3e4c86d0b8d 100644
> --- a/mm/mremap.c
> +++ b/mm/mremap.c
> @@ -705,8 +705,8 @@ static unsigned long move_vma(struct vm_area_struct *vma,
>  	unsigned long vm_flags = vma->vm_flags;
>  	unsigned long new_pgoff;
>  	unsigned long moved_len;
> -	unsigned long account_start = 0;
> -	unsigned long account_end = 0;
> +	bool account_start = false;
> +	bool account_end = false;
>  	unsigned long hiwater_vm;
>  	int err = 0;
>  	bool need_rmap_locks;
> @@ -790,9 +790,9 @@ static unsigned long move_vma(struct vm_area_struct *vma,
>  	if (vm_flags & VM_ACCOUNT && !(flags & MREMAP_DONTUNMAP)) {
>  		vm_flags_clear(vma, VM_ACCOUNT);
>  		if (vma->vm_start < old_addr)
> -			account_start = vma->vm_start;
> +			account_start = true;
>  		if (vma->vm_end > old_addr + old_len)
> -			account_end = vma->vm_end;
> +			account_end = true;
>  	}
>  
>  	/*
> @@ -832,7 +832,7 @@ static unsigned long move_vma(struct vm_area_struct *vma,
>  		/* OOM: unable to split vma, just get accounts right */
>  		if (vm_flags & VM_ACCOUNT && !(flags & MREMAP_DONTUNMAP))
>  			vm_acct_memory(old_len >> PAGE_SHIFT);
> -		account_start = account_end = 0;
> +		account_start = account_end = false;
>  	}
>  
>  	if (vm_flags & VM_LOCKED) {
> -- 
> 2.48.1
> 
> 


  reply	other threads:[~2025-03-03 13:26 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-03 11:08 [PATCH 0/7] refactor mremap and fix bug Lorenzo Stoakes
2025-03-03 11:08 ` [PATCH 1/7] mm/mremap: correctly handle partial mremap() of VMA starting at 0 Lorenzo Stoakes
2025-03-03 13:26   ` Harry Yoo [this message]
2025-03-03 16:09   ` Liam R. Howlett
2025-03-05 11:50   ` Vlastimil Babka
2025-03-05 19:46     ` Lorenzo Stoakes
2025-03-03 11:08 ` [PATCH 2/7] mm/mremap: refactor mremap() system call implementation Lorenzo Stoakes
2025-03-03 17:12   ` Liam R. Howlett
2025-03-03 17:20     ` Lorenzo Stoakes
2025-03-03 18:50       ` Liam R. Howlett
2025-03-05  1:47   ` Harry Yoo
2025-03-05 11:23     ` Lorenzo Stoakes
2025-03-03 11:08 ` [PATCH 3/7] mm/mremap: introduce and use vma_remap_struct threaded state Lorenzo Stoakes
2025-03-05 18:52   ` Liam R. Howlett
2025-03-05 19:43     ` Lorenzo Stoakes
2025-03-05 19:55       ` Liam R. Howlett
2025-03-03 11:08 ` [PATCH 4/7] mm/mremap: initial refactor of move_vma() Lorenzo Stoakes
2025-03-04 21:45   ` Yosry Ahmed
2025-03-04 23:15     ` Andrew Morton
2025-03-05  5:52       ` Lorenzo Stoakes
2025-03-05 19:20   ` Liam R. Howlett
2025-03-05 20:01     ` Lorenzo Stoakes
2025-03-03 11:08 ` [PATCH 5/7] mm/mremap: complete " Lorenzo Stoakes
2025-03-03 11:08 ` [PATCH 6/7] mm/mremap: refactor move_page_tables(), abstracting state Lorenzo Stoakes
2025-03-03 11:08 ` [PATCH 7/7] mm/mremap: thread state through move page table operation Lorenzo Stoakes
2025-03-03 23:17   ` kernel test robot
2025-03-03 23:30   ` kernel test robot
2025-03-04  0:05     ` Andrew Morton
2025-03-04  0:12       ` Andrew Morton
2025-03-04  5:40         ` Lorenzo Stoakes

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=Z8Wt8HrxZeMkKtF5@harry \
    --to=harry.yoo@oracle.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=jannh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=vbabka@suse.cz \
    /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.