Hi Steve,
On 20/11/24 07:06, Jean-Michel Hautbois wrote:
You reference two variables that are not part of the event:
"mem_map" and "m68k_memory[0].addr"
Do these variables ever change? Because the TP_printk() part of the
TRACE_EVENT() macro is called a long time after the event is
recorded. It
could be seconds, minutes, days or even months (and unlikely possibly
years) later.
I am really not the best placed to answer.
AFAIK, it sounds like those are never changing.
m68k_memory[0].addr never changes (that segment is usually where the
kernel is loaded to, and can't be hotplugged).
mem_map is equal to NODE_DATA(0)->node_mem_map on m68k
(mm/mm_init.c:__init alloc_node_mem_map()) and won't change either.
Cheers,
Michael
The event takes place and runs the TP_fast_assign() to record the
event in
the ring buffer. Then some time later, when you read the "trace"
file, the
TP_printk() portion gets run. If you wait months before reading that,
it is
executed months later.
Now you have "mem_map" and "m68k_memory[0].addr" in that output that
gets
run months after the fact. Are they constant throughout the boot?
I don't know.
Now another issue is that user space has no idea what those values
are. Now
user space can not print the values. Currently the code crashes
because you
are the first one to reference a global value from a trace event
print fmt.
That should probably be fixed to simply fail to parse the event and
ignore
the print format logic (which defaults to just printing the raw fields).
The patch you sent works...
But, it fails a bit later:
Dispatching timerlat u procs
starting loop
User-space timerlat pid 230 on cpu 0
Segmentation fault
-- Steve
