On Tue, 19 Nov 2024 19:06:45 +0100 Jean-Michel Hautbois <[email protected]> wrote: > > > > It shouldn't crash, but it also found a bug in your code ;-) > > In my code is a really big assumption :-).
Well, not your personally, but I meant "your" as in m68k code. > > > 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. That would mean they are OK and will not corrupt the trace, but it will be meaningless for tools like perf and trace-cmd. > > > > > 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 > More printk? ;-) -- Steve
