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 AEC3CC77B7F for ; Wed, 25 Jun 2025 00:52:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4BAAA6B00A5; Tue, 24 Jun 2025 20:52:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4440E6B00AB; Tue, 24 Jun 2025 20:52:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 333366B00AC; Tue, 24 Jun 2025 20:52:32 -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 1F6616B00A5 for ; Tue, 24 Jun 2025 20:52:32 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 8BD98C127B for ; Wed, 25 Jun 2025 00:52:31 +0000 (UTC) X-FDA: 83592097302.15.6DA79FC Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) by imf01.hostedemail.com (Postfix) with ESMTP id A5B0140002 for ; Wed, 25 Jun 2025 00:52:29 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=odl44Kfd; spf=pass (imf01.hostedemail.com: domain of surenb@google.com designates 209.85.160.172 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750812749; 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=WSwW+xIhvHfP2n82ypS/Wn9Qq6NX23eYFIUnCLJFSpw=; b=qMpzKqGin1/mk9FjYCWbYXwZUQmF6RYnmxzFVonKepv8ogmDEAe3p+uaJ6NbSceAfaAnwK pbgEZvC2T/nHEracIl7NiyPdXRuH5yh0TWoWUFiqLw+ilNbzWaS/Nxaag2GVdx+1j4VMGC Hr2K1zoi6TV6NcqiDIRIfX2CDoQtkrg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750812749; a=rsa-sha256; cv=none; b=jAbr7+vSNz4s6GmRtPK+xr9KstOX69vTXS2K2h69l6PP3tSaNvMiScnDJW5YaWLQxSwIkx i3V0NXU+El77FWatbsO7H4a6jrxLJqPtjVgTA1NB5grI5qDe8rfRpDzAK22Qj4oHKwZ8uG C2gM6tu2pcCeR3RcBFLr9wpmwgUtAEs= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=odl44Kfd; spf=pass (imf01.hostedemail.com: domain of surenb@google.com designates 209.85.160.172 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-4a5ac8fae12so204991cf.0 for ; Tue, 24 Jun 2025 17:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1750812749; x=1751417549; 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=WSwW+xIhvHfP2n82ypS/Wn9Qq6NX23eYFIUnCLJFSpw=; b=odl44KfdIw1O/eJByZY+sL4kk4zC56ZMM86NUD2veIEX+Ew+7c/2YLhU37MBtUmU03 nDJ3gagptlesxlH7An9wmp3s6CWfPignvQLr2zW8AVqV1B+9JMUtxhZrIqPXDnUI8GwD VBdwfcs0uxwc9w27JW/tJFOxJHrcZnqIaeRuY2jHQeVKI1MjGVsZLRuEQGhaMfHqmgo1 fXRITRy1IFIHoYYmkbr1AvWGAyq38H/CyFvMZ5jGSVeqV6uuadd6JSxcI9EgYsoTicwU f2GlSpMq05g39vAjZOm8C+8oCb20BHoDcXlzFmaa4fTwGOlhv/AuuJu6a702SFVZj4ki wcPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750812749; x=1751417549; 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=WSwW+xIhvHfP2n82ypS/Wn9Qq6NX23eYFIUnCLJFSpw=; b=fN82CxUUymhrNe7AxZXShXaE36DJzBb3xA6BEdxczava5IrDnslJQzoeXx48qXqFqA OQ/2v1A0eJysodUFpx89I4aNHJZ0BNHBI4BxhGKPJ3p3MqoCu7Tbl/OA9NZenDO00ydC oCwbrZ2zs9y8+uHtvoJ17YqbthPbWcm3EHVBWRYt9TfB6VgPDAOFEsczYSV2xbi67AEd r0diPeoU8TAHmQlNaMauPtlhYR+4IzjMJ3elE480QW1eFsoGXWuWCPU7PQkXfnbf4xIX N3kSTWSZMMKKgVBpLWqR9CvkPb7Ygn9nWNXbXxGVy0UTPAR+sT8wbrc+xu4jiU1/mTm2 kh4g== X-Forwarded-Encrypted: i=1; AJvYcCXaVZ9Cfuc+qpCeR3ehIgM5vGlhKyMAEscK4yv/q52b4yM5YnJ1mdpjYQreLIYaPM6jDjWqpAYowg==@kvack.org X-Gm-Message-State: AOJu0YxPWV+oRYCxVTd+zt08M+sU3lo6x2okViYbzJ9b4eceEdxzy60o OFknukf1r/86QBTVGTxDqk37VWyp35Q0vaBm2aaZaZdb2LB01ufdSajTPw4n5CBMSZ6RsokkCRE hR2DQOZ6f11dzc1XIWlBfM/6kd1lIt6NYMtzjV9iX X-Gm-Gg: ASbGncuT3no90lRKJQzoUm8OKKaFv4H6kgFJ7DtHcY5oXXAMIod9bkYcjPUVlywWWmI LxgPTe/xaV3sBbJxJaCXNrNfa1oGoEnoGxStp78k+w7fN0GuhnlCQ8+tWeLrdpC8OWUEDK6FS89 5iWbsIC/7SORu39jzv7XDJcM7nNpuHzVJZbMZ2bGa/xBD/lszXUrA0 X-Google-Smtp-Source: AGHT+IGW0s3Z21zLhutKE3Q2yJQO+RbEUgzPYht2EC0rHYCJKwd1wxOQmJduNe16htpPIhpza8ZyjWrC924RETnjIpU= X-Received: by 2002:a05:622a:1917:b0:479:1958:d81a with SMTP id d75a77b69052e-4a7c231bc81mr688391cf.6.1750812748318; Tue, 24 Jun 2025 17:52:28 -0700 (PDT) MIME-Version: 1.0 References: <20250624072513.84219-1-harry.yoo@oracle.com> <7f2f180f.a643.197a21de68c.Coremail.00107082@163.com> <2dba37c6.b15a.197a23dcce2.Coremail.00107082@163.com> <3942323b.b31d.197a2572832.Coremail.00107082@163.com> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 24 Jun 2025 17:52:17 -0700 X-Gm-Features: Ac12FXzl7cdhs3-J3HO9jp1NRd-686pg1FYiAY_L-CUy2cf6uWBIJvEKOSvtC-M Message-ID: Subject: Re: [PATCH v3] lib/alloc_tag: do not acquire non-existent lock in alloc_tag_top_users() To: Harry Yoo Cc: David Wang <00107082@163.com>, 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-Rspamd-Queue-Id: A5B0140002 X-Stat-Signature: 8hoinodxbua6s3p31poyfkz5uj9iyi3f X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1750812749-87565 X-HE-Meta: U2FsdGVkX1+SHtsXA5ImtRJsr/+ISoHNsbCBUjLTJOaTTqmx0Y18IiP6Ng2zMlGtC4qsBawTuOPDJ2UHUFv5iPQM7OY3rh5qnIhVssro+Bres0RyLT5JgvYCfKBmWsvF+XzCSW52glnOEf2yHUIxwzLDR5K6cI9BX2ggFQTJxxos2fUqRdbxcmuTEQS1H14S/ZPhtcGri8/kTdc1tN/+KnjJ7SvUrL8ifsB0qJnfsXcNd9ppBXu2iIWbMwJm177tKJrstNXIB/QYFLrqvseFIWSiJGrDkRj5jr4NBSu96QGX+xrQt+10TlWOQKVDyZndAHOwiJHY8OfHPSszVN6BTcTarAj8IuLA1ox9yfoiToTYPSSezg5VWBvb8PsRfQeV6p1x8fMTC8Jv/KHzMNA2wZBLxXLkbnVngJviyFaq5GBtFYHDz7iJZaBRfZEAfSAkEun7O+NJNx84FI9nSB4EGjxqEpPuRhac3m7nnDW1gOhpIT7ejitgYb2h1oyitz37UUnAwCg50m+M0YU8eReA/cl9q1g5735vE5Wr4YbTzkqK6NWkyGyPB3EwWnSfEHhamClGv4+M2P+EItJzYBdZQb1eF4labAhA8y/l7PqIc0GHJmcdDIpra1FlPgY2qu6aiZ5DUS8AUogFJeQTdKR3sy5WQJUh5qLPRb+czuxGhPNgIGpxNDznbJt2o0lgmlxZyLtmvLkF8lNSy1ixrv8MgBR5ceeAz6Z0S1th6K4ham4ZgWQioHF0DjdKRwoPY6uZ4Q0VsshdXiq8sW1nLrjKgfBc5+1qi2s3+wDxXp2DGopC42FmsvJnudqVEkz6PS+L2Xsedcif+ZGodbfmFfEPm1eSHGmEV1UY3n4ua1ycoO6H9MEg2POfnsV6kZvlTSAb/5+iQ43XnFb987mtRY2EfrMyk5/89U94StxbwmyFGguK4yWY+o6+JKkExvbQ8oVfwnQq5Qccf6D3eRebWEh Z5z22y6m ZwvCBhdOf1vcHYVWlWbaYEL1l5FP8f/dyRDj2UdrtiBNnTVRNT3H3pIeF9n1T3otOJHTGAT2pO28YW3eRxq35DZ7SD+Foig4Rpl5dF+QYqYPU7jlfhO5Bv4BGNKVjI7XG7bMMWn2FnRmLdoi+6nhmXTxxicRUu4U9VGBL+S7G1Q1GeQmQhYISq8dF1631g8lQBn12xhFW/9hL36/VR77p+14ELRVeFhzEC1Ioe6u+TajbIhsFZa7u7x0x14DN0uwzm1MRUedE/lu3mQDpiKHCW0gUO8nBIWqOfCeiws05i36/8PPM5LTmBzRV/clwqsV3kiAK5XSF3dc/ftLibGtn3JIs/uaHW8nyAWs858Fa3z2XFW/s/75mrrlpjeudasqM46u8azqhxN0TD5Fk3xRFy1cUAcQXEnbus5KHg6TJ5O6wBhGWPE2VbmtQaBzd6ziZTUxHRsoTtK6MK0uSjbUEVKmfWYsR/bHiosOWM1Qjbsq6t08cOIv1vIueeg== 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 Tue, Jun 24, 2025 at 11:01=E2=80=AFAM Harry Yoo w= rote: > > On Tue, Jun 24, 2025 at 08:38:05AM -0700, Suren Baghdasaryan wrote: > > On Tue, Jun 24, 2025 at 8:14=E2=80=AFAM Harry Yoo wrote: > > > > > > On Tue, Jun 24, 2025 at 07:57:40AM -0700, Suren Baghdasaryan wrote: > > > > On Tue, Jun 24, 2025 at 7:28=E2=80=AFAM David Wang <00107082@163.co= m> wrote: > > > > > > > > > > > > > > > At 2025-06-24 22:13:49, "Harry Yoo" wrote: > > > > > >On Tue, Jun 24, 2025 at 10:00:48PM +0800, David Wang wrote: > > > > > >> > > > > > >> At 2025-06-24 21:50:02, "Harry Yoo" wro= te: > > > > > >> >On Tue, Jun 24, 2025 at 09:25:58PM +0800, David Wang wrote: > > > > > >> >> > > > > > >> >> At 2025-06-24 15:25:13, "Harry Yoo" = wrote: > > > > > >> >> >alloc_tag_top_users() attempts to lock alloc_tag_cttype->m= od_lock > > > > > >> >> >even when the alloc_tag_cttype is not allocated because: > > > > > >> >> > > > > > > >> >> > 1) alloc tagging is disabled because mem profiling is di= sabled > > > > > >> >> > (!alloc_tag_cttype) > > > > > >> >> > 2) alloc tagging is enabled, but not yet initialized (!a= lloc_tag_cttype) > > > > > >> >> > 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 there= fore > > > > > >> >> >alloc_tag_top_users() should not attempt to acquire the se= maphore. > > > > > >> >> > > > > > > >> >> >This leads to a crash on memory allocation failure by atte= mpting to > > > > > >> >> >acquire a non-existent semaphore: > > > > > >> >> > > > > > > >> >> > Oops: general protection fault, probably for non-canonic= al address 0xdffffc000000001b: 0000 [#3] SMP KASAN NOPTI > > > > > >> >> > KASAN: null-ptr-deref in range [0x00000000000000d8-0x000= 00000000000df] > > > > > >> >> > 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), B= IOS 1.16.2-debian-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 48 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: 0000000= 000000000 > > > > > >> >> > RDX: 000000000000001b RSI: 000000000000000a RDI: 0000000= 000000070 > > > > > >> >> > RBP: 00000000000000d8 R08: 0000000000000001 R09: ffffed1= 07dde49d1 > > > > > >> >> > R10: ffff8883eef24e8b R11: ffff8881002cec20 R12: 1ffff11= 020059d37 > > > > > >> >> > R13: 00000000003fff7b R14: ffff8881002cec20 R15: dffffc0= 000000000 > > > > > >> >> > FS: 00007f963f21d940(0000) GS:ffff888458ca6000(0000) kn= lGS:0000000000000000 > > > > > >> >> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > > > > >> >> > CR2: 00007f963f5edf71 CR3: 000000010672c000 CR4: 0000000= 000350ef0 > > > > > >> >> > 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 trig= ger after commit > > > > > >> >> >780138b12381 ("alloc_tag: check mem_profiling_support in a= lloc_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 ea= sily triggered > > > > > >> >> >when memory profiling is compiled but disabled at boot. > > > > > >> >> > > > > > > >> >> >To properly determine whether alloc_tag_init() has been ca= lled and > > > > > >> >> >its data structures initialized, verify that alloc_tag_ctt= ype is a valid > > > > > >> >> >pointer before acquiring the semaphore. If the variable is= NULL or an error > > > > > >> >> >value, it has not been properly initialized. In such a cas= e, just skip > > > > > >> >> >and do not attempt to acquire the semaphore. > > > > > >> >> > > > > > > >> >> >Reported-by: kernel test robot > > > > > >> >> >Closes: https://urldefense.com/v3/__https://lore.kernel.or= g/oe-lkp/202506181351.bba867dd-lkp@intel.com__;!!ACWV5N9M2RV99hQ!MADvGKtvTv= lLXNxlrJ4BdOSnbsJlyrSroPUGJ3JQHs_IF-gxxqfQ89OTZ21aN96DbmjG9qH3Wi1MlgtiSA$ > > > > > >> >> >Closes: https://urldefense.com/v3/__https://lore.kernel.or= g/oe-lkp/202506131711.5b41931c-lkp@intel.com__;!!ACWV5N9M2RV99hQ!MADvGKtvTv= lLXNxlrJ4BdOSnbsJlyrSroPUGJ3JQHs_IF-gxxqfQ89OTZ21aN96DbmjG9qH3Wi0o2OoynA$ > > > > > >> >> >Fixes: 780138b12381 ("alloc_tag: check mem_profiling_suppo= rt in alloc_tag_init") > > > > > >> >> >Fixes: 1438d349d16b ("lib: add memory allocations report i= n show_mem()") > > > > > >> >> >Cc: stable@vger.kernel.org > > > > > >> >> >Signed-off-by: Harry Yoo > > > > > >> >> >--- > > > > > >> >> > > > > > > >> >> >@Suren: I did not add another pr_warn() because every erro= r path in > > > > > >> >> >alloc_tag_init() already has pr_err(). > > > > > >> >> > > > > > > >> >> >v2 -> v3: > > > > > >> >> >- Added another Closes: tag (David) > > > > > >> >> >- Moved the condition into a standalone if block for bette= r readability > > > > > >> >> > (Suren) > > > > > >> >> >- Typo fix (Suren) > > > > > >> >> > > > > > > >> >> > lib/alloc_tag.c | 3 +++ > > > > > >> >> > 1 file changed, 3 insertions(+) > > > > > >> >> > > > > > > >> >> >diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c > > > > > >> >> >index 41ccfb035b7b..e9b33848700a 100644 > > > > > >> >> >--- a/lib/alloc_tag.c > > > > > >> >> >+++ b/lib/alloc_tag.c > > > > > >> >> >@@ -127,6 +127,9 @@ size_t alloc_tag_top_users(struct code= tag_bytes *tags, size_t count, bool can_sl > > > > > >> >> > struct codetag_bytes n; > > > > > >> >> > unsigned int i, nr =3D 0; > > > > > >> >> > > > > > > >> >> >+ if (IS_ERR_OR_NULL(alloc_tag_cttype)) > > > > > >> >> >+ return 0; > > > > > >> >> > > > > > >> >> What about mem_profiling_support set to 0 after alloc_tag_i= nit, in this case: > > > > > >> >> alloc_tag_cttype !=3D NULL && mem_profiling_support=3D=3D0 > > > > > >> >> > > > > > >> >> I kind of think alloc_tag_top_users should return 0 in this= case....and both mem_profiling_support and alloc_tag_cttype should be che= cked.... > > > > > >> > > > > > > >> >After commit 780138b12381, alloc_tag_cttype is not allocated = if > > > > > >> >!mem_profiling_support. (And that's why this bug showed up) > > > > > >> > > > > > >> There is a sysctl(/proc/sys/vm/mem_profiling) which can overri= de mem_profiling_support and set it to 0, after alloc_tag_init with mem_pro= filing_support=3D1 > > > > > > > > Wait, /proc/sys/vm/mem_profiling is changing mem_alloc_profiling_ke= y, > > > > not mem_profiling_support. Am I missing something? > > > > > > Feels like it should call shutdown_mem_profiling() instead of > > > proc_do_static_key() (and also remove /proc/allocinfo)? > > > > No, we should be able to re-enable it later on. > > A few questions that came up while reading this, > please feel free to ignore :) > > - What is the expected output of /proc/allocinfo when it's disabled? > Should it print old data or nothing? I think it should be consistent > with the behavior of alloc_tag_top_users(). > > - When it's disabled and re-enabled again, can we see inconsistent > data if some memory has been freed in the meantime? > > > You can't do that if you call shutdown_mem_profiling(). > > Because setting mem_profiling_support =3D false mean it's not supported. > And you can't re-enable if it's not supported. Gotcha! > > > mem_profiling_support is very different from mem_alloc_profiling_key. > > mem_profiling_support means memory profiling is not supported while > > mem_alloc_profiling_key means it's enabled or disabled and can be > > changed later. > > Okay. Now I see why I was confused. Perhaps I should have guessed that > from the name, but I was not 100% sure about the meaning. > > > > > > > > > > > > >Ok. Maybe it shouldn't report memory allocation information that= is > > > > > >collected before mem profiling was disabled. (I'm not sure why i= t disabling > > > > > >at runtime is allowed, though) > > > > > > > > > > > >That's a good thing to have, but I think that's a behavioral cha= nge in > > > > > >mem profiling, irrelevant to this bug and not a -stable thing. > > > > > > > > > > > >Maybe as a follow-up patch? > > > > > > > > > > Only a little more changes needed, I was suggesting: > > > > > > > > > > @@ -134,6 +122,14 @@ size_t alloc_tag_top_users(struct codetag_by= tes *tags, size_t count, bool can_sl > > > > > struct codetag_bytes n; > > > > > unsigned int i, nr =3D 0; > > > > > > > > > > + if (!mem_profiling_support) > > > > > + return 0; > > > > > > > > David is right that with /proc/sys/vm/mem_profiling memory profilin= g > > > > can be turned off at runtime but the above condition should be: > > > > if (!mem_alloc_profiling_enabled()) > > > > return 0; > > > > > > I agree that this change is a useful addition, but adding it to the p= atch > > > doesn't look right. It's doing two different things. > > > > You might be right, calling alloc_tag_top_users() while > > !mem_alloc_profiling_enabled() will print older data but it won't lead > > to UAF. > > Yes and I think it'll be great if David could post it after the fix lands > maineline. > > Aside from that, any feedback on the v3 of the patch? > > If yes, I'll adjust it. > If not, please consider an ack ;) LGTM. Acked-by: Suren Baghdasaryan > > > > > > + > > > > > + if (IS_ERR_OR_NULL(alloc_tag_cttype)) { > > > > > + pr_warn("alloctag module is not ready yet.\n"); > > > > > > > > I don't think spitting out this warning on every show_mem() is usef= ul. > > > > If alloc_tag_cttype is invalid because codetag_register_type() fail= ed > > > > then we already print an error here: > > > > https://elixir.bootlin.com/linux/v6.16-rc3/source/lib/alloc_tag.c#L= 829, > > > > so user has the logs to track this down. > > > > If show_mem() is called so early that alloc_tag_init() hasn't been > > > > called yet then missing allocation tag information would not be > > > > surprising I think, considering it's early boot. I don't think it's > > > > worth detecting and reporting such a state. > > > > > > > > > + return 0; > > > > > + } > > > > > + > > > > > > -- > > > Cheers, > > > Harry / Hyeonggon > > > > -- > Cheers, > Harry / Hyeonggon