From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id BF4DAC83F17 for ; Tue, 15 Jul 2025 23:19:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3D06D6B0089; Tue, 15 Jul 2025 19:19:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3A7F36B009E; Tue, 15 Jul 2025 19:19:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E4806B00A5; Tue, 15 Jul 2025 19:19:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 1E0D36B0089 for ; Tue, 15 Jul 2025 19:19:59 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B6B361401E5 for ; Tue, 15 Jul 2025 23:19:58 +0000 (UTC) X-FDA: 83668068876.12.AE1AC67 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) by imf06.hostedemail.com (Postfix) with ESMTP id 85E06180003 for ; Tue, 15 Jul 2025 23:19:55 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=huHBsNr6; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf06.hostedemail.com: domain of lkp@intel.com designates 192.198.163.15 as permitted sender) smtp.mailfrom=lkp@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752621596; a=rsa-sha256; cv=none; b=TdkpvW3+imN+gY/1kX+2Mz780s1HdBlXzkNpiJLZqqs1DaSUcZHmg+Nl40jC9PFIj4swGA Zb1iH0PL4KoumdcAXGQHhFXxsreWwFGbhU/WJijkfWWMbcZz49fPvsHtjpyzc6r9+v5cP8 qYwmGDMQj7G/zty6NnXqZY37FDnRa3Y= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=huHBsNr6; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf06.hostedemail.com: domain of lkp@intel.com designates 192.198.163.15 as permitted sender) smtp.mailfrom=lkp@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752621596; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8/1/RJRvkRb38dmC6RfkXVt2GTWLIPMYDuqnjH6AqmQ=; b=4r78jOEhsCoAyS7ztRutKqY8BtE77jknA++0qDMl8NjUW5usvVCcZN/K9PEYXOZCaJjAPk 84Er5DUiYSSC5mTy+oS7XsjKj6u22eqc+DeG51WgZOS1EAJ3ssli4uRc8ILkLSC7j2e2ee PbGRxB7i+EDwGSrLdiR3dBs7K332QSI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1752621596; x=1784157596; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=itnCC0VYx4q+7BX3ewA5kXh7ZnbQx/OqXw4zUuElz3g=; b=huHBsNr66Cj4WXEfNIk2kasnmLWf/XJNIbunjmxtcPp4OTGNO8nr3p3I 6Pr8fh8k4xs13Ipw/lfnHKwzQAXwAM7zBTr6gBotmmRunIebWPmf/GCgy cs+2AiLclFSwL15O1MjAAu/7+1uJ5Yxp0vEh1/HkrdyWOETKBCqy+J0/q qmZaF2SgpjdiwLJX/atUHjnIZrLYiH6rz9vJsSP1CV9xqHMsEIIHgnEx2 yqJ/4fXrRYCiN8Vfg0Ea/7GdIwkO+x42BCGZpnqqjEkt4VdYfnWMfHwap r7F6Qamk/o10J427iYq7JCrUlgkA1SeEh7Jtpp8Wv2H+2Prq2PpkIEwI0 A==; X-CSE-ConnectionGUID: uc5NwS7cSR2SeK6d7xIi2A== X-CSE-MsgGUID: DqX1gfPDS8eReLzxPAZU+A== X-IronPort-AV: E=McAfee;i="6800,10657,11493"; a="55006933" X-IronPort-AV: E=Sophos;i="6.16,314,1744095600"; d="scan'208";a="55006933" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jul 2025 16:19:54 -0700 X-CSE-ConnectionGUID: VujzdIHpTnu31G/E73VB1A== X-CSE-MsgGUID: pemlAhaUQjqCEiML7WxdCA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,314,1744095600"; d="scan'208";a="158070374" Received: from lkp-server01.sh.intel.com (HELO 9ee84586c615) ([10.239.97.150]) by fmviesa010.fm.intel.com with ESMTP; 15 Jul 2025 16:19:49 -0700 Received: from kbuild by 9ee84586c615 with local (Exim 4.96) (envelope-from ) id 1ubow7-000Bet-1H; Tue, 15 Jul 2025 23:19:47 +0000 Date: Wed, 16 Jul 2025 07:19:21 +0800 From: kernel test robot To: Hui Zhu , Andrew Morton , Uladzislau Rezki , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , bjorn3_gh@protonmail.com, Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Danilo Krummrich , Geliang Tang , Hui Zhu , 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 Subject: Re: [PATCH 1/3] vmalloc: Add vrealloc_align to support allocation of aligned vmap pages Message-ID: <202507160708.jArplInK-lkp@intel.com> References: <81647cce3b8e7139af47f20dbeba184b7a89b0cc.1752573305.git.zhuhui@kylinos.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <81647cce3b8e7139af47f20dbeba184b7a89b0cc.1752573305.git.zhuhui@kylinos.cn> X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 85E06180003 X-Stat-Signature: 9ga818sjw54nhpurqxpyjza96fwrseee X-Rspam-User: X-HE-Tag: 1752621595-818798 X-HE-Meta: U2FsdGVkX182fb/AHHW7+7wZFrkXO7BwGVZrSAstgJqpN7Fc/IBNYLC6LR2v7hrr9Ekp1V9T1QOiG5PWiPYxDp/VGunbc1fcVRWrQSNAc7DQyaQnVBHSaXeTSOJ7k4mfurmYUVl4Hf2CkOg3WpNhMXL9xylA+sC4pmFHnFTcTlzFUrAIP4zuVXNKIe2OU6BJ7F0RwkI6eZd4tXm2AA7dZlGgHpS1CjnbF8pfvWsLuhQ2njqoPMwkG+IlFC5lAlaM2yUBQMyFjBSUNX85aMrP5e8jyb8xCw+4zRVImY6VNSnNE8P/drAAORIdOE3jpFXk5V6ntBkFj+/MRajgdjwue0y5QFirUYXb7NugWss59KUXSJgnQNAoz3J17g18Aj75AEabwNSESorXw8sfx05R0Usuvh5BUylgzJ8bAKyqgS3GYML5mIILMvDmdEZzgH84dL5QiH0wB4y0fsDI4MmxNB53PyuIo06X1K7cjCaw1uii61dNNHh1vHmYDDf8H0p5dh+vxIqY4Cp95iqtV1S44rSQJWm7XIRNmMq+qmMR6+NSn+O0uMG6oNJgtGy2ZJj/1YIzwcQ52HMMt7indWOdwlRWCUtBQnz7GwjdTRwRiwqv0hfSnm2O0FB3pbQ3gVroGItWKQUYnqByx/v8foSkmwbwViD/78u/FJ21s2WFfGF8uctVvk06PQu59l3gq2FMFtp7L902kzrHmNKiZYsGoz3RNA9P7SEWj4M7TFlmIQ9Kvc73E63AJyoC236pIMxrlL05I4FwzIuJQnMsWsulzWDxGP+lNt5ATS8UBJzWXovkLAEW5nZ/x7h+md/7UGideXWuBFiGnLis58ldDN3g2SassWlm0eefjvkubxk7JgrugcT76jrFC6gAjYrsHLPjSj+ApK5nS8MUKD3pkcOQ2dcv1k9QdXneEUk2opQPb0+K8UFdDVt5sSZe0GioQdpJ+H3Kr+tOkWn7a3rs7Rs i2K82mXU 5Ete5y/5vUvzXDyGv8sgrMDEbMX7+cqu9e92I3l+8CR5WMGRiTqay5QUk7uAd5osKXifi60UdhjYe2Jq/rPwx23HYTA1bgeAKefcXz4Fbc+NR/2SHHQofIWRYacNQNeHmt8E/0TgPruUovEtnAFIcP3d859bO+xBMfDpNNddCqDF/xOAp6THBOusRTRiD2wjmvHpWiX8vZoXzi2+Y8sFeu4DRT5vCwoEzfOLf/E8H5o+Dp/bz7XndJ0aaA0m3w430D1pFrUTTUN8AEGluDpM/yp4AIyvddlh/xblMLidHOac4hpfa8EMB2JMl/1+HTTDKvYRohZ+Hc1I6QjdFyUcvH+LdJBUiYNJDenfe/iKjasqD147sCNf9Y1XcRYi2X/PrRYe1TGAKxCitfkqBW0UJhWu/LJa11R22E1bQjQkjIZOxZngyC+m4YhFtn+esjboySi16SCgV092uO7pEsKb8+pfsnA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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 | 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