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 1E480C61CE8 for ; Mon, 9 Jun 2025 22:56:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 453076B0088; Mon, 9 Jun 2025 18:56:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 401456B0089; Mon, 9 Jun 2025 18:56:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 316EC6B008A; Mon, 9 Jun 2025 18:56:03 -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 11FBE6B0088 for ; Mon, 9 Jun 2025 18:56:03 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 8A506B7D5D for ; Mon, 9 Jun 2025 22:56:02 +0000 (UTC) X-FDA: 83537371764.29.431B3CB Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) by imf29.hostedemail.com (Postfix) with ESMTP id B2BAB120002 for ; Mon, 9 Jun 2025 22:56:00 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=xvDEZVv7; spf=pass (imf29.hostedemail.com: domain of surenb@google.com designates 209.85.160.175 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=1749509760; 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=ihMIZFEayy7GV8s7zAcF/jQzclWrV8pozW3srSlXZUw=; b=WgacisH5lZrL/MhGlcNqMbKd3gwYh9IiAvmX1sKeKjXPIMj7U+a2djZqZs1v+aV8bzAY8T 2rLscU+8+opXO9nhDjgaFNKEYJFAXSK0SoYtT4QkvJ0SUA9wMyqDwTivjIr1FDbcGKPiHw DQHHa+lFpx5/WrsKf5P6cTuQm1/v1b0= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=xvDEZVv7; spf=pass (imf29.hostedemail.com: domain of surenb@google.com designates 209.85.160.175 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749509760; a=rsa-sha256; cv=none; b=weA3XlADLe190V/DYEGG15QJL2Tj53ZFLWMpisO1cmsKtZpF5x/ORQZDNc2bNd6dw4s+ue a2myIMgWKaMJzd4uzpOls9PGMyQTn2aPSYndRQv3GSaTLFZp2lBH2Iu4fL9KJp8qPHcqj9 9C7LCUxd/f3ClYtCxQHAX0+qwZ7C7g0= Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-4a58ef58a38so31911cf.0 for ; Mon, 09 Jun 2025 15:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1749509760; x=1750114560; 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=ihMIZFEayy7GV8s7zAcF/jQzclWrV8pozW3srSlXZUw=; b=xvDEZVv7NekKDOrdD6zlslXEECv8VN+V3gddaILiTMBw+RlwMu+u739+d6DZAKK8sf hJXynGokmt+/+0iA6aZ5FkYj9pMMY40VQwZWWbb8cv2Grd4tvWn5Rhi6IclQKzahCJ7g lzUJrfjW6D5bBm6idrEbR3+EOnU8eKhF5f6Mn+TtTAJXxGQDugNjoSITc3DGg6+PBBHD a587JrBR+KIr0IFkYy1l1xGHmf4jikasF83Um5PiBFRtHOt7wt46WYeCXPdQsI6UB5k5 mz/gzr1GJ7TDeNdPSAFqc3w8JG/7Rr79aze8jMlYk/yk+LaLwnDUFJqatYFDxwEowHi6 CqQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749509760; x=1750114560; 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=ihMIZFEayy7GV8s7zAcF/jQzclWrV8pozW3srSlXZUw=; b=bfeWUew7in+ioM6GjWvR3tjsZ7hfK3E7NlkC3A1bLOzk5xwvxE4zXCyTtEYiYcdj21 wq//EJmAGbnpxq3PkfBi9Qcbaz25qZVjGg60n2XOvfxfFiG8lfuL/nOK9L2YCT+lmXhM BfxiIGM/s+gerYzZFtFsaXpCwaSZTZxgztGDPu37I8WVeIOzIGcwqM3smJvRKtFy1+1C mlL6mllHPf1fOticUx4A8oAsD+BAuwv5hO5UAsA76yuBi7aAalUuOPlyiz4IRGYD43A1 lgOltoWUCFmCAJjO7+o0pfrRJGB3y8pCDme7lBkqC2z0I3RJJ7KKpVcJAFi1DwLry1Mj zXJg== X-Gm-Message-State: AOJu0Yxbomr33QDWZToABeEsSxED5CGobUgh1PGJCFxDkkSTrEDZD1LW IW6a4CVYbvMsiQvpsKhC6FtgJ8RnTU/B3Q9bcKuVFM7aHMt7JNtD+ydyQ4tfBB6X0D4uRMv5epE opty/9PC00vhySZeaAvxv84xI3R3nY78AIDVXEgp9 X-Gm-Gg: ASbGncs9ST6extU5qnmWaUmfnxr/IsAFZivS/9gcS8YhuPOZoOUa0B1+BYsCE27d0uZ Yr2eRD3GFAMHyNFGN6dLVJeO3z+vpZmyahBuhtFrY8YvooeyAOmUUbU+zHjFnSCqmeQQrIxz469 5eJOoBAmLZkv0vdvVKHEcrzhoWzrFo6KsqZ2OVWbKEig== X-Google-Smtp-Source: AGHT+IGWEGQOzHjO5OL9STbHHex5X7m/OPfc8ruMkgdFG2w6TCRDJEeN6/M3ivsJyHJnLIIeyOoCHI1Xv4p6QVRq99E= X-Received: by 2002:a05:622a:1811:b0:494:b641:4851 with SMTP id d75a77b69052e-4a6f072bd8fmr8746151cf.27.1749509759444; Mon, 09 Jun 2025 15:55:59 -0700 (PDT) MIME-Version: 1.0 References: <20250605190128.2287011-1-cachen@purestorage.com> <20250605190128.2287011-2-cachen@purestorage.com> In-Reply-To: From: Suren Baghdasaryan Date: Mon, 9 Jun 2025 15:55:48 -0700 X-Gm-Features: AX0GCFs9bmpX6qpwI25Q7xqVDYK6FtluR1yyB7mNWfaMdLWwS7SUmjpGzgBv2ug Message-ID: Subject: Re: [PATCH 1/1] alloc_tag: remove empty module tag section from linker script To: Casey Chen Cc: linux-mm@kvack.org, kent.overstreet@linux.dev, yzhong@purestorage.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: B2BAB120002 X-Stat-Signature: 9jrersfoaci1c5n7oi481apkd9te6ia7 X-Rspam-User: X-HE-Tag: 1749509760-29555 X-HE-Meta: U2FsdGVkX1/djk/S8vx9I0BDyjwEW2qQF9fbvbqufp8XsLgg6YwRq8vRXg6RXuf9Pg6x3YnqpVxfiNhRETLSRdRYlqBM4+zZ8r1ROYnHqLjT0MPNZP/LDNGaCcRG/zriE0PMw9gC1Gl6DvAxsYII1cMwNvYINdShB2Ylv07zIixaDE2Rzy0xwUV9lm8JH4dhkVaupSGHEMRNzpSvW+cf2+lAywC2MXvCZA0hX0kvkiKpGg+GovCjlNO58n3Cl8bTZ04WeauCY2mUP+BYJbgedu79eII75u84i4DDIpUM+AwKCSvrbW5e/HIluDgPCgJYfHLCPWRo4AQH7Ca8oIorfuWvnlCFRmXkWl+2Zg/Qduv8qA9IWtpSLSlX4ia+E3GDqXlub1rwy9mGCHbndtHIcd87ukPt0S8kjJAOITqAzaotLvF4OaL9963FfF3jEByz6cw6Z68QIHhyKN0x3xbHKvMgu3KVVJHxQusmfK32nKqX3R/AtKSLHUdSpjvQ8f2ZLj+Wo1JEcJEI+5q8hq8VzjWL6kkDeJr2gZH1BSZAo4uuX6AfKIOOwgY7JnjTLjXh7/nMuH1OU04ovylDGEeZTAV3uPayA/AFoygsKEBZUshH3g2lKgeJ00u7MTIW9RP66mVoFpGn+sP7AXp6voPdJ0KrwYa88S2vXNmIr9xHg/jPhZ6wqoBO/Dopt8GnSBG1VzQgd1bnM0brWhLoL3mtyTJLFA8eG+GByc8T/Bk7bdsGLCBYYOZmXCtrcMslSZ9byLb2enBkjfZBh/2uwBhPeBKnNA3ED2qZbHP966AyjNe9le8dKiBbgQfa/8p7C7gt/s8v+yDGROoEY3e+CVCW7WhqaufYOJGIkUpOakX4F7WS9Ztbgww8Cxu628QB0KIFsw5aLTtT22p/eki0DbzISP5rb0pSCqOT06gvaTPscnuiAtAfFomA4yUGeCUcUG/n/5wezBs5lwxYs9wsUy7 FQtE/39h TNeuCAV5XyeUBBFZZn9DknbComPiipGYcK4XQPVTna0Wy9e8r/53JxxA9aOkQbUbmP94o+pDlXAnbL/AP9iok4I17SGQTW+eBE5/7lXFJdXB9Q+GcNQEQeK869erGCxXqPoG2TYWOycBK+x0cm0fnIXbwxH//SJJfzFj/wQchIpKbwunBNz632FwtM7fQtKcPTVh48KIGgoPZDsbgA8xYL2Sw03opRG/9SMsI2RNUx+IlgM94sdSQMRIXBhl17gUtXd+fa89YZVEywZCavsPx9jbPl+21HrnpBGoHhXAZ/YRlkVtd3QlwV0vsjeDTJh59N25oEu2uzWs1LGqZalZ2V/OdGLfYtwI9F26anNtywDsnoSk7jlgNJkKod4jaRpMYiAk7 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 Mon, Jun 9, 2025 at 2:15=E2=80=AFPM Casey Chen = wrote: > > On Thu, Jun 5, 2025 at 1:07=E2=80=AFPM Suren Baghdasaryan wrote: > > > > On Thu, Jun 5, 2025 at 12:01=E2=80=AFPM Casey Chen wrote: > > > > > > The empty MOD_CODETAG_SECTIONS() macro added an incomplete .data > > > section in module linker script, which caused symbol lookup tools > > > like gdb to misinterpret symbol addresses e.g., __ib_process_cq > > > incorrectly mapping to unrelated functions like below. > > > > > > (gdb) disas __ib_process_cq > > > Dump of assembler code for function trace_event_fields_cq_schedule: > > > > > > Removing the empty section restores proper symbol resolution and > > > layout, ensuring .data placement behaves as expected. > > > > Hmm. I'm not sure why an empty .data section would cause such an > > issue. Is that expected behavior? > > > > I'm not sure that's why I am posting this to ask for ideas. It looks > like gdb failed to disassemble function. > > > To clarify, codetags are designed to support different types of tags, > > not only allocation tags which we currently use. It so happens that > > allocation tags can be still used after module unload, therefore they > > are placed into MOD_SEPARATE_CODETAG_SECTIONS(). If some other tags > > are added in the future and their lifecycle is the same as modules > > (IOW after module unload they can be unloaded too), then they would be > > added into MOD_CODETAG_SECTIONS() but until then this section is > > empty. > > > > Could we remove the empty data section with MOD_CODETAG_SECTIONS() for > now until we really need it ? Ok, I see no issue with removing it but please remove its definition from codetag.lds.h as well. Whenever sending mm related patches (including alloc_tag ones) please send them to akpm@linux-foundation.org and CC everyone else. Andrew is the mm tree maintainer and that's the usual way to post MM changes. Thanks, Suren. > > > > > > Fixes: 22d407b164ff ("lib: add allocation tagging support for memory = allocation profiling") > > > Signed-off-by: Casey Chen > > > Reviewed-by: Yuanyuan Zhong > > > --- > > > scripts/module.lds.S | 5 ----- > > > 1 file changed, 5 deletions(-) > > > > > > diff --git a/scripts/module.lds.S b/scripts/module.lds.S > > > index 711c6e029936..c071ca4beedd 100644 > > > --- a/scripts/module.lds.S > > > +++ b/scripts/module.lds.S > > > @@ -50,17 +50,12 @@ SECTIONS { > > > .data : { > > > *(.data .data.[0-9a-zA-Z_]*) > > > *(.data..L*) > > > - MOD_CODETAG_SECTIONS() > > > } > > > > > > .rodata : { > > > *(.rodata .rodata.[0-9a-zA-Z_]*) > > > *(.rodata..L*) > > > } > > > -#else > > > - .data : { > > > - MOD_CODETAG_SECTIONS() > > > - } > > > #endif > > > MOD_SEPARATE_CODETAG_SECTIONS() > > > } > > > -- > > > 2.34.1 > > >