From: kernel test robot <lkp@intel.com>
To: Hui Zhu <hui.zhu@linux.dev>,
Andrew Morton <akpm@linux-foundation.org>,
Uladzislau Rezki <urezki@gmail.com>,
Miguel Ojeda <ojeda@kernel.org>,
Alex Gaynor <alex.gaynor@gmail.com>,
Boqun Feng <boqun.feng@gmail.com>, Gary Guo <gary@garyguo.net>,
bjorn3_gh@protonmail.com, Benno Lossin <lossin@kernel.org>,
Andreas Hindborg <a.hindborg@kernel.org>,
Alice Ryhl <aliceryhl@google.com>,
Trevor Gross <tmgross@umich.edu>,
Danilo Krummrich <dakr@kernel.org>,
Geliang Tang <geliang@kernel.org>, Hui Zhu <zhuhui@kylinos.cn>,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [PATCH 1/3] vmalloc: Add vrealloc_align to support allocation of aligned vmap pages
Date: Wed, 16 Jul 2025 07:19:21 +0800 [thread overview]
Message-ID: <202507160708.jArplInK-lkp@intel.com> (raw)
In-Reply-To: <81647cce3b8e7139af47f20dbeba184b7a89b0cc.1752573305.git.zhuhui@kylinos.cn>
Hi Hui,
kernel test robot noticed the following build warnings:
[auto build test WARNING on rust/rust-next]
[also build test WARNING on akpm-mm/mm-everything rust/alloc-next linus/master v6.16-rc6 next-20250715]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Hui-Zhu/vmalloc-Add-vrealloc_align-to-support-allocation-of-aligned-vmap-pages/20250715-180136
base: https://github.com/Rust-for-Linux/linux rust-next
patch link: https://lore.kernel.org/r/81647cce3b8e7139af47f20dbeba184b7a89b0cc.1752573305.git.zhuhui%40kylinos.cn
patch subject: [PATCH 1/3] vmalloc: Add vrealloc_align to support allocation of aligned vmap pages
config: i386-buildonly-randconfig-002-20250716 (https://download.01.org/0day-ci/archive/20250716/202507160708.jArplInK-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250716/202507160708.jArplInK-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202507160708.jArplInK-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> mm/vmalloc.c:4124:9: warning: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
4123 | WARN(1, "Trying to vrealloc_align() align is not power of 2 (%ld)\n",
| ~~~
| %zu
4124 | align);
| ^~~~~
include/asm-generic/bug.h:134:29: note: expanded from macro 'WARN'
134 | __WARN_printf(TAINT_WARN, format); \
| ^~~~~~
include/asm-generic/bug.h:106:17: note: expanded from macro '__WARN_printf'
106 | __warn_printk(arg); \
| ^~~
mm/vmalloc.c:1987:20: warning: unused function 'setup_vmalloc_vm' [-Wunused-function]
1987 | static inline void setup_vmalloc_vm(struct vm_struct *vm,
| ^~~~~~~~~~~~~~~~
2 warnings generated.
vim +4124 mm/vmalloc.c
4082
4083 /**
4084 * vrealloc_align - reallocate virtually contiguous memory;
4085 * contents remain unchanged
4086 * @p: object to reallocate memory for
4087 * @size: the size to reallocate
4088 * @align: requested alignment
4089 * @flags: the flags for the page level allocator
4090 *
4091 * If @p is %NULL, vrealloc() behaves exactly like vmalloc(). If @size is 0 and
4092 * @p is not a %NULL pointer, the object pointed to is freed.
4093 *
4094 * If __GFP_ZERO logic is requested, callers must ensure that, starting with the
4095 * initial memory allocation, every subsequent call to this API for the same
4096 * memory allocation is flagged with __GFP_ZERO. Otherwise, it is possible that
4097 * __GFP_ZERO is not fully honored by this API.
4098 *
4099 * In any case, the contents of the object pointed to are preserved up to the
4100 * lesser of the new and old sizes.
4101 *
4102 * This function must not be called concurrently with itself or vfree() for the
4103 * same memory allocation.
4104 *
4105 * Return: pointer to the allocated memory; %NULL if @size is zero or in case of
4106 * failure
4107 */
4108 void *vrealloc_align_noprof(const void *p, size_t size, size_t align,
4109 gfp_t flags)
4110 {
4111 struct vm_struct *vm = NULL;
4112 size_t alloced_size = 0;
4113 size_t old_size = 0;
4114 void *n;
4115
4116 if (!size) {
4117 vfree(p);
4118 return NULL;
4119 }
4120
4121 if (p) {
4122 if (!is_power_of_2(align)) {
4123 WARN(1, "Trying to vrealloc_align() align is not power of 2 (%ld)\n",
> 4124 align);
4125 return NULL;
4126 }
4127
4128 vm = find_vm_area(p);
4129 if (unlikely(!vm)) {
4130 WARN(1, "Trying to vrealloc_align() nonexistent vm area (%p)\n", p);
4131 return NULL;
4132 }
4133
4134 alloced_size = get_vm_area_size(vm);
4135 old_size = vm->requested_size;
4136 if (WARN(alloced_size < old_size,
4137 "vrealloc_align() has mismatched area vs requested sizes (%p)\n", p))
4138 return NULL;
4139 }
4140
4141 if (IS_ALIGNED((unsigned long)p, align)) {
4142 /*
4143 * TODO: Shrink the vm_area, i.e. unmap and free unused pages. What
4144 * would be a good heuristic for when to shrink the vm_area?
4145 */
4146 if (size <= old_size) {
4147 /* Zero out "freed" memory, potentially for future realloc. */
4148 if (want_init_on_free() || want_init_on_alloc(flags))
4149 memset((void *)p + size, 0, old_size - size);
4150 vm->requested_size = size;
4151 kasan_poison_vmalloc(p + size, old_size - size);
4152 return (void *)p;
4153 }
4154
4155 /*
4156 * We already have the bytes available in the allocation; use them.
4157 */
4158 if (size <= alloced_size) {
4159 kasan_unpoison_vmalloc(p + old_size, size - old_size,
4160 KASAN_VMALLOC_PROT_NORMAL);
4161 /*
4162 * No need to zero memory here, as unused memory will have
4163 * already been zeroed at initial allocation time or during
4164 * realloc shrink time.
4165 */
4166 vm->requested_size = size;
4167 return (void *)p;
4168 }
4169 } else {
4170 /*
4171 * p is not aligned with align.
4172 * Allocate a new address to handle it.
4173 */
4174 if (size < old_size)
4175 old_size = size;
4176 }
4177
4178 /* TODO: Grow the vm_area, i.e. allocate and map additional pages. */
4179 n = __vmalloc_node_noprof(size, align, flags, NUMA_NO_NODE,
4180 __builtin_return_address(0));
4181 if (!n)
4182 return NULL;
4183
4184 if (p) {
4185 memcpy(n, p, old_size);
4186 vfree(p);
4187 }
4188
4189 return n;
4190 }
4191
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next prev parent reply other threads:[~2025-07-15 23:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-15 9:59 [PATCH 0/3] rust: allocator: Vmalloc: Support alignments larger than PAGE_SIZE Hui Zhu
2025-07-15 9:59 ` [PATCH 1/3] vmalloc: Add vrealloc_align to support allocation of aligned vmap pages Hui Zhu
2025-07-15 23:19 ` kernel test robot [this message]
2025-07-16 7:02 ` Uladzislau Rezki
2025-07-15 9:59 ` [PATCH 2/3] rust: allocator: Vmalloc: Support alignments larger than PAGE_SIZE Hui Zhu
2025-07-15 9:59 ` [PATCH 3/3] rust: add a sample allocator usage Hui Zhu
2025-07-15 10:37 ` Danilo Krummrich
2025-07-17 10:02 ` Your Name
2025-07-15 10:21 ` [PATCH 0/3] rust: allocator: Vmalloc: Support alignments larger than PAGE_SIZE Danilo Krummrich
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=202507160708.jArplInK-lkp@intel.com \
--to=lkp@intel.com \
--cc=a.hindborg@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=geliang@kernel.org \
--cc=hui.zhu@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=llvm@lists.linux.dev \
--cc=lossin@kernel.org \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
--cc=urezki@gmail.com \
--cc=zhuhui@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.