From: Uladzislau Rezki <urezki@gmail.com>
To: Liu Ye <liuye@kylinos.cn>
Cc: akpm@linux-foundation.org, urezki@gmail.com, hch@infradead.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/vmalloc: Refactoring function __vmalloc_node_range_noprof
Date: Thu, 6 Mar 2025 15:06:15 +0100 [thread overview]
Message-ID: <Z8mr12PilC00Wcvg@pc636> (raw)
In-Reply-To: <20250306072131.800499-1-liuye@kylinos.cn>
On Thu, Mar 06, 2025 at 03:21:31PM +0800, Liu Ye wrote:
> According to the code logic, the first parameter of the sub-function
> __get_vm_area_node should be size instead of real_size.
>
> Then in the function __get_vm_area_node, the size will be aligned,
> so the redundant alignment operation is deleted.
>
> The use of the real_size variable causes code redundancy,
> so it is removed to simplify the code.
>
> The real prefix is generally used to indicate the adjusted value of a
> parameter, but according to the code logic, it should indicate the
> original value, so it is recommended to rename it to original_align.
>
> Signed-off-by: Liu Ye <liuye@kylinos.cn>
> ---
> mm/vmalloc.c | 20 ++++++++------------
> 1 file changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index dc658d4af181..a8488452b70b 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3770,8 +3770,7 @@ void *__vmalloc_node_range_noprof(unsigned long size, unsigned long align,
> struct vm_struct *area;
> void *ret;
> kasan_vmalloc_flags_t kasan_flags = KASAN_VMALLOC_NONE;
> - unsigned long real_size = size;
> - unsigned long real_align = align;
> + unsigned long original_align = align;
> unsigned int shift = PAGE_SHIFT;
>
> if (WARN_ON_ONCE(!size))
> @@ -3780,7 +3779,7 @@ void *__vmalloc_node_range_noprof(unsigned long size, unsigned long align,
> if ((size >> PAGE_SHIFT) > totalram_pages()) {
> warn_alloc(gfp_mask, NULL,
> "vmalloc error: size %lu, exceeds total pages",
> - real_size);
> + size);
> return NULL;
> }
>
> @@ -3797,19 +3796,18 @@ void *__vmalloc_node_range_noprof(unsigned long size, unsigned long align,
> else
> shift = arch_vmap_pte_supported_shift(size);
>
> - align = max(real_align, 1UL << shift);
> - size = ALIGN(real_size, 1UL << shift);
> + align = max(original_align, 1UL << shift);
> }
>
> again:
> - area = __get_vm_area_node(real_size, align, shift, VM_ALLOC |
> + area = __get_vm_area_node(size, align, shift, VM_ALLOC |
> VM_UNINITIALIZED | vm_flags, start, end, node,
> gfp_mask, caller);
> if (!area) {
> bool nofail = gfp_mask & __GFP_NOFAIL;
> warn_alloc(gfp_mask, NULL,
> "vmalloc error: size %lu, vm_struct allocation failed%s",
> - real_size, (nofail) ? ". Retrying." : "");
> + size, (nofail) ? ". Retrying." : "");
> if (nofail) {
> schedule_timeout_uninterruptible(1);
> goto again;
> @@ -3861,7 +3859,7 @@ void *__vmalloc_node_range_noprof(unsigned long size, unsigned long align,
> (gfp_mask & __GFP_SKIP_ZERO))
> kasan_flags |= KASAN_VMALLOC_INIT;
> /* KASAN_VMALLOC_PROT_NORMAL already set if required. */
> - area->addr = kasan_unpoison_vmalloc(area->addr, real_size, kasan_flags);
> + area->addr = kasan_unpoison_vmalloc(area->addr, size, kasan_flags);
>
> /*
> * In this function, newly allocated vm_struct has VM_UNINITIALIZED
> @@ -3870,17 +3868,15 @@ void *__vmalloc_node_range_noprof(unsigned long size, unsigned long align,
> */
> clear_vm_uninitialized_flag(area);
>
> - size = PAGE_ALIGN(size);
> if (!(vm_flags & VM_DEFER_KMEMLEAK))
> - kmemleak_vmalloc(area, size, gfp_mask);
> + kmemleak_vmalloc(area, PAGE_ALIGN(size), gfp_mask);
>
> return area->addr;
>
> fail:
> if (shift > PAGE_SHIFT) {
> shift = PAGE_SHIFT;
> - align = real_align;
> - size = real_size;
> + align = original_align;
> goto again;
> }
>
> --
> 2.25.1
>
This one looks good to me:
Reviewed-by: "Uladzislau Rezki (Sony)" <urezki@gmail.com>
--
Uladzislau Rezki
prev parent reply other threads:[~2025-03-06 14:06 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-06 7:21 [PATCH] mm/vmalloc: Refactoring function __vmalloc_node_range_noprof Liu Ye
2025-03-06 14:06 ` Uladzislau Rezki [this message]
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=Z8mr12PilC00Wcvg@pc636 \
--to=urezki@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liuye@kylinos.cn \
/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.