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 1A857C7115B for ; Fri, 20 Jun 2025 15:45:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B40596B0088; Fri, 20 Jun 2025 11:45:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AD9286B0089; Fri, 20 Jun 2025 11:45:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C7FA6B008A; Fri, 20 Jun 2025 11:45:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 881BB6B0088 for ; Fri, 20 Jun 2025 11:45:45 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2A38D120F77 for ; Fri, 20 Jun 2025 15:45:45 +0000 (UTC) X-FDA: 83576204250.30.66C1020 Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by imf26.hostedemail.com (Postfix) with ESMTP id 29DBC140014 for ; Fri, 20 Jun 2025 15:45:42 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EvIOkFCd; spf=pass (imf26.hostedemail.com: domain of klarasmodin@gmail.com designates 209.85.167.41 as permitted sender) smtp.mailfrom=klarasmodin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750434343; 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=j4gHMbfrP62AyybD3k1CrUQ7A0/RCXBAPC12kLOvMpU=; b=VSbWfjJyAjdp87vgn6yBAyRjrg1qZ41N7d57tZ5//KaRMuCpAePDIPDfEjLBfazWAwIwu1 yW87DOnZ25CP4aB0KSYu0qF7EFZsFp5aIWaohKOJ9+n6BKwKQo3P56Try3fm7GaSglYb5w WKbK7aY6Gn5osBcValwXbTB38GiqmFA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750434343; a=rsa-sha256; cv=none; b=0bUjV/DO9GAzCi/Sg3lzHvqlpRbRxWUWBKWYAFXrih4oDOy6feAXHIHlYZhdq4ssUGrt6P h22MD9OGxc1ge16+RozzRKxVQRUN6D/PA9QCaMb54OApZ82+o3OsERHj0IDWMEDH3ANEa0 m0vhiZb+3/bzIh94SApSAQF4N06yUqM= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EvIOkFCd; spf=pass (imf26.hostedemail.com: domain of klarasmodin@gmail.com designates 209.85.167.41 as permitted sender) smtp.mailfrom=klarasmodin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-553b5165cf5so2473796e87.0 for ; Fri, 20 Jun 2025 08:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750434341; x=1751039141; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=j4gHMbfrP62AyybD3k1CrUQ7A0/RCXBAPC12kLOvMpU=; b=EvIOkFCdBG3ujjaGGuWGQirN1qHMvnO3cFIWLUFFDvAf6FIbTJuAxa5utC9zL6IUZF afE6c2eehE2DTvdi3vl25U04vKJj4gOwtdbZYn30hsLfeYPVKR1ZfVUTCiT4kpm9xt0t NnXBtu7BhQrNN+1q67siFwWK2iy4upVB2lNuIC/LTTEQtPmO3hwE1892esV/CSAPISsZ iDYNb9okzujuwJx/kuZCvjzCrKbVoos+JkpvVTLzJokXhXtAsD3PlrptPQUPnyV+a6zN zao81EqxT+RNQZ+qryHWPfUTnIZ/RrhCCBOhIFX6gZ03BlNFMBde2Roh+C7Ja5LLl8VE tgfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750434341; x=1751039141; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=j4gHMbfrP62AyybD3k1CrUQ7A0/RCXBAPC12kLOvMpU=; b=BTb2x9DGDzDHrKbrXq+41PJREBRXGN6ZuR3us3BPwM7ZWXIJj8AhBNk3TWNsFNhfNe f0BE26SM94Jb3X1986oLIG+tNFQBcgjWx9hpFbPVrvd+dQlRBnG09W5G89fzHDKXUS5X /e0cLXZ+GaQOLijWyhWPWClKCMUUtnBjIOFxcXNkjODDTThuuIV+MKTUPISjRQWiOAWO pk3edMc4dt4652M4Nj5BXCeywEVh82dXKIZuI4JEI5s5jSfR6O33kR1h2kCjsDXHPDKv Hcm0C8Y/OvBQ2sB1lQ3lO0Wg2EII8hhJfJDbFrKWj6fL5s273sxYccOJ/7VstlQKIwME tlvw== X-Forwarded-Encrypted: i=1; AJvYcCV1zKvQ/rOF4+sRypxSzmdGsDIcIAoQth2bd5k1WfUFEUJD/Wn4jIphdvB7QaHOWXUyTliQBNAZVw==@kvack.org X-Gm-Message-State: AOJu0Yz6tonR85e7h8hdJLNy6n3eEdxYUh2+KNf38r/5fFpMY6BWAWXb 5VNhmz3pydVkz0LaEmRJXpNSpS8Ue5DSp//405cvh355Bw5GVtL65UeM X-Gm-Gg: ASbGncsnjdxWufE7NWVso6J81wN3e26GShEdIvZoe3RUNHOIlzHRlifw+zWukYnNrgm 5Z7pjVZVqY+kExfhQzTiREentlgZSsv7FpEo0Et9UpCf3Q/VyDahvHdhw0UKrpvLrERg2R+OW4N VAYJiIbHPH43fDfnB5BS9kH0ToPKWjifN7lvfmS20KfLZb1sFfqF3uY4ZzWqDpF5mk5V2Erwmpn fZmtI/557zC/UK44YqGfymUuCvZTCuVih9JDYzLSajnvanhxSB+FaGF964saCdQlDzcl3MFsgjU 860SVn+1rIuVRrCQ6RxKW39rRSdbPcyKLxlKwuJpVDa1U4e5iD1D7Yz9h74p9HWiqu38a71k2Fs p5w== X-Google-Smtp-Source: AGHT+IHie5DgDR9fAEvkFZRLnTQygV7sMClPhEOHfnmOPQG3XhthUwEw/pgKPY8+lQ5Ma1A4lzeVSg== X-Received: by 2002:a05:6512:3e17:b0:550:e608:410b with SMTP id 2adb3069b0e04-553e3bfe5dcmr1300695e87.33.1750434340878; Fri, 20 Jun 2025 08:45:40 -0700 (PDT) Received: from localhost (soda.int.kasm.eu. [2001:678:a5c:1202:4fb5:f16a:579c:6dcb]) by smtp.gmail.com with UTF8SMTPSA id 2adb3069b0e04-553e41cc3bdsm321721e87.216.2025.06.20.08.45.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Jun 2025 08:45:40 -0700 (PDT) Date: Fri, 20 Jun 2025 17:45:39 +0200 From: Klara Modin To: Hao Ge Cc: Catalin Marinas , Suren Baghdasaryan , Kent Overstreet , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Hao Ge Subject: Re: [PATCH] mm/alloc_tag: Fix the kmemleak false positive issue in the allocation of the percpu variable tag->counters Message-ID: References: <20250619183154.2122608-1-hao.ge@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250619183154.2122608-1-hao.ge@linux.dev> X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 29DBC140014 X-Stat-Signature: 76tuthkek37f5hxe6u6p6rs8b9g476nr X-Rspam-User: X-HE-Tag: 1750434342-657770 X-HE-Meta: U2FsdGVkX1/cw0wCf34z4HiMktFnzO/c7XLHtvMtGmRzMjhwOtB9/349ir6TTzlZjstvZ9h8lMFUwAxKtiiOFGG9wk/yHhz/WLkfjKV7ewXlK4y52tdEfE/VWIzMd0VSpPnRJhQL0J/TviJfzoaBmGYW6cWcM5HCOVUY7NBK8JsMBOJMkEA7VQ7tcRGsx1MX1UtMnIP4x50UDuh0lDO/WGDw1Adad50wXoeV8FDBGeDilki8SyiZaYWxSm2KeXZDWMNMcYq8Tv95/U7U+kfpBIqiodCURUUrrY99VQOZTGBHleVPPmyY51Xt3U6+79YFRzrA3LlbHXAOlCnWHUBLrmRcaJJH3UMs/pRQcZOY1uS5iaVhtnaf6Rk5tMj/eeGslptKn9ab/LgF5z2p5xp7gSJjbctM0MxOXT2I1ZCmLDN2PaJKG8PaKZSl08ukK8PKCwjwHk/+zRhVoXvVLzYQbnkrNoAXCn2ppNz1WiJNnUfMR+g3i9epTEBO0uu6yYJKLXY2cp9/7IcyYIhSEkgEjqQiv6w8idnl2hCD3NpZr8ioJvlU83s8TN58xyx4sARFU8KCPKoJEIXMEaZu8/X2s/6BAejyWKhwgMG8WmO0VN7uzZBJLlOJxpn/knDftTiwTJKwAW/y4Y6DfyJYSrdbocZDLeCcxwUjRXOl8ja587ecygPGBm7xKCgKPN+jtk0I1ITa4HWoEmah2nhv1XJvQ+X00P/YqYG8eOCjWMSYxa+QAg+0akodA8d2nlIcmx6Ct/OGTf58lsjdWknIU1MB5A2tdeHOEFSIxYKCQ+nWNximiRgKmkcD/jFk13smPyxTkOuioHktjvMl0Ptu/aIq1FmmajcZAPv5EJ+VM0oJVbG/nKB5YJvJn4Oieo0BeJCoR91TgGkjEcDoEK5VogxrsnGSbsoTkeG0nu/mU47SE060WsdzRaZ6YJlQhXo+ZbK234Koui2KsaB9fH9VwK3 WAAq2CSA znzAO1WqZQ5sSLER3gFYAoYPtmQjffryamjKLjJrJ1JhWmaBsXhBPe+PUX0HvnWCP/BFCgzJ1D5V4cemFVk0rYBZ45c1a6NWD16OqLjYOYUgUDPy0X5Cjas3WMK9cApzeKeDryxN0axz74sati1RM0xITKv6zKTw70o33HGQxcJHNHMN18kpNHyfRmNoHMwmiMRy26aEJQHkZ52jb6BM42cAeHEuQ6E258kaVppqVE/FD8PgzosreBevQOheBxdFaYEDvde9XDN7/Zni1xAb/qzPsH0TqYutM3lwsu1u6Tx3l0Cucj5wJU0xzMa9RTzXhkVYd95enMCCvpe2pGFAkKw89kks8gkx5kJCunACWoKO3RDZf6oElIJOQjd/loq/MvADB8rcAXEhWLzV6xgBieb9ZR3CrlxB+ZpkSV7gQCYizJoBMCO9PZkrcKHfqMyH03sgQkrXMQD9hV5SNKxEE/Ge5VYWUKmPJ7SNfOMnr+BjhvAs+4AoqFKvSW92zj3Ing0K3NoAlGKQdehEssYwokAKe+KhVIRn+vSBPl8C9P89q5iO0PYXMvZEbmzUcB96zXf/M 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, On 2025-06-20 02:31:54 +0800, Hao Ge wrote: > From: Hao Ge > > When loading a module, as long as the module has memory > allocation operations, kmemleak produces a false positive > report that resembles the following: > > unreferenced object (percpu) 0x7dfd232a1650 (size 16): > comm "modprobe", pid 1301, jiffies 4294940249 > hex dump (first 16 bytes on cpu 2): > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > backtrace (crc 0): > kmemleak_alloc_percpu+0xb4/0xd0 > pcpu_alloc_noprof+0x700/0x1098 > load_module+0xd4/0x348 > codetag_module_init+0x20c/0x450 > codetag_load_module+0x70/0xb8 > load_module+0xef8/0x1608 > init_module_from_file+0xec/0x158 > idempotent_init_module+0x354/0x608 > __arm64_sys_finit_module+0xbc/0x150 > invoke_syscall+0xd4/0x258 > el0_svc_common.constprop.0+0xb4/0x240 > do_el0_svc+0x48/0x68 > el0_svc+0x40/0xf8 > el0t_64_sync_handler+0x10c/0x138 > el0t_64_sync+0x1ac/0x1b0 > > This is because the module can only indirectly reference alloc_tag_counters > through the alloc_tag section, which misleads kmemleak. > > However, we don't have a kmemleak ignore interface for percpu > allocations yet. So let's create one and invoke it for tag->counters. > > Fixes: 12ca42c23775 ("alloc_tag: allocate percpu counters for module tags dynamically") > Signed-off-by: Hao Ge > --- > include/linux/kmemleak.h | 1 + > lib/alloc_tag.c | 8 +++++++- > mm/kmemleak.c | 14 ++++++++++++++ > 3 files changed, 22 insertions(+), 1 deletion(-) > > diff --git a/include/linux/kmemleak.h b/include/linux/kmemleak.h > index 93a73c076d16..2ea8e66bf689 100644 > --- a/include/linux/kmemleak.h > +++ b/include/linux/kmemleak.h > @@ -28,6 +28,7 @@ extern void kmemleak_update_trace(const void *ptr) __ref; > extern void kmemleak_not_leak(const void *ptr) __ref; > extern void kmemleak_transient_leak(const void *ptr) __ref; > extern void kmemleak_ignore(const void *ptr) __ref; > +extern void kmemleak_igonore_percpu(const void __percpu *ptr) __ref; Note that there's no stub defined in the #else block, which means this will fail to build if CONFIG_DEBUG_KMEMLEAK is disabled. > extern void kmemleak_scan_area(const void *ptr, size_t size, gfp_t gfp) __ref; > extern void kmemleak_no_scan(const void *ptr) __ref; > extern void kmemleak_alloc_phys(phys_addr_t phys, size_t size, > diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c > index d48b80f3f007..de6dcf4ea0f5 100644 > --- a/lib/alloc_tag.c > +++ b/lib/alloc_tag.c > @@ -10,6 +10,7 @@ > #include > #include > #include > +#include > > #define ALLOCINFO_FILE_NAME "allocinfo" > #define MODULE_ALLOC_TAG_VMAP_SIZE (100000UL * sizeof(struct alloc_tag)) > @@ -632,8 +633,13 @@ static int load_module(struct module *mod, struct codetag *start, struct codetag > mod->name); > return -ENOMEM; > } > - } > > + /* > + * Avoid a kmemleak false positive. The pointer to the counters is stored > + * in the alloc_tag section of the module and cannot be directly accessed. > + */ > + kmemleak_igonore_percpu(tag->counters); > + } > return 0; > } > > diff --git a/mm/kmemleak.c b/mm/kmemleak.c > index da9cee34ee1b..8797fe88861e 100644 > --- a/mm/kmemleak.c > +++ b/mm/kmemleak.c > @@ -1246,6 +1246,20 @@ void __ref kmemleak_transient_leak(const void *ptr) > } > EXPORT_SYMBOL(kmemleak_transient_leak); > > +/** > + * kmemleak_ignore_phys - similar to kmemleak_ignore but taking a percpu This should match with the function below. > + * address argument > + * @ptr: percpu address of the object > + */ > +void __ref kmemleak_igonore_percpu(const void __percpu *ptr) > +{ > + pr_debug("%s(0x%px)\n", __func__, ptr); > + > + if (kmemleak_enabled && ptr && !IS_ERR_PCPU(ptr)) > + make_black_object((unsigned long)ptr, OBJECT_PERCPU); > +} > +EXPORT_SYMBOL_GPL(kmemleak_igonore_percpu); > + > /** > * kmemleak_ignore - ignore an allocated object > * @ptr: pointer to beginning of the object > -- > 2.25.1 > s/igonore/ignore/ The commit summary should probably also be shortened, it is recommended to be at most 70-75 characters[1]. Perhaps something like mm/alloc_tag: Fix kmemleak false positive in percpu tag->counters could be appropriate? Regards, Klara Modin Link: https://www.kernel.org/doc/html/latest/process/submitting-patches.html [1]