From: Petr Pavlu <petr.pavlu@suse.com>
To: Casey Chen <cachen@purestorage.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-modules@vger.kernel.org,
linux-arch@vger.kernel.org, surenb@google.com,
kent.overstreet@linux.dev, arnd@arndb.de, mcgrof@kernel.org,
pasha.tatashin@soleen.com, yzhong@purestorage.com
Subject: Re: [PATCH] alloc_tag: remove empty module tag section
Date: Tue, 17 Jun 2025 11:27:39 +0200 [thread overview]
Message-ID: <2cd3947a-63d9-4a79-a24a-eb1ae8164169@suse.com> (raw)
In-Reply-To: <20250610162258.324645-1-cachen@purestorage.com>
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?
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/
--
Thanks,
Petr
next prev parent reply other threads:[~2025-06-17 9:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-10 16:22 Casey Chen
2025-06-17 9:27 ` Petr Pavlu [this message]
2025-06-17 15:05 ` Suren Baghdasaryan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2cd3947a-63d9-4a79-a24a-eb1ae8164169@suse.com \
--to=petr.pavlu@suse.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=cachen@purestorage.com \
--cc=kent.overstreet@linux.dev \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-modules@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=pasha.tatashin@soleen.com \
--cc=surenb@google.com \
--cc=yzhong@purestorage.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox