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 409E8C7115D for ; Fri, 20 Jun 2025 10:03:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 941126B007B; Fri, 20 Jun 2025 06:03:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9184B6B0089; Fri, 20 Jun 2025 06:03:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8554D6B0092; Fri, 20 Jun 2025 06:03:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 7A5F36B007B for ; Fri, 20 Jun 2025 06:03:38 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 1A4EC1D40B7 for ; Fri, 20 Jun 2025 10:03:38 +0000 (UTC) X-FDA: 83575342116.09.BB6C14A Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.2]) by imf02.hostedemail.com (Postfix) with ESMTP id 84C438000B for ; Fri, 20 Jun 2025 10:03:35 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=163.com header.s=s110527 header.b=CgLswvgZ; spf=pass (imf02.hostedemail.com: domain of 00107082@163.com designates 117.135.210.2 as permitted sender) smtp.mailfrom=00107082@163.com; dmarc=pass (policy=none) header.from=163.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750413816; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=609TVC0hOBK6dMhgn8tSTcczNdyVWJ/RBOSw15FKE+Y=; b=yX8wyZd+kXHUmzcTFlls8tgoutRK8Zm6ksD+LV84RL7xpQmtuowRPurcxyaoL8I1LbcnlE zfLA7qjXpfQdoO/XgKiBou3GZ0OvZePXNHptYICA6uxH4S0s91kXZPizZpg1bdpX3enEVh vEXZb9rmB3Ihi/fXy0IZPf1AHhTRklg= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=163.com header.s=s110527 header.b=CgLswvgZ; spf=pass (imf02.hostedemail.com: domain of 00107082@163.com designates 117.135.210.2 as permitted sender) smtp.mailfrom=00107082@163.com; dmarc=pass (policy=none) header.from=163.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750413816; a=rsa-sha256; cv=none; b=q/JWxD428GzY9d1MNmDA0k5lABR8xC9MVWKqCK0QjH07vEOGWIpRqcfB+MlsUhbRlYOiLd 84uAKQA8pUasR8LXHUePyWPO2XO17VIcLWiCc9TlXgSJzDVEbWgS6ODg6C/8s2ohQC77Fg tjGMln+iF+WRUWgDgwwsOr6sFjL5Mjo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=60 9TVC0hOBK6dMhgn8tSTcczNdyVWJ/RBOSw15FKE+Y=; b=CgLswvgZJ9CPhVq7O1 ElIxKBwU3TuS9durqa2XM5A6FByXdn/DWNUajWRb5sn2DWChXTzzJ5OsqrrDIlVX kLU6MUwW2vViF3rut3GRnP0vl+HIvnMYbAHXRD77VxYsXKESGAXMuFqHQ4mmaLMK TEIGzxq1ZAinf0DWWklxfhZr8= Received: from localhost.localdomain (unknown []) by gzsmtp1 (Coremail) with SMTP id PCgvCgCXf77TMVVoqyBpAQ--.37413S4; Fri, 20 Jun 2025 18:03:14 +0800 (CST) From: David Wang <00107082@163.com> To: oliver.sang@intel.com, urezki@gmail.com Cc: ahuang12@lenovo.com, akpm@linux-foundation.org, bhe@redhat.com, hch@infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, lkp@intel.com, mjguzik@gmail.com, oe-lkp@lists.linux.dev, harry.yoo@oracle.com, kent.overstreet@linux.dev, surenb@google.com Subject: CONFIG_TEST_VMALLOC=y conflict/race with alloc_tag_init Date: Fri, 20 Jun 2025 18:02:58 +0800 Message-Id: <20250620100258.595495-1-00107082@163.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <202506181351.bba867dd-lkp@intel.com> References: <202506181351.bba867dd-lkp@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:PCgvCgCXf77TMVVoqyBpAQ--.37413S4 X-Coremail-Antispam: 1Uf129KBjvJXoWxGrWUWFWUZw47uF17Zr43KFg_yoW5KFWUpa yfXry7Ca95J3yxCrW7K34v9ryFqw4DGw1UJF42vayF9rnIkr4UCr1DKryIqFyUXFWYya9Y qFs7tF4vkr1UZaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07U6HqxUUUUU= X-Originating-IP: [111.35.191.131] X-CM-SenderInfo: qqqrilqqysqiywtou0bp/xtbBkBpyqmhVMBM2swAAsJ X-Rspamd-Server: rspam11 X-Rspam-User: X-Rspamd-Queue-Id: 84C438000B X-Stat-Signature: 91zg8egjsor8i7uuiqc3kmtgfhwn7siz X-HE-Tag: 1750413815-174460 X-HE-Meta: U2FsdGVkX1/cM/ULUoKtxXgdNKYkBmy4JZQkoW8rjwAYwIxBUeCWQDyy2TRFB3vba1vYBzOqPSteKX5OM/0WZyxn7MkjxbtzdWlukrZNszKHjEh0EMLka4SS3CFKB9ZSvf02MEZ9/LimgpYVxYOa64XHUuHpn4hYWOeCaFjHSFTsSJ9zAyhbkOXv2sLrNMwNzBNQQ0LdZHB0Ada0v3pME64v9m656K4y56f7V3Ze5KKmGkxB+UIGjPzR2IkIP8WTt8mSkCCFnzsFtJ34i1enxPb4jOYdIg4I8Nb9LyAfPw0a+k1HUKcx3yzNQacS19weL9aye2zd9RYHxGXba9rcDiOab13abCJEBNBxMmuMJSuCJ5xMYthjsYs3rX59BP+/dBW4bNyguBnGCGwBLDHH5MYnVpb+fkGySQANYX1bJaB8TjPvHOTmWvS8WgQxKPVhuDNCva8Q59K/vJkFwRQ0bNOM2Udas2O9HtWV6unmxZfTGqL8Lx3bD+E6C3LwgEy7DAhkz7NeZPp1U500kH6BzQ9gyKtB3A2atnWCwvmlXJxEykQzgeUuRiPnWG7Un6DKv/pojlALoj26hBfit3zI4T9XC/aTj4PB3lYUwn5dSF24yFyHsdp3QiTWyCeyvNmPlxcY+pXCxU7LUEoua8dyMkhtlhrxI9eZatYCrU0vfzbIhIAtXY7IfvvJ5yI0R5to4BmHnWLYmVm4H2xcYEGOCMc9iIyq3NbDaDYpPjTusZX08bLTE5GYK3Q++6fIDXdPfY+sCVoXGDyCaJt6D/uIxFyULG/QUya+3r3pu8/Dz2FLRhDbr6YjwSx46moQRjSlon/CScstQOQeKDivrgg5Sis82BB361bMcN0GT0/0oMWBagBXzkGWtmAxxxVBUtjQXUO97AdKZ5RzCAClbgzeb4vVSb+5CBSCRfWMtAxN8lrBoHqyDB6fYsKdAXFERe53yvwgwrNodyJ6Yzr0uDV 2fTIBc9m 2vdqbU+uWAE4CdOcDD9Qvf3j8rQxnv1VvXTpQZDN3sOTXP43/slctns8zcP6I0/Jf+z2NC+YNbYHNjtmA94Nsc/ZfDAkuz0z7g53DtbmI0RJGKIso0TqpjVQEf3I7FhqOUUWiqL4b5QcKOgqmwWTEROvdn4ls1skRvJd5tGF4bgas1E8MK9+OKMgmMYVDTLWtj0j+lpe48lYgZ2mwDyaYXbQlU7J2QaAP25xFD1LdiveLWbQrA8g1dZcwnVG/HBZx+Bk5eWh3iJQ4HFvCfVAmeQ9GmpS/CUy/NVExAF1+uvEZGclT/2gr83RPjdqIKs1LxXJ9Wgr4faPoAuxO5hm6lXWvmHl5z8i66hadKleoSav0xaI0CqE/lSD+ovykho/0yPxpdMhYwx0OI/qlHXIDMqQSnkvq9UdT9F1U7kwCmJ51cRRG0adKGRhrRBh/qoYdd2qKsboDbh6x/W02VKC/tUqfzFBeEHvMP+4g 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: On Wed, Jun 18, 2025 at 02:25:37PM +0800, kernel test robot wrote: > > Hello, > > for this change, we reported > "[linux-next:master] [lib/test_vmalloc.c] 7fc85b92db: Mem-Info" > in > https://lore.kernel.org/all/202505071555.e757f1e0-lkp@intel.com/ > > at that time, we made some tests with x86_64 config which runs well. > > now we noticed the commit is in mainline now. > the config still has expected diff with parent: > > --- /pkg/linux/x86_64-randconfig-161-20250614/gcc-12/7a73348e5d4715b5565a53f21c01ea7b54e46cbd/.config 2025-06-17 14:40:29.481052101 +0800 > +++ /pkg/linux/x86_64-randconfig-161-20250614/gcc-12/2d76e79315e403aab595d4c8830b7a46c19f0f3b/.config 2025-06-17 14:41:18.448543738 +0800 > @@ -7551,7 +7551,7 @@ CONFIG_TEST_IDA=m > CONFIG_TEST_MISC_MINOR=m > # CONFIG_TEST_LKM is not set > CONFIG_TEST_BITOPS=m > -CONFIG_TEST_VMALLOC=m > +CONFIG_TEST_VMALLOC=y > # CONFIG_TEST_BPF is not set > CONFIG_FIND_BIT_BENCHMARK=m > # CONFIG_TEST_FIRMWARE is not set > > > then we noticed similar random issue with x86_64 randconfig this time. > > 7a73348e5d4715b5 2d76e79315e403aab595d4c8830 > ---------------- --------------------------- > fail:runs %reproduction fail:runs > | | | > :199 34% 67:200 dmesg.KASAN:null-ptr-deref_in_range[#-#] > :199 34% 67:200 dmesg.Kernel_panic-not_syncing:Fatal_exception > :199 34% 67:200 dmesg.Mem-Info > :199 34% 67:200 dmesg.Oops:general_protection_fault,probably_for_non-canonical_address#:#[##]SMP_KASAN > :199 34% 67:200 dmesg.RIP:down_read_trylock > > we don't have enough knowledge to understand the relationship between code > change and the random issues. just report what we obsverved in our tests FYI. > I think this is caused by a race between vmalloc_test_init and alloc_tag_init. vmalloc_test actually depends on alloc_tag via alloc_tag_top_users, because when memory allocation fails show_mem() would invoke alloc_tag_top_users. With following configuration: CONFIG_TEST_VMALLOC=y CONFIG_MEM_ALLOC_PROFILING=y CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT=y CONFIG_MEM_ALLOC_PROFILING_DEBUG=y If vmalloc_test_init starts before alloc_tag_init, show_mem() would cause a NULL deference because alloc_tag_cttype was not init yet. I add some debug to confirm this theory diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c index d48b80f3f007..9b8e7501010f 100644 --- a/lib/alloc_tag.c +++ b/lib/alloc_tag.c @@ -133,6 +133,8 @@ size_t alloc_tag_top_users(struct codetag_bytes *tags, size_t count, bool can_sl struct codetag *ct; struct codetag_bytes n; unsigned int i, nr = 0; + pr_info("memory profiling alloc top %d: %llx\n", mem_profiling_support, (long long)alloc_tag_cttype); + return 0; if (can_sleep) codetag_lock_module_list(alloc_tag_cttype, true); @@ -831,6 +833,7 @@ static int __init alloc_tag_init(void) shutdown_mem_profiling(true); return PTR_ERR(alloc_tag_cttype); } + pr_info("memory profiling ready %d: %llx\n", mem_profiling_support, (long long)alloc_tag_cttype); return 0; } When bootup the kernel, the log shows: $ sudo dmesg -T | grep profiling [Fri Jun 20 17:29:35 2025] memory profiling alloc top 1: 0 <--- alloc_tag_cttype == NULL [Fri Jun 20 17:30:24 2025] memory profiling ready 1: ffff9b1641aa06c0 vmalloc_test_init should happened after alloc_tag_init if CONFIG_TEST_VMALLOC=y, or mem_show() should check whether alloc_tag is done initialized when calling alloc_tag_top_users David