From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: "Liam R. Howlett" <Liam.Howlett@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Jann Horn <jannh@google.com>,
David Hildenbrand <david@redhat.com>,
Qi Zheng <zhengqi.arch@bytedance.com>,
Kefeng Wang <wangkefeng.wang@huawei.com>,
Jeff Xu <jeffxu@chromium.org>,
Pedro Falcato <pedro.falcato@gmail.com>
Subject: Re: [PATCH v2 2/2] mm/mremap: Remove goto from mremap_to()
Date: Mon, 21 Oct 2024 11:19:19 +0100 [thread overview]
Message-ID: <adf4dbf0-f697-4467-8ccb-d35d4a67fb8d@lucifer.local> (raw)
In-Reply-To: <20241018174114.2871880-3-Liam.Howlett@oracle.com>
On Fri, Oct 18, 2024 at 01:41:14PM -0400, Liam R. Howlett wrote:
> From: "Liam R. Howlett" <Liam.Howlett@Oracle.com>
>
> mremap_to() has a goto label at the end that doesn't unwind anything.
> Removing the label makes the code cleaner.
>
> This commit also adds documentation on the function.
>
> Signed-off-by: Liam R. Howlett <Liam.Howlett@Oracle.com>
This is a nice cleanup, thanks!
Other than nits below, LGTM, so:
Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> ---
> mm/mremap.c | 46 +++++++++++++++++++++++++++-------------------
> 1 file changed, 27 insertions(+), 19 deletions(-)
>
> diff --git a/mm/mremap.c b/mm/mremap.c
> index e781ec4573ca..4c79ab92eb8f 100644
> --- a/mm/mremap.c
> +++ b/mm/mremap.c
> @@ -887,6 +887,20 @@ static int resize_is_valid(struct vm_area_struct *vma, unsigned long addr,
> return 0;
> }
>
> +/*
> + * mremap_to() - remap a vma to a new location
> + * @addr: The old address
> + * @old_len: The old size
> + * @new_addr: The target address
> + * @new_len: The new size
> + * @locked: If the returned vma is locked (VM_LOCKED)
> + * @flags: the mremap flags
> + * @uf: The mremap userfaultfd context
> + * @uf_unmap_early: The userfaultfd unmap early context
> + * @uf_unmap: The userfaultfd unmap context
Nit - these are lists of userfaultfd_unmap_ctx rather than contexts. But I
mean, the naming around this is generally not great and not your fault so
not a big deal.
> + *
> + * Returns: The new address of the vma or an error.
> + */
> static unsigned long mremap_to(unsigned long addr, unsigned long old_len,
> unsigned long new_addr, unsigned long new_len, bool *locked,
> unsigned long flags, struct vm_userfaultfd_ctx *uf,
> @@ -895,18 +909,18 @@ static unsigned long mremap_to(unsigned long addr, unsigned long old_len,
> {
> struct mm_struct *mm = current->mm;
> struct vm_area_struct *vma;
> - unsigned long ret = -EINVAL;
> + unsigned long ret;
> unsigned long map_flags = 0;
>
> if (offset_in_page(new_addr))
> - goto out;
> + return -EINVAL;
>
> if (new_len > TASK_SIZE || new_addr > TASK_SIZE - new_len)
> - goto out;
> + return -EINVAL;
>
> /* Ensure the old/new locations do not overlap */
> if (addr + old_len > new_addr && new_addr + new_len > addr)
> - goto out;
> + return -EINVAL;
>
> /*
> * move_vma() need us to stay 4 maps below the threshold, otherwise
> @@ -933,31 +947,28 @@ static unsigned long mremap_to(unsigned long addr, unsigned long old_len,
> */
> ret = do_munmap(mm, new_addr, new_len, uf_unmap_early);
> if (ret)
> - goto out;
> + return ret;
> }
>
> if (old_len > new_len) {
> ret = do_munmap(mm, addr+new_len, old_len - new_len, uf_unmap);
> if (ret)
> - goto out;
> + return ret;
> old_len = new_len;
> }
>
> vma = vma_lookup(mm, addr);
> - if (!vma) {
> - ret = -EFAULT;
> - goto out;
> - }
> + if (!vma)
> + return -EFAULT;
>
> ret = resize_is_valid(vma, addr, old_len, new_len, flags);
> if (ret)
> - goto out;
> + return ret;
>
> /* MREMAP_DONTUNMAP expands by old_len since old_len == new_len */
> if (flags & MREMAP_DONTUNMAP &&
> !may_expand_vm(mm, vma->vm_flags, old_len >> PAGE_SHIFT)) {
> - ret = -ENOMEM;
> - goto out;
> + return -ENOMEM;
> }
>
> if (flags & MREMAP_FIXED)
> @@ -970,17 +981,14 @@ static unsigned long mremap_to(unsigned long addr, unsigned long old_len,
> ((addr - vma->vm_start) >> PAGE_SHIFT),
> map_flags);
Unrelated to your change, but I'm really confused as to why we're doing
this even if MREMAP_FIXED might be set, then ignore its return value if it
is set?
Would be way nicer to do something like:
if (!(flags & MREMAP_FIXED)) {
new_addr = get_unmapped_area(vma->vm_file, new_addr, new_len,
vma->vm_pgoff +
((addr - vma->vm_start) >> PAGE_SHIFT),
map_flags);
if (IS_ERR_VALUE(new_addr))
return new_addr;
}
Anyway one for another series.
I'd say the 'ret' variable is badly named now, but it was badly named
before so there's zero delta on that.
> if (IS_ERR_VALUE(ret))
> - goto out;
> + return ret;
>
> /* We got a new mapping */
> if (!(flags & MREMAP_FIXED))
> new_addr = ret;
>
> - ret = move_vma(vma, addr, old_len, new_len, new_addr, locked, flags, uf,
> - uf_unmap);
> -
> -out:
> - return ret;
> + return move_vma(vma, addr, old_len, new_len, new_addr, locked, flags,
> + uf, uf_unmap);
> }
>
> static int vma_expandable(struct vm_area_struct *vma, unsigned long delta)
> --
> 2.43.0
>
next prev parent reply other threads:[~2024-10-21 10:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-18 17:41 [PATCH v2 0/2] mm/mremap: Remove extra vma tree walk Liam R. Howlett
2024-10-18 17:41 ` [PATCH v2 1/2] mm/mremap: Clean up vma_to_resize() Liam R. Howlett
2024-10-21 10:03 ` Lorenzo Stoakes
2024-10-22 22:08 ` Pedro Falcato
2024-10-23 2:10 ` Liam R. Howlett
2024-10-18 17:41 ` [PATCH v2 2/2] mm/mremap: Remove goto from mremap_to() Liam R. Howlett
2024-10-21 10:19 ` Lorenzo Stoakes [this message]
2024-10-22 22:10 ` Pedro Falcato
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=adf4dbf0-f697-4467-8ccb-d35d4a67fb8d@lucifer.local \
--to=lorenzo.stoakes@oracle.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=jannh@google.com \
--cc=jeffxu@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pedro.falcato@gmail.com \
--cc=wangkefeng.wang@huawei.com \
--cc=zhengqi.arch@bytedance.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox