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 913BAC3ABC6 for ; Thu, 8 May 2025 21:41:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1EF576B00A7; Thu, 8 May 2025 17:41:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 175D66B00A9; Thu, 8 May 2025 17:41:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 016B56B00AE; Thu, 8 May 2025 17:41:49 -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 CF1A26B00A7 for ; Thu, 8 May 2025 17:41:49 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 3DB4FBE704 for ; Thu, 8 May 2025 21:41:51 +0000 (UTC) X-FDA: 83421063222.06.8EBC8C9 Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) by imf09.hostedemail.com (Postfix) with ESMTP id 4D158140008 for ; Thu, 8 May 2025 21:41:49 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Lq6o3rVz; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.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=1746740509; 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=EmKk3GLSRxx8+Kwgcnr1XAp5wF86LzLkBPKCEHaK3X8=; b=JrZzmIytPbtzFRmVrP9cYSMPrNNFm43xVm91bfo7Lz7YeAN10I/wVPkdB4DboejfijGYY8 Bz24juDgThMk0kTwTEqZHTW29qcfHfrmwZH93pZEKmFvxSezewAKzMRGn3bvEvauulEKoG wYBEZjLaqO7huLcN2/rJ9H3k3N0+yJ8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746740509; a=rsa-sha256; cv=none; b=7rNAFrprjIdzvyrosLWwq40vvIh+URyIQmlNkIe9MdTMXBtb+7z1pO1+bY+P+x2z28FKYi SggzJS3f9y3c2fXYeYQNLQMlz1kwarHT0yPMdtGXIbDkg5bfSGc0JBp8pps/oRXEro4Vlf AlK2I5RpI3v8DZfmYX+jFpNHbEGDtkA= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Lq6o3rVz; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of surenb@google.com designates 209.85.160.182 as permitted sender) smtp.mailfrom=surenb@google.com Received: by mail-qt1-f182.google.com with SMTP id d75a77b69052e-47e9fea29easo41551cf.1 for ; Thu, 08 May 2025 14:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1746740508; x=1747345308; 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=EmKk3GLSRxx8+Kwgcnr1XAp5wF86LzLkBPKCEHaK3X8=; b=Lq6o3rVzlM7Ba/VdJheJBXbw3Zm2ekLf+xJZ+G+frxFPBduCqAcD7OqhN7foPvQNnA sRBpdb6WJR7R1jq6TjVv4Cw97WoEqE+KXX0XmJHQYISufhfT3KrgWiwSqtzzkufbvWU9 A3s5AJEAgX9u3SMWfyauo/jaHuBo5jcoaYgUw0wvgoDrO/j0LZ8/K4rHtHEnLIqo2Z2N ZyVefQl4IXamieHmI143NiR0M8a3s4TG3zDtC669YtumNA0kd2OxxrY+i4oOZZtMEBQF 6rDdwJZbB8+pGcDv1d7qEvH/p4InqdUCQ3BFvG7g89apHFjLFzI0gaeQmidRLjL000V6 xn0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746740508; x=1747345308; 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=EmKk3GLSRxx8+Kwgcnr1XAp5wF86LzLkBPKCEHaK3X8=; b=SzNWb3u27BDaoCQ/C9Yr1G7hKZMZ9Z714vQyoVOc40h6DS9eTX0azDYXNI8lwSSHoH 6J4hGzhPzSJAtyatEeV0J8uaBXvGxmf6dpghq4Groas8QBNYLTnnwNGYRNpekjxJEgPL UYEi105LSVYzCEcTkMtxIgS4uvCnVt8jOwtHSWtegIHp2PbJ3Y8BuAmNd6cz+elUgXAF oHgEw5P24pMuHFJ9nlMcCNPzgbMo/Up9wFIiPJK3a4Q5BGgsckfWT+EOmKtEZPtXm/Bj e5SW3quyG+Icl3XHw+jOXbHimCz2128vdmQBisf4uE3jJTdwHMTf7DkW0GDRWBF/u6TY p1RQ== X-Forwarded-Encrypted: i=1; AJvYcCWMKCSY8MSjU6e8OJMNT7jICjliqn1Q93lGH6tXJsYNFdyK8fH6ZPmry8LP8Cr8GOBr/JXSPzm07Q==@kvack.org X-Gm-Message-State: AOJu0YyRQ6UHBj9G02kLb8/MEh2o+nkx0YvQnNfvZLqsoSyvsPfusyjn 7RdNiAEji9O7P3yXdt2dxgeRRrSiZ7dbX61rEXIiJl85/PSKxgiB+PDRE4nFYaGtFjT9x/KnX8F 14KmjYjxDTmO9Y+I3op1zpEDlrsQxlOwq7tWc X-Gm-Gg: ASbGncuPubQ0SPm5IAUpjFbwX9gakRiJUALkoh4sU9NLwV/WZheCUvN2VDwDleIrHSr t3hjKwVlAap2a20HQ560AU2zcJCAMWdbuLa0gbdTKS+R+pQU1J6VoeXC/mPoLNeKm+3TNkvJx2j RjbZ4oNd0QXzRgQjUaWAbE71K8AecPG6x2REaThLaSq+3pM9vst/4= X-Google-Smtp-Source: AGHT+IF7q2Ij3uVjNzAszC8Nhjpr+Cen/gqEZNPE458JraRVOTyXNcyTUF7bxg1OzNGFhanICUsBRRdT5rUs0eAFHBY= X-Received: by 2002:a05:622a:64c:b0:476:f181:efeb with SMTP id d75a77b69052e-49452cc1a2dmr1310391cf.16.1746740508068; Thu, 08 May 2025 14:41:48 -0700 (PDT) MIME-Version: 1.0 References: <20250507175500.204569-1-00107082@163.com> <531adbba.b537.196b0868a8c.Coremail.00107082@163.com> In-Reply-To: <531adbba.b537.196b0868a8c.Coremail.00107082@163.com> From: Suren Baghdasaryan Date: Thu, 8 May 2025 14:41:36 -0700 X-Gm-Features: AX0GCFuCR9elxrj-B0jGMzMMGRNkb45rYCG_9syGViivQkpSvf8Wp1XcQfp2J6Y Message-ID: Subject: Re: [PATCH] alloc_tag: avoid mem alloc and iter reset when reading allocinfo To: David Wang <00107082@163.com> Cc: kent.overstreet@linux.dev, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 4D158140008 X-Rspam-User: X-Stat-Signature: kiiyj7zojcpg6gd1yqpdhnjrp7uhnnca X-HE-Tag: 1746740509-446974 X-HE-Meta: U2FsdGVkX1+BqeaP9Q/M68RfbSnZfmDBIM0RAekYZzyjZi8GctLWQg8bgI0gjqs02vGhGmqMq08egshrSY3vo0aSTsiMtekbeDFCtpTrHALdV7v3BFTNkbe5pkYiBSTySPrEoAnnkFwVqT50LyduJGMpYnU9BXsQcbXUGlN5PQG4ovg8k0waUhc+DNWgxC0utzyVo+ZfbDk6cFGQCWK/7MVupDWS3hZdjWC4ZbBW5s+xF+oGOp+RtVNT0KedHEYvBs/zPQgKyJhDCkM2hDO+6fTIkseJ1j4XuHMiHv1+jS9xPhRfAw+JfV+Nw+AgciyMhF4cXXEEQzdL7wlv72Jlu/k4k0yAPIrWRtXtli0oZzH+4KdBMS/qV6za9Xyan/gzWhn7vrgTJOEIW+0eugl+wsyKCygpD0icUhIYy0uUker2bf0wNNspfMSLQa4OsRnMF3YAdgATbgLvVFykqO4qPx4bBH49l7lNHQ50mormpAZf5XyRm1qh9rjr7rdxyP6Lri0/NvOnegHtKfbyp05+eyfiLWbRaxkVkBVUlsrVVX67AEICpNvG8WbMdkkYIPwLhMjaFpOZ7vW13QF4aPWT6GDx6JApfhMyEWPbDoFLer4m5LOwu1sadjDSsq2lXYZStuAIP04JR923wP5ciMUYed7kjeNn011CGUFC9tFprR2dAKcD8zu5gQGNe1ulQp7uydDSy34hqKQqzFdTpVRRG19VsHfA2Ypf4EQKC4PoR9Nl5mS5swm5NWfdBElWSyxOVk0xR0WaVNMKVLcRHzjSZ5ELSsme4Tn6gJmLEdDCt9d+Vxf3J4EslNWmwXAy99IR+TcmR/qZ0784ZhTEbip3G4vcsPbZfGUr1PViu4NFNu5oEQlQU97RJgz9Uv+c6FQuZUl62t+iDI6Vr/TqR8LpNZpPL5DG12sv2evl4WnBEr+Bsa50giynRLqyLu4Zp+lBec1uE8WbJ92GmoOFTpZ Xwoo/B3E LRKjcgrnTG0PpnMBBsT335CGohxGEYT3q2FcHWU1mkRZ+KcRWXsdV+fhC8XLlgb0Obl/9mMDYgMrqTqHlvuibvLANWnBehmHhO+4XFBd9m/k8Lg250CVzpNsfRHmtkQDjHk+xOzwrd6Lowx/pnkVC8PxZL1PloN2ROaA4ySsR+BGfeXF9i8A3hIBtzXwNf3nmvti76tv0loe/eK9pN8Fnsk2Yng5AkAaDpWB9um6BVZw8CWm4UQIVXF79t26VVX5WAWbytYKg/ki+iv3ngxUQuzB/uiYZZhYxgIz1cVwqXv5QgGKnHssKOyCvTcntlHZzlqS1v5o+DRKctzP6zCCt9QizM4BGZTqbeZE/h9+cxsCEyIFDL1pZq3UjNY9G/fKG/xLYzI19afylOY3qCKYNqhEyjw8FFgP2p6Z956vuJnrn7l0= 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 Thu, May 8, 2025 at 8:32=E2=80=AFAM David Wang <00107082@163.com> wrote: > > > > At 2025-05-08 07:36:14, "Suren Baghdasaryan" wrote: > >On Wed, May 7, 2025 at 5:55=E2=80=AFPM David Wang <00107082@163.com> wro= te: > >> > >> --- > >> The patch is not complete, just want to get feedbacks whether this > >> worth carrying on. > > > >In such cases it's customary to mark the patch as RFC which saves you > >time on explaining your motivation :) > > > >> --- > >> When reading /proc/allocinfo, for each read syscall, seq_file would > >> invoke start/stop callbacks. In start callback, a memory is alloced > >> to store iterator and the iterator would restart from beginning to > >> walk to its previous position. > >> Each seq_file read() takes at most 4096 bytes, even read with a larger > >> user space buffer, meaning read out /proc/allocinfo, tens of read > >> syscalls are needed. For example, a 306036 bytes allocinfo files need > >> 76 reads: > >> > >> $ sudo cat /proc/allocinfo | wc > >> 3964 16678 306036 > >> > >> For those n=3D3964 lines, each read takes about m=3D3964/76=3D52 lines= , > >> the iter would be rewinding: > >> m steps on 1st read, > >> 2*m steps on 2nd read > >> 3*m steps on 3rd read > >> ... > >> n steps on the last read > >> totally, the iterator would be iterated O(n*n/m) times. > >> (Each read would take more time than previous one.) > >> > >> To use a private data alloced when /proc/allocinfo is opened, > >> the n/m memory alloction could be avoid, and there is no need > >> to restart the iterator from very beginning everytime. > >> So only 1 memory allocation and n steps for iterating are needed. > >> (Only when module changed, the iterator should be invalidated and > >> restart.) > > > >Yeah, your change makes sense and looks like a good optimization. From > >a quick look at the code, codetag_next_ct() should handle the case > >when a module gets removed from under us while we are not holding > >cttype->mod_lock. I'll need to take another closer look at it once you > >post an official patch. > >Thanks! > > > The module tag container designed more "compact" than I imaged. It seems = that no > extra iterator validation needed for most situations, but I get anxious a= bout the following > possibility: > > In between read() calls, module A removed and then module B inserted, acc= identally A > and B have same IDR id (id reused) and same "struct module" address (kmal= loc happened > to pick the cmod address kfree by module A). > If this happened, the `if (cmod !=3D iter->cmod)` check in codetag_next_c= t may not be > solid safe.... > > What about adding a clock/timestamp/expiration to cttype/module/iterator: I see there was a followup discussion but I don't think your question was answered. Instead of expiration I would suggest adding a timestamp in the struct codetag_module that would store the time module was loaded (basically the time when struct codetag_module gets created) and also add a timestamp in the struct codetag_iterator. Whenever iter->cmod gets assigned a new module during the walk (see https://elixir.bootlin.com/linux/v6.14.5/source/lib/codetag.c#L95) we update iterator's timestamp (iter->timestamp =3D cmod->timestamp) and then we can validate that the module was not replaced from under us by comparing ter->timestamp and cmod->timestamp. If the module was replaced from under us, the timestamps will not be equal, so we can reset the iterator. > > diff --git a/include/linux/codetag.h b/include/linux/codetag.h > index d14dbd26b370..fc9f430090ae 100644 > --- a/include/linux/codetag.h > +++ b/include/linux/codetag.h > @@ -54,6 +54,7 @@ struct codetag_iterator { > struct codetag_module *cmod; > unsigned long mod_id; > struct codetag *ct; > + unsigned long expiration; > }; > > #ifdef MODULE > diff --git a/lib/codetag.c b/lib/codetag.c > index 42aadd6c1454..a795b152ce92 100644 > --- a/lib/codetag.c > +++ b/lib/codetag.c > @@ -13,6 +13,8 @@ struct codetag_type { > struct idr mod_idr; > struct rw_semaphore mod_lock; /* protects mod_idr */ > struct codetag_type_desc desc; > + /* timestamping iterator expiration */ > + unsigned long clock; > }; > > struct codetag_range { > @@ -23,6 +25,8 @@ struct codetag_range { > struct codetag_module { > struct module *mod; > struct codetag_range range; > + /* creation timestamp */ > + unsigned long timestamp; > }; > > static DEFINE_MUTEX(codetag_lock); > @@ -48,6 +52,7 @@ struct codetag_iterator codetag_get_ct_iter(struct code= tag_type *cttype) > .cmod =3D NULL, > .mod_id =3D 0, > .ct =3D NULL, > + .expiration =3D 0, > }; > > return iter; > @@ -93,6 +98,11 @@ struct codetag *codetag_next_ct(struct codetag_iterato= r *iter) > > if (cmod !=3D iter->cmod) { > iter->cmod =3D cmod; > + iter->expiration =3D cmod->timestamp; > + ct =3D get_first_module_ct(cmod); > + } else if (cmod->timestamp !=3D iter->expiration) { > + pr_warn("Same IDR id and module address, but diff= erent module!"); > + iter->expiration =3D cmod->timestamp; > ct =3D get_first_module_ct(cmod); > } else > ct =3D get_next_module_ct(iter); > @@ -101,6 +111,7 @@ struct codetag *codetag_next_ct(struct codetag_iterat= or *iter) > break; > > iter->mod_id++; > + iter->cmod =3D NULL; > } > > iter->ct =3D ct; > @@ -169,6 +180,7 @@ static int codetag_module_init(struct codetag_type *c= ttype, struct module *mod) > struct codetag_module *cmod; > int err; > > + cttype->clock++; > range =3D get_section_range(mod, cttype->desc.section); > if (!range.start || !range.stop) { > pr_warn("Failed to load code tags of type %s from the mod= ule %s\n", > @@ -188,6 +200,7 @@ static int codetag_module_init(struct codetag_type *c= ttype, struct module *mod) > > cmod->mod =3D mod; > cmod->range =3D range; > + cmod->timestamp =3D cttype->clock; > > down_write(&cttype->mod_lock); > err =3D idr_alloc(&cttype->mod_idr, cmod, 0, 0, GFP_KERNEL); > > > > > > And I notice another issue: there are duplicating keys(file:line+module+= func) in allocinfo even without this patch: > On my workstation : > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 1400832 114 ././common/inc/nv-linux.h:1117 [nvidia] func:nv_kme= m_cache_alloc_stack 840764 > 0 0 ././common/inc/nv-linux.h:1117 [nvidia] func:nv_kme= m_cache_alloc_stack 1 > 0 0 ././common/inc/nv-linux.h:1117 [nvidia] func:nv_kme= m_cache_alloc_stack 2 > 0 0 ././common/inc/nv-linux.h:1117 [nvidia] func:nv_kme= m_cache_alloc_stack 758 > 0 0 ././common/inc/nv-linux.h:1117 [nvidia] func:nv_kme= m_cache_alloc_stack 62951 > 0 0 ././common/inc/nv-linux.h:1117 [nvidia] func:nv_kme= m_cache_alloc_stack 1 > 0 0 ././common/inc/nv-linux.h:1117 [nvidia] func:nv_kme= m_cache_alloc_stack 325450 > 12288 1 ././common/inc/nv-linux.h:1117 [nvidia] func:nv_kme= m_cache_alloc_stack 1 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 81920 20 drivers/iommu/amd/../iommu-pages.h:94 func:iommu_al= loc_pages_node 20 > 1441792 352 drivers/iommu/amd/../iommu-pages.h:94 func:iommu_al= loc_pages_node 352 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 112 7 kernel/sched/sched.h:2587 func:alloc_user_cpus_ptr = 1591 > 48 3 kernel/sched/sched.h:2587 func:alloc_user_cpus_ptr = 12 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 48 1 mm/mm_slot.h:28 func:mm_slot_alloc 4 > 2160 54 mm/mm_slot.h:28 func:mm_slot_alloc 10705 > > Most duplicating keys are from "*.h" files > On a KVM, duplication also happens to some "*.c" files: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0 0 ./include/crypto/kpp.h:185 func:kpp_request_alloc > 0 0 ./include/crypto/kpp.h:185 func:kpp_request_alloc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0 0 ./include/net/tcp.h:2548 func:tcp_v4_save_options > 0 0 ./include/net/tcp.h:2548 func:tcp_v4_save_options > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0 0 drivers/iommu/amd/../iommu-pages.h:94 func:iommu_al= loc_pages_node > 0 0 drivers/iommu/amd/../iommu-pages.h:94 func:iommu_al= loc_pages_node > 0 0 drivers/iommu/amd/../iommu-pages.h:94 func:iommu_al= loc_pages_node > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0 0 drivers/iommu/intel/../iommu-pages.h:94 func:iommu_= alloc_pages_node > 0 0 drivers/iommu/intel/../iommu-pages.h:94 func:iommu_= alloc_pages_node > 0 0 drivers/iommu/intel/../iommu-pages.h:94 func:iommu_= alloc_pages_node > 0 0 drivers/iommu/intel/../iommu-pages.h:94 func:iommu_= alloc_pages_node > 0 0 drivers/iommu/intel/../iommu-pages.h:94 func:iommu_= alloc_pages_node > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0 0 fs/binfmt_elf.c:1395 func:load_elf_library > 0 0 fs/binfmt_elf.c:1395 func:load_elf_library > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0 0 fs/binfmt_elf.c:1653 func:fill_files_note > 0 0 fs/binfmt_elf.c:1653 func:fill_files_note > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0 0 fs/binfmt_elf.c:1851 func:fill_note_info > 0 0 fs/binfmt_elf.c:1851 func:fill_note_info > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0 0 fs/binfmt_elf.c:1891 func:fill_note_info > 0 0 fs/binfmt_elf.c:1891 func:fill_note_info > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0 0 fs/binfmt_elf.c:1899 func:fill_note_info > 0 0 fs/binfmt_elf.c:1899 func:fill_note_info > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0 0 fs/binfmt_elf.c:2057 func:elf_core_dump > 0 0 fs/binfmt_elf.c:2057 func:elf_core_dump > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0 0 fs/binfmt_elf.c:2072 func:elf_core_dump > 0 0 fs/binfmt_elf.c:2072 func:elf_core_dump > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0 0 fs/binfmt_elf.c:532 func:load_elf_phdrs > 0 0 fs/binfmt_elf.c:532 func:load_elf_phdrs > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0 0 fs/binfmt_elf.c:885 func:load_elf_binary > 0 0 fs/binfmt_elf.c:885 func:load_elf_binary > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0 0 fs/binfmt_elf.c:910 func:load_elf_binary > 0 0 fs/binfmt_elf.c:910 func:load_elf_binary > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0 0 fs/fuse/fuse_i.h:1082 [fuse] func:fuse_folios_alloc > 0 0 fs/fuse/fuse_i.h:1082 [fuse] func:fuse_folios_alloc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0 0 io_uring/io_uring.h:253 func:io_uring_alloc_async_d= ata > 0 0 io_uring/io_uring.h:253 func:io_uring_alloc_async_d= ata > 0 0 io_uring/io_uring.h:253 func:io_uring_alloc_async_d= ata > 0 0 io_uring/io_uring.h:253 func:io_uring_alloc_async_d= ata > 0 0 io_uring/io_uring.h:253 func:io_uring_alloc_async_d= ata > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0 0 kernel/sched/sched.h:2587 func:alloc_user_cpus_ptr > 0 0 kernel/sched/sched.h:2587 func:alloc_user_cpus_ptr > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0 0 mm/mm_slot.h:28 func:mm_slot_alloc > 160 4 mm/mm_slot.h:28 func:mm_slot_alloc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0 0 security/apparmor/domain.c:1136 func:change_hat > 0 0 security/apparmor/domain.c:1136 func:change_hat > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0 0 security/apparmor/domain.c:1455 func:aa_change_prof= ile > 0 0 security/apparmor/domain.c:1455 func:aa_change_prof= ile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0 0 security/apparmor/domain.c:835 func:handle_onexec > 0 0 security/apparmor/domain.c:835 func:handle_onexec > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0 0 security/apparmor/domain.c:909 func:apparmor_bprm_c= reds_for_exec > 0 0 security/apparmor/domain.c:909 func:apparmor_bprm_c= reds_for_exec > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 0 0 security/apparmor/mount.c:738 func:aa_pivotroot > 0 0 security/apparmor/mount.c:738 func:aa_pivotroot > > > > My workstation have my own changes based on 6.15-rc5, but I didn't touch = any code about tags... > The KVM runs 6.15-rc5. > > The script for checking: > > #!/bin/env python > def fetch(): > r =3D {} > with open("/proc/allocinfo") as f: > for l in f: > f =3D l.strip().split()[2] > if f not in r: r[f]=3D[] > r[f].append(l) > keys =3D [] > for f, ls in r.items(): > if len(ls) > 1: keys.append(f) > keys.sort() > for f in keys: > print "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D" > for l in r[f]: print l, > > fetch() > > > > > > David > > > >>