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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).