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 72F18C71136 for ; Tue, 17 Jun 2025 15:05:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 156C16B0098; Tue, 17 Jun 2025 11:05:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 12EC56B0099; Tue, 17 Jun 2025 11:05:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 06BEF6B009A; Tue, 17 Jun 2025 11:05:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E4D296B0098 for ; Tue, 17 Jun 2025 11:05:37 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 68336B98DE for ; Tue, 17 Jun 2025 15:05:37 +0000 (UTC) X-FDA: 83565216714.22.51B1035 Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) by imf15.hostedemail.com (Postfix) with ESMTP id 5F30DA001B for ; Tue, 17 Jun 2025 15:05:35 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="GMk79u/O"; spf=pass (imf15.hostedemail.com: domain of surenb@google.com designates 209.85.208.53 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=1750172735; 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=xdDBWUy9j2pqUSBQx3kBN47BSA5JF5clYU2Pq1utjBw=; b=CZXX/uaJ90BtX3//Q8PNZqDT6KFCVZItQ/V4o0o0Qf9GIL6y4LLvEDXAUOzGYO00S46AHg ZXhEbT4aXIJS/qXY7g5gnnchH/faEuazf56dIJsOBg3+l8vkhIF/jTvHr0+qP2ZDEh6Sy2 HCMVDRBltmrZ3VlKcHYXnA2v4VwvhGk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750172735; a=rsa-sha256; cv=none; b=CnPgy3X1FQ3YbGQvcH2rk2WV8rdi6yjKHW8TVitG3THjcLkfPCMeBNGfvf9AkGYoqW+95I ldE/cLFVJDmhU8n7oPRgwpbrmK42UnZ+xSP9r34KvCZBxn4PIAqhKog+l9o36CtJBn6ooh V6qSBvKeO7HuJmIunU/PJy/oVRxrcYM= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="GMk79u/O"; spf=pass (imf15.hostedemail.com: domain of surenb@google.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-609b169834cso5178a12.0 for ; Tue, 17 Jun 2025 08:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1750172734; x=1750777534; 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=xdDBWUy9j2pqUSBQx3kBN47BSA5JF5clYU2Pq1utjBw=; b=GMk79u/O+sFzg94+lnAKPPHoFLSXPux6J/+j2MReiqOETFpWjnO3dt21exadITM4W7 B7A3LQOhewixu6e8aTgAn2ETMwx3aFvrGWRPaVZo5JprQ2IlW6NBeeAoBzFpB+mcXxuP Jkfk3BYLjhvuayeTzGPEI7APY+JTj5pulrBRGE6dsCVvFIq3gtnPZp15w/ujf3sYEupE hdfiXswxbmiFCa8StGqO3armo4iMgKfFbI5f6QwzW18l0LT3BGWPzinNnWSoH5IEUZ4t R3Aev/cswxFj0Vqdv+e0lg6pfYa+T23zSAOp0nIGyJT+rm8V6HnUeQfaMHTuBLPRIMHU z7Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750172734; x=1750777534; 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=xdDBWUy9j2pqUSBQx3kBN47BSA5JF5clYU2Pq1utjBw=; b=hQ9eoQ/qnC0nZZJXPTIg/fB7bTPuqyqTrROfAXf/oUg88JQsbaRQdEWRtqNOizRcOh pX1py0PWSjm4sXax5kD/rRALXE8trnjgUtzNwQpn5CsklLOKASWnok2rkgUbl7RyG8hu qSCAUvJRRb71TFLFuv8+UV2L8Kv63BYd3fI0i7M3KggpXzEx20VhBhPlggbsn/60gobi r5eMvTs6xAyHJ7GyhDHvwrUjuQ4Gq2CvT1MsDirDxDbFzYwhgrJk03mSu+ersaHvdMef Z5I42d3y7kKpws5+WiKtRp2TahbIQpd1lFF3kQw8hTWHck79G14lzC3zFUojdk+xWMqS n+bQ== X-Forwarded-Encrypted: i=1; AJvYcCVdTU43reFoZGeJq+ZZImguWdL6xB4fYPhKNJNyCiXG/GFmqMFOwWYdfDkGPpsMQLcBMJdZ2fmiAQ==@kvack.org X-Gm-Message-State: AOJu0YymD2frjxKJmenXSJVXDTi9Xg9IW53glcJSR2KkdGtRRj16lD2M cYnvxE3kNKtQJlQRgNWKcURIZc/a69bcn1vOkPEZxGDDyeGD1LvqTD7PU3NAcBEen0K/LCeP+cM zZORBTceO65ccEBt9lwUNw9aJPCQb3tGj9LUiB5LH X-Gm-Gg: ASbGncsgCof0xhNezZO3t52PZkLMc6laF4Z33yJPtt3+sY6M8AzrAEsv6svXKsQ35Sw TKQvpaxHiJU3hLzxR2kUaj+RXERo1Jj1nMz4SvLnk/ggEAMbsOsgrYJEhVyiczQXvDNbhgTYVev FPL3eNkLkH+8zbMYsscu2ZCPle5BzlfB5DlzKWmf95RZdW/WOEqBlFctpGkdBnNH+VK3PUgfLAf Q== X-Google-Smtp-Source: AGHT+IGRa+ebswKWFvguxlBNnkaQydcOCTcdUc1tpDY2GOdw3o8/6AoW8HLi2nmZXoRCM54Zx9JT9odQlOQ7f8488xU= X-Received: by 2002:a05:6402:1298:b0:608:fb55:bf12 with SMTP id 4fb4d7f45d1cf-608fb55cf20mr248560a12.4.1750172730198; Tue, 17 Jun 2025 08:05:30 -0700 (PDT) MIME-Version: 1.0 References: <20250610162258.324645-1-cachen@purestorage.com> <2cd3947a-63d9-4a79-a24a-eb1ae8164169@suse.com> In-Reply-To: <2cd3947a-63d9-4a79-a24a-eb1ae8164169@suse.com> From: Suren Baghdasaryan Date: Tue, 17 Jun 2025 08:05:16 -0700 X-Gm-Features: AX0GCFtqkKIf4xqb1bUZ_2PHwjODhV30fsR1AexyTYrzdWW3sQdis91nCJ5F--0 Message-ID: Subject: Re: [PATCH] alloc_tag: remove empty module tag section To: Petr Pavlu Cc: Casey Chen , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-modules@vger.kernel.org, linux-arch@vger.kernel.org, kent.overstreet@linux.dev, arnd@arndb.de, mcgrof@kernel.org, pasha.tatashin@soleen.com, yzhong@purestorage.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 5F30DA001B X-Stat-Signature: ybmrcrj6p3tcuskr3wrars84fkw8u7tn X-Rspam-User: X-HE-Tag: 1750172735-323100 X-HE-Meta: U2FsdGVkX19vtzcl0YYgpqxNu4fH4bwfLh3KZRHsgtYN7Fce3dwm/6CdGeyewF1r/KZpnVGnhec18ma1RwE83ppG1QwvOzN1vJDEkI994N800AHfL/luE/+tlrH1YO7Hx9rSdiW+XgWclNtikOHeviFO24XgApOvmfWahiS6nyS7bNwRLqwJFou9yauphBpnu0S+jTCp2l0+MFgHxj+SqgTpp97xx7Y/Rnu7PJJsHvYbX15kOLv23wR72b632p4DRHOxNrutpvXf1uKCETD8ufenagWceK7VmxRXq1Qsy0r7w5n9unk8907va9N3lXv5TgJrnlomAzfsc8XM1vjs56dog9tbVnK8IrAPeZh5nmw6XwXdNtGlqr0xzIruBevJg8axDCy7qDzUdi7aYhTZ9AJ0CXhdobROiscc75ls9GudvbWM/mhY6YI1Z8WcKUliXhhcMTBpfWXrqk9GWA5r2smptv7hHYDf0XYnOAU9MuegwNS4u64KpkCPmcb6+74JJdBur1ait8hhgRwvy37dpte/bVQuKGwMiLvsLftXEfCE3c9w1Sarkff//2/wsHAemxMc+5sUz+PGs/Q9zggf0D4X7DKjVONJlTMrot7n1glEiXDWuxdttsOBGK4ePEq8yoBryb1eelcoIOddLboW9RCdDvmMf5T+olbsjh2t+50yIAl1+vTJelp+ZuOBHG28g/8d3iKaq6wMelAnjcaPXWQpcNFuHRjWYn14dfIzsySx5B1IrNrSrvTUxwdYfDaTdRxuqTRbyTpycB4TrA9FokzNs18meACZSLTXdkcBblaRFqTtHmPx1WK+e8ShorC8T92f5O6DjFTo6C+NEF/vJKAOFI2s6ikCIDWeeVk/Cb8QAM7ZdUUP3VYuC1g/72BBFW/e9M+8LsU/yvFCLHSkTRwi42bjjCixVSUX/rMBgwUtL4D38XUY1J/vCEcF92ytZZtYm29X2OHrqSz57iZ KmVdCB/g kXlB+Qm1z484MLgdPbo2L7o027MrWHSHHXsnBd/1rp5ec0l0/P0WPrmOdPSAuRyJhb4DYqXIfTj/DBQQ0gv0n8r96tGMR7egqxwNPs3HLLfQvtc/Giz6vJ4XhgT/Q1a65xHOaxQ3jVy9F6BE2x380fRaQhVejbogSpntQmZjpzYs3R2+m32RaBUp6W5/RPkeO36N+CieXz10WXiFWlgpfg8c3XXdptOVCr4BZWdrxXosl7sU+N7xAyVqn2aSl1cp0pSjYU2PbrhAkIUxk7HugdTjXFO4/13l8IcpXE5yBrtZL+EaMXpwe0coR26mk9+fVOHSijEqBv5Fi+Rw= 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 17, 2025 at 2:27=E2=80=AFAM Petr Pavlu wr= ote: > > On 6/10/25 6:22 PM, 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. > > The patch looks ok me, but I'm somewhat confused about the problem. > I think a linker should not add an empty output section if it doesn't > contain anything, or if .data actually contains something then the extra > dummy definition should be also harmless? I also assumed so but apparently this is not entirely harmless. > > This also reminds me of my previous related fix "codetag: Avoid unused > alloc_tags sections/symbols" [1] which fell through the cracks. I can > rebase it on top of this patch. > > [1] https://lore.kernel.org/all/20250313143002.9118-1-petr.pavlu@suse.com= / Yes please. > > -- > Thanks, > Petr