From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 714C21840 for ; Wed, 25 Oct 2023 04:54:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="h6m80GBX" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1698209697; x=1729745697; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=oCQNN4BAYh1dgi4fhqGeDaJQ9pP3TeTIi6MWMt4r8uA=; b=h6m80GBXvFtjtIg2GYiB1Un2aH8MM232+JA+55Hy6363ekcAAeYOra/s QiBciTol/Ft7MForYUAAZqxzKLuQ4WCdc0VvGJ95lyYs4d0mIRnpTUepN iZPVwvuKQvx1Px7k7Fm+Ie+RfGelPdSVZCHQigqWgQMQxMx2YWN04gTjm y6aGDUDbP2N6Lck28sScK0J6vbSWyC8o/YDmgY0uZWdQGuN8p789ZXG4d 4xpC9l9wcMr7W6VkAJl7kaSqd3u9MWkOk4WateU6hWxNeC9qEo7214Rzm qu7rZM8Kmt9JiMBtheDMquTgS+3QQEv5PDsbToMyDJ6okQHL+sD7Maz6f g==; X-IronPort-AV: E=McAfee;i="6600,9927,10873"; a="366583494" X-IronPort-AV: E=Sophos;i="6.03,249,1694761200"; d="scan'208";a="366583494" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Oct 2023 21:54:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10873"; a="793745673" X-IronPort-AV: E=Sophos;i="6.03,249,1694761200"; d="scan'208";a="793745673" Received: from lkp-server01.sh.intel.com (HELO 8917679a5d3e) ([10.239.97.150]) by orsmga001.jf.intel.com with ESMTP; 24 Oct 2023 21:54:48 -0700 Received: from kbuild by 8917679a5d3e with local (Exim 4.96) (envelope-from ) id 1qvVuo-0008d1-1n; Wed, 25 Oct 2023 04:54:46 +0000 Date: Wed, 25 Oct 2023 12:54:26 +0800 From: kernel test robot To: Suren Baghdasaryan , akpm@linux-foundation.org Cc: oe-kbuild-all@lists.linux.dev, kent.overstreet@linux.dev, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, roman.gushchin@linux.dev, mgorman@suse.de, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, corbet@lwn.net, void@manifault.com, juri.lelli@redhat.com, ldufour@linux.ibm.com, catalin.marinas@arm.com, will@kernel.org, arnd@arndb.de, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, x86@kernel.org, peterx@redhat.com, david@redhat.com, axboe@kernel.dk, mcgrof@kernel.org, masahiroy@kernel.org, nathan@kernel.org, dennis@kernel.org, tj@kernel.org Subject: Re: [PATCH v2 07/39] mm: introduce slabobj_ext to support slab object extensions Message-ID: <202310251250.7eIjGAy6-lkp@intel.com> References: <20231024134637.3120277-8-surenb@google.com> Precedence: bulk X-Mailing-List: oe-kbuild-all@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231024134637.3120277-8-surenb@google.com> Hi Suren, kernel test robot noticed the following build warnings: [auto build test WARNING on vbabka-slab/for-next] [also build test WARNING on kees/for-next/hardening linus/master v6.6-rc7] [cannot apply to akpm-mm/mm-everything next-20231024] [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/Suren-Baghdasaryan/lib-string_helpers-Add-flags-param-to-string_get_size/20231024-215116 base: git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab.git for-next patch link: https://lore.kernel.org/r/20231024134637.3120277-8-surenb%40google.com patch subject: [PATCH v2 07/39] mm: introduce slabobj_ext to support slab object extensions config: loongarch-allyesconfig (https://download.01.org/0day-ci/archive/20231025/202310251250.7eIjGAy6-lkp@intel.com/config) compiler: loongarch64-linux-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231025/202310251250.7eIjGAy6-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/202310251250.7eIjGAy6-lkp@intel.com/ All warnings (new ones prefixed by >>): In file included from mm/kfence/kfence.h:17, from mm/kfence/core.c:36: mm/kfence/../slab.h: In function 'slab_post_alloc_hook': >> mm/kfence/../slab.h:778:29: warning: variable 'obj_exts' set but not used [-Wunused-but-set-variable] 778 | struct slabobj_ext *obj_exts; | ^~~~~~~~ vim +/obj_exts +778 mm/kfence/../slab.h 771 772 static inline void slab_post_alloc_hook(struct kmem_cache *s, 773 struct obj_cgroup *objcg, gfp_t flags, 774 size_t size, void **p, bool init, 775 unsigned int orig_size) 776 { 777 unsigned int zero_size = s->object_size; > 778 struct slabobj_ext *obj_exts; 779 bool kasan_init = init; 780 size_t i; 781 782 flags &= gfp_allowed_mask; 783 784 /* 785 * For kmalloc object, the allocated memory size(object_size) is likely 786 * larger than the requested size(orig_size). If redzone check is 787 * enabled for the extra space, don't zero it, as it will be redzoned 788 * soon. The redzone operation for this extra space could be seen as a 789 * replacement of current poisoning under certain debug option, and 790 * won't break other sanity checks. 791 */ 792 if (kmem_cache_debug_flags(s, SLAB_STORE_USER | SLAB_RED_ZONE) && 793 (s->flags & SLAB_KMALLOC)) 794 zero_size = orig_size; 795 796 /* 797 * When slub_debug is enabled, avoid memory initialization integrated 798 * into KASAN and instead zero out the memory via the memset below with 799 * the proper size. Otherwise, KASAN might overwrite SLUB redzones and 800 * cause false-positive reports. This does not lead to a performance 801 * penalty on production builds, as slub_debug is not intended to be 802 * enabled there. 803 */ 804 if (__slub_debug_enabled()) 805 kasan_init = false; 806 807 /* 808 * As memory initialization might be integrated into KASAN, 809 * kasan_slab_alloc and initialization memset must be 810 * kept together to avoid discrepancies in behavior. 811 * 812 * As p[i] might get tagged, memset and kmemleak hook come after KASAN. 813 */ 814 for (i = 0; i < size; i++) { 815 p[i] = kasan_slab_alloc(s, p[i], flags, kasan_init); 816 if (p[i] && init && (!kasan_init || !kasan_has_integrated_init())) 817 memset(p[i], 0, zero_size); 818 kmemleak_alloc_recursive(p[i], s->object_size, 1, 819 s->flags, flags); 820 kmsan_slab_alloc(s, p[i], flags); 821 obj_exts = prepare_slab_obj_exts_hook(s, flags, p[i]); 822 } 823 824 memcg_slab_post_alloc_hook(s, objcg, flags, size, p); 825 } 826 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki