On Thu, 6 Feb 2025 12:18:20 -0500
Steven Rostedt [off-list ref] wrote:

On Fri, 7 Feb 2025 01:53:30 +0900
Masami Hiramatsu (Google) [off-list ref] wrote:

quoted

On Thu, 6 Feb 2025 10:36:12 -0500
Steven Rostedt [off-list ref] wrote:

quoted

On Thu, 6 Feb 2025 19:01:24 +0900
Masami Hiramatsu (Google) [off-list ref] wrote:
  

quoted

quoted

+static void trace_module_record(struct module *mod)
+{
+	struct trace_array *tr;
+
+	list_for_each_entry(tr, &ftrace_trace_arrays, list) {
+		/* Update any persistent trace array that has already been started */
+		if ((tr->flags & (TRACE_ARRAY_FL_BOOT | TRACE_ARRAY_FL_LAST_BOOT)) ==
+		    TRACE_ARRAY_FL_BOOT) {
+			/* Only update if the trace array is active */
+			if (trace_array_active(tr))    

Do we really need this check? It seems that we can just save_mod() if the
above condition is true.  

It gets a little more  complicated if we need to add and remove modules.  

Yeah, but for converting the module address, we don't want to see other
module information.

But we want to see the module information for modules that were loaded
during the trace. If a module is removed and suddenly the system crashed,
we just lost that information. Hence why I reset the module information
when the tracing starts.

Then, what about removing module info if the address is recycled for
new module? We can keep it until the same address range is used by other
module(s).

quoted

quoted

If we want to have events for modules that were removed. Note, the ring
buffer is cleared if any module event was ever enabled and then the module
is removed, as how to print it is removed too. But we could disable that
for the persistent ring buffers as they should not be using the default
trace event print format anyway.  

Yeah, if the event is on the module the buffer is cleared.
But the module address can be in the stacktrace. In that case, the event
in the module is not enabled, but other events like sched_switch can
take stacktrace which can include the module address. In that case, the
buffer is also cleared when the module is removed?

No. The buffer is only cleared if one of its events were ever enabled. If
no event within the module was enabled, then the buffer is not cleared.

quoted

quoted

As for stack traces, we still want the module it was for when the stack
trace happens. A common bug we see is when a module is removed, it can
cause other bugs. We want to know about modules that were removed. Keeping
that information about removed modules will allow us to see what functions
were called by a stack trace for a module that was removed.  

Hmm, but that should be covered by module load/unload events?

If we have them enabled.

Yes, and current module load event does not cover the address. I think
we can add a new event to log it.

Thank you,

-- Steve

-- 
Masami Hiramatsu (Google) [off-list ref]