tracing: Introduce relative stacktrace#53
Closed
modules-kpd-app[bot] wants to merge 2 commits intomodules-next_basefrom
Closed
tracing: Introduce relative stacktrace#53modules-kpd-app[bot] wants to merge 2 commits intomodules-next_basefrom
modules-kpd-app[bot] wants to merge 2 commits intomodules-next_basefrom
Conversation
Author
|
Upstream branch: f3b9354 |
modules-kpd-app
bot
force-pushed
the
modules-next_base
branch
from
0f0b06f to
0893b23
Compare
Author
|
Upstream branch: 48ecfdd |
modules-kpd-app
bot
force-pushed
the
series/928865=>modules-next
branch
from
545ae9f to
8c04f91
Compare
Author
|
Upstream branch: 48ecfdd |
modules-kpd-app
bot
force-pushed
the
series/928865=>modules-next
branch
from
8c04f91 to
0f87b48
Compare
modules-kpd-app
bot
force-pushed
the
modules-next_base
branch
from
0893b23 to
95973fc
Compare
Author
|
Upstream branch: 053842e |
modules-kpd-app
bot
force-pushed
the
series/928865=>modules-next
branch
from
0f87b48 to
e8473a8
Compare
modules-kpd-app
bot
force-pushed
the
modules-next_base
branch
from
95973fc to
b5b7508
Compare
Add __module_build_id() to find module by build_id. This also makes module::build_id available with CONFIG_MODULE_BUILD_ID kconfig. Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Add "relative-stacktrace" option to save the stacktrace entries as offset from the _stext or module's text section. For the module address, each entry also saves the first 4bytes of the build_id of the module so that it can find the appropriate symbol from the offset. By using this build_id, we can also easily find the corresponding modules off-line. Thus this stacktrace data is in the persistent ring buffer, the kernel can find appropriate modules after reboot without saving previous live information. This feature also shows the module name after the symbol as below. event-sample-1622 [005] ...1. 2112.978105: <stack trace> => event_triggers_post_call => trace_event_raw_event_foo_bar [trace_events_sample] => do_simple_thread_func [trace_events_sample] => simple_thread [trace_events_sample] => kthread => ret_from_fork => ret_from_fork_asm The downside is the cost of time and memory (on 32bit arch). This needs to find the module if the address in the module, and save both of 32bit offset and 32bit hash for each entry, this may consume twice memory on 32bit arch. On 64bit arch, the amount of consuming memory is the same. Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Author
|
Upstream branch: afa9286 |
modules-kpd-app
bot
force-pushed
the
series/928865=>modules-next
branch
from
e8473a8 to
03b93b3
Compare
Author
|
At least one diff in series https://patchwork.kernel.org/project/linux-modules/list/?series=929666 irrelevant now. Closing PR. |
dagomez137
pushed a commit
that referenced
this pull request
Nov 17, 2025
The following lockdep splat was observed while kernel auto-online a CXL memory region: ====================================================== WARNING: possible circular locking dependency detected 6.17.0djtest+ #53 Tainted: G W ------------------------------------------------------ systemd-udevd/3334 is trying to acquire lock: ffffffff90346188 (hmem_resource_lock){+.+.}-{4:4}, at: hmem_register_resource+0x31/0x50 but task is already holding lock: ffffffff90338890 ((node_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x2e/0x70 which lock already depends on the new lock. [..] Chain exists of: hmem_resource_lock --> mem_hotplug_lock --> (node_chain).rwsem Possible unsafe locking scenario: CPU0 CPU1 ---- ---- rlock((node_chain).rwsem); lock(mem_hotplug_lock); lock((node_chain).rwsem); lock(hmem_resource_lock); The lock ordering can cause potential deadlock. There are instances where hmem_resource_lock is taken after (node_chain).rwsem, and vice versa. Split out the target update section of hmat_register_target() so that hmat_callback() only envokes that section instead of attempt to register hmem devices that it does not need to. [ dj: Fix up comment to be closer to 80cols. (Jonathan) ] Fixes: cf8741a ("ACPI: NUMA: HMAT: Register "soft reserved" memory as an "hmem" device") Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Tested-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com> Reviewed-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Link: https://patch.msgid.link/20251105235115.85062-3-dave.jiang@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull request for series with
subject: tracing: Introduce relative stacktrace
version: 1
url: https://patchwork.kernel.org/project/linux-modules/list/?series=928865