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 30AA4C77B7C for ; Sun, 22 Jun 2025 22:24:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8CC196B00A3; Sun, 22 Jun 2025 18:24:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 87CCC6B00AD; Sun, 22 Jun 2025 18:24:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 76BC16B00AE; Sun, 22 Jun 2025 18:24:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 63F696B00A3 for ; Sun, 22 Jun 2025 18:24:23 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 0E64980FA6 for ; Sun, 22 Jun 2025 22:24:23 +0000 (UTC) X-FDA: 83584466406.15.D5B744B Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) by imf20.hostedemail.com (Postfix) with ESMTP id 3C73B1C0003 for ; Sun, 22 Jun 2025 22:24:21 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ihwol+8I; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of surenb@google.com designates 209.85.160.182 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750631061; a=rsa-sha256; cv=none; b=rrD6IVPGYahn4HAIUWrKQN2LD0A9unApDfv6sjXuNHrs8wA+1f5EflAAxfK+jGjoqRoJnj 8L3sJWz9LZ0D0nK9Qp/KN9PvkNpUkm2MBA5ZZWYjZNEkG7eo7AHqid+OhLEilyHZaYEC4f 4tEflji5KRm21r+W1ozokCy3wpRwPKU= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ihwol+8I; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of surenb@google.com designates 209.85.160.182 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750631061; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=z2GI2494rUC/2TZW0ywCzgu9F19ggR5YUviGIVZ+qfY=; b=elfmOffSZf0/DZPLOh6N1ckF5J+LyDQTOKGhvAAO15q5uKfm1tganrIOtIEIOlqJgl8CI2 oY8fLocV3wkWkblF5DvXhWz6KmFZhgSJ4yqmTkOdN1ERrvmrkxXRCb5mHQUwtSFdqJ2+u4 nwVZghiR0Qd4wIkLCL5u4c0Iwa+J3as= Received: by mail-qt1-f182.google.com with SMTP id d75a77b69052e-4a5ac8fae12so480161cf.0 for ; Sun, 22 Jun 2025 15:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1750631060; x=1751235860; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=z2GI2494rUC/2TZW0ywCzgu9F19ggR5YUviGIVZ+qfY=; b=ihwol+8IPcK/4geMl0j1YiJlFWhWaUrwPY7H6G7x4laEo5U4/4VthZ4tT3pacdDo/3 pO20h/ebCIaUiaTGWTyBoW5J8pZDS/okTGrLVYNKvVvP62hbEOdEZK6+gwA0Am7h8bjn 5KmsdAbg9ZR4TZfEy00OI792ZSkBaI2Zigvs6radXBhjPphEnkZHrzssQu3BSsahtonr knjHVyANUJ4m5QgpGVEIrR0Ot2S9E7yqLR+xFDqWsf9/ITIFV9poCKh0T7xV6qjiOEqG O7gf47p/SWV6h8olIDxHBSirYtq8ucx+xOv641kG6W9mDmwZyMCQoqCHRfvWN9wcAdJY J6Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750631060; x=1751235860; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=z2GI2494rUC/2TZW0ywCzgu9F19ggR5YUviGIVZ+qfY=; b=AKtezHt/QyGZvQF1JB3+9XX8DZWYsRCNx2zDLolnLHdCJMRk1uSWfBZtiKoZ+Ub/aA 5PDAhvjQfHzFxqeAuyb1SUMxkevJDUvDutPj618xC4dKDtjcKRK9Aq9GmU2ikMcw8Y3i vlxXvaT4h+leDkrJCao+SiYAgkIdPywIydOPAp6AquC0rGffRAvMKNy5MdRvbv10tOZb KDfb2xEQguss+olBDdWaOrNjzouZknP3eWFZWnXjMglSn3AXempSTahDYY8vO+v0N7vX b6O7FA2Ahkv/hFJ7LhIMzkBbSCqNi7Tvw1pUV5UMXjgr1mmhBl9fInSr+GwT21hjysbC S8Jg== X-Forwarded-Encrypted: i=1; AJvYcCWZl61NGvcjvJ819DmVBdRH+exkPmKl9MlVdeQdZdruUxsZbH3LnFPincfb91nrFd9D3yyfFniA8A==@kvack.org X-Gm-Message-State: AOJu0YxgJyg+Idu9pcbhQ3iCJXEKy+9/fwmPp3NPpS/Y2WHMHW+am7tn mK1RUj8g6JYyRXbTL8UlUavAqrsO33VTmi5a9Jz88Vyl7/L+1nFcA8Vjc/1kZnuCCXbuGkBwElO wm7jlz1CG8L211IMk3zdUWAgJipEUTbhyydgNjLpc X-Gm-Gg: ASbGnctcbNBXbUcPKwvR+xfvzbMkOsVlFJlc+x5QgdYoGtMgG8j33GJlrsch48Kc6om PvC7GN9LYuDCb2D/ZoN6PUFaAxwUtV9s9Wj1lu95IgwBX3yi/BzHtyaMA5QIW/CFKNM51GRG8G2 Db83QQbpjPECy2u06pSlOqf9aPSprqQ8aSk1EFILzNyg== X-Google-Smtp-Source: AGHT+IFXpfw+xB4qC+6F0GtwYxkvSjZPT2sqzoTBpbCRyfAg/E0SGXmExBTMb8qlx3auQmultRnj8mhUyA+FgakccdY= X-Received: by 2002:a05:622a:11ca:b0:48a:42fa:78fa with SMTP id d75a77b69052e-4a7852dba43mr5237071cf.2.1750631059676; Sun, 22 Jun 2025 15:24:19 -0700 (PDT) MIME-Version: 1.0 References: <20250620195305.1115151-1-harry.yoo@oracle.com> <7935cfb1.1432.19790952566.Coremail.00107082@163.com> In-Reply-To: <7935cfb1.1432.19790952566.Coremail.00107082@163.com> From: Suren Baghdasaryan Date: Sun, 22 Jun 2025 15:24:08 -0700 X-Gm-Features: Ac12FXxuGqxZZyKQhgH0eqA4IJBrgYI4hYeartJ-8Oj8skCpD3dIFoo0_U2Xlwc Message-ID: Subject: Re: [PATCH v2] lib/alloc_tag: do not acquire non-existent lock in alloc_tag_top_users() To: David Wang <00107082@163.com> Cc: Harry Yoo , akpm@linux-foundation.org, kent.overstreet@linux.dev, oliver.sang@intel.com, cachen@purestorage.com, linux-mm@kvack.org, oe-lkp@lists.linux.dev, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: we3h5idkgnxa8fuypp744egkyde6hk11 X-Rspamd-Queue-Id: 3C73B1C0003 X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1750631061-275771 X-HE-Meta: U2FsdGVkX1/dL8nRRNUEE3zzBFvb/p2Yj+XKVBX0sP1L7GQ/vLUN1v1kpVOvaCFKE/nXFBPIscH8sDC+q5rjxaQ7J1alQtHd8n0zrW+4wrtcBhBl+Bt5c3omJZHGBJTQnFHVSzdGGX0ylX4iz5Yp1kJDBqt2skfD3bExs5ZW2EhHNUmz96/aXSEuQ3DD/jtiBbAxPhmf3h2CPUDseEEDj0IC//vVpEuSfzCnwWtc26P75776ELKdU5duigxwoMPS5Q5XKIXG5jgWme6yk+wgGryk3L5Z6dYRgv/Qfp0Fx8LlEOP2gO65o/Gual/msFeTfeCjIW/NFPgITmlSD/bwdp6L+TTRRnWCVh/+8M+nvVxs90hL1mW93DqtQbBsY3BLIakLVVm3gkiK1x7zrKLHV1fBtIxqVUyuJZIny2b5knDQtOzcndKeEFyPAg4z+xsmZfY1146FdYZ+sYlB+91VesfwoT/mHl7AtSG5MC9lZamgpGQof3B1BcJF+FJAKWYGZVi812USoBEBt3Dk/Wd06YzUgkryN+Y/gCfgg9gXry9AHyEWXLwTbJkUhEg6buDg8daNUsn7StUvvUX5/KKyBFATcpAqh5NWHJjJJjTnEUXzQwsEgwEN5MJo/Jrl1QEMog5ShDAVK+zxw8d2V1jhyK3a0g3NiY6ajNChcS+vNbTOLIB3gEFQtbkN3r7LVZhRUu4ptm/OAqu3tgnIzx7l/bZbRO8MXlKDvZrDytnZC08u2JXpdc7vmZfqkfCHf3BRpb+/zIbFlNjDYmqu1jEx8y00iB9Hyil8rSbZwIDsa2dV3mcfW9UXf5XoKWA1iCOUM5WN7jAn1oa2TT8Kix6KpwviPHMw+EMHSh5PfKySGmJHlq4KkviDQ0vL0ctuz+0jC4IooYr0tGU+90Z/dqz3NMhqQ1QTGBjR6MAL8gqYpY+ocBZADiEWa3UgFcVrbsDJPQHfGlHYOC/ogePf4no kFnmwbAR hSKpHOfwyOxTVA+LCpNxQrsJ8/qeDctZmUjLnpTZBff+4GQhyFaOOocLOsvwH/fYOiHOXnu+NYiu9DitnHcGya+i6KCM2XsHf2dwKX5fO1HSsbDRQLuJkKLBGzKyVQuP8dus2rzhjq9b4wfx63vpKf+jeyNXA6fREEeCoy+orURxoKxXaNBjagwqiGAqG8vt32TX9531REtpm8P3qm8etLSn9Z3SzCpgigWxh2XyMTHThIFM+D5WXEji/Ou7p4oyIBwvWqgK+EZOmnJdKl7Z1VSDZs68NufFm9xAqbfDJgFL5yoiV9QHDSfY7u8jKTf+TNoNrMN492ZtE0Kyi37Cu7B7CAjqZNF2wFnbf1iMeOIpaSkNoSLIuo4F+TwLbEtkDLzaB/gV3msgeYe9myQdqrFGLJ0lxK2nomae1 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 Fri, Jun 20, 2025 at 8:43=E2=80=AFPM David Wang <00107082@163.com> wrote= : > > > At 2025-06-21 03:53:05, "Harry Yoo" wrote: > >alloc_tag_top_users() attempts to lock alloc_tag_cttype->mod_lock > >even when the alloc_tag_cttype is not allocated because: > > > > 1) alloc tagging is disabled because mem profiling is disabled > > (!alloc_tag_cttype) > > 2) alloc tagging is enabled, but not yet initialized (!alloc_tag_cttyp= e) > > 3) alloc tagging is enabled, but failed initialization > > (!alloc_tag_cttype or IS_ERR(alloc_tag_cttype)) > > > >In all cases, alloc_tag_cttype is not allocated, and therefore > >alloc_tag_top_users() should not attempt to acquire the semaphore. > > > >This leads to a crash on memory allocation failure by attempting to > >acquire a non-existent semaphore: > > > > Oops: general protection fault, probably for non-canonical address 0xd= ffffc000000001b: 0000 [#3] SMP KASAN NOPTI > > KASAN: null-ptr-deref in range [0x00000000000000d8-0x00000000000000df] > > CPU: 2 UID: 0 PID: 1 Comm: systemd Tainted: G D 6.16.= 0-rc2 #1 VOLUNTARY > > Tainted: [D]=3DDIE > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-deb= ian-1.16.2-1 04/01/2014 > > RIP: 0010:down_read_trylock+0xaa/0x3b0 > > Code: d0 7c 08 84 d2 0f 85 a0 02 00 00 8b 0d df 31 dd 04 85 c9 75 29 4= 8 b8 00 00 00 00 00 fc ff df 48 8d 6b 68 48 89 ea 48 c1 ea 03 <80> 3c 02 00= 0f 85 88 02 00 00 48 3b 5b 68 0f 85 53 01 00 00 65 ff > > RSP: 0000:ffff8881002ce9b8 EFLAGS: 00010016 > > RAX: dffffc0000000000 RBX: 0000000000000070 RCX: 0000000000000000 > > RDX: 000000000000001b RSI: 000000000000000a RDI: 0000000000000070 > > RBP: 00000000000000d8 R08: 0000000000000001 R09: ffffed107dde49d1 > > R10: ffff8883eef24e8b R11: ffff8881002cec20 R12: 1ffff11020059d37 > > R13: 00000000003fff7b R14: ffff8881002cec20 R15: dffffc0000000000 > > FS: 00007f963f21d940(0000) GS:ffff888458ca6000(0000) knlGS:0000000000= 000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > CR2: 00007f963f5edf71 CR3: 000000010672c000 CR4: 0000000000350ef0 > > Call Trace: > > > > codetag_trylock_module_list+0xd/0x20 > > alloc_tag_top_users+0x369/0x4b0 > > __show_mem+0x1cd/0x6e0 > > warn_alloc+0x2b1/0x390 > > __alloc_frozen_pages_noprof+0x12b9/0x21a0 > > alloc_pages_mpol+0x135/0x3e0 > > alloc_slab_page+0x82/0xe0 > > new_slab+0x212/0x240 > > ___slab_alloc+0x82a/0xe00 > > > > > >As David Wang points out, this issue became easier to trigger after comm= it > >780138b12381 ("alloc_tag: check mem_profiling_support in alloc_tag_init"= ). > > > >Before the commit, the issue occurred only when it failed to allocate > >and initialize alloc_tag_cttype or if a memory allocation fails before > >alloc_tag_init() is called. After the commit, it can be easily triggered > >when memory profiling is compiled but disabled at boot. Thanks for the fix and sorry about the delay with reviewing it. > > > >To properly determine whether alloc_tag_init() has been called and > >its data structures initialized, verify that alloc_tag_cttype is a valid > >pointer before acquiring the semaphore. If the variable is NULL or an er= ror > >value, it has not been properly initialized. In such a case, just skip > >and do not attempt acquire the semaphore. nit: s/attempt acquire/attempt to acquire > > > >Reported-by: kernel test robot > >Closes: https://lore.kernel.org/oe-lkp/202506181351.bba867dd-lkp@intel.c= om > >Fixes: 780138b12381 ("alloc_tag: check mem_profiling_support in alloc_ta= g_init") > >Fixes: 1438d349d16b ("lib: add memory allocations report in show_mem()") > >Cc: stable@vger.kernel.org > >Signed-off-by: Harry Yoo > > Just notice another thread can be closed as well: > https://lore.kernel.org/all/202506131711.5b41931c-lkp@intel.com/ > This coincide with scenario #1, where OOM happened with > CONFIG_MEM_ALLOC_PROFILING=3Dy > # CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT is not set > # CONFIG_MEM_ALLOC_PROFILING_DEBUG is not set > > >--- > > > >v1 -> v2: > > > >- v1 fixed the bug only when MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT=3Dn. > > > > v2 now fixes the bug even when MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT= =3Dy. > > I didn't expect alloc_tag_cttype to be NULL when > > mem_profiling_support is true, but as David points out (Thanks David!) > > if a memory allocation fails before alloc_tag_init(), it can be NULL. > > > > So instead of indirectly checking mem_profiling_support, just directly > > check if alloc_tag_cttype is allocated. > > > >- Closes: https://lore.kernel.org/oe-lkp/202505071555.e757f1e0-lkp@intel= .com > > tag was removed because it was not a crash and not relevant to this > > patch. > > > >- Added Cc: stable because, if an allocation fails before > > alloc_tag_init(), it can be triggered even prior-780138b12381. > > I verified that the bug can be triggered in v6.12 and fixed by this > > patch. > > > > It should be quite difficult to trigger in practice, though. > > Maybe I'm a bit paranoid? > > > > lib/alloc_tag.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > >diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c > >index 66a4628185f7..d8ec4c03b7d2 100644 > >--- a/lib/alloc_tag.c > >+++ b/lib/alloc_tag.c > >@@ -124,7 +124,9 @@ size_t alloc_tag_top_users(struct codetag_bytes *tag= s, size_t count, bool can_sl > > struct codetag_bytes n; > > unsigned int i, nr =3D 0; > > > >- if (can_sleep) > >+ if (IS_ERR_OR_NULL(alloc_tag_cttype)) > >+ return 0; So, AFAIKT alloc_tag_cttype will be NULL when memory profiling is disabled and it will be ENOMEM if codetag_register_type() fails. I think it would be good to add a pr_warn() in the alloc_tag_init() when codetag_register_type() fails so that the user can determine the reason why show_mem() report is missing allocation tag information. > >+ else if (can_sleep) nit: the above extra "else" is not really needed. The following should work just fine, is more readable and produces less churn: + if (IS_ERR_OR_NULL(alloc_tag_cttype)) + return 0; + if (can_sleep) codetag_lock_module_list(alloc_tag_cttype, true); else if (!codetag_trylock_module_list(alloc_tag_cttype)) return 0; > > codetag_lock_module_list(alloc_tag_cttype, true); > > else if (!codetag_trylock_module_list(alloc_tag_cttype)) > > return 0; > >-- > >2.43.0