Hi David, I will look into this at earliest and provide feedback.
Thanks From: David Marchand <[email protected]> Sent: Friday, February 7, 2025 2:20 PM To: Jerin Jacob <[email protected]>; Sunil Kumar Kori <[email protected]> Cc: [email protected]; Chengwen Feng <[email protected]>; Kevin Laatz <[email protected]>; Bruce Richardson <[email protected]>; Tyler Retzlaff <[email protected]>; Andre Muezerie <[email protected]>; Thomas Monjalon <[email protected]>; Stephen Hemminger <[email protected]> Subject: [EXTERNAL] Re: [PATCH v2 3/3] trace: fix undefined behavior in register Hello Jerin, Sunil, On Thu, Jan 30, 2025 at 3: 59 PM David Marchand <david. marchand@ redhat. com> wrote: > > Registering a tracepoint handler was resulting so far in undefined > behavior at runtime. > > The RTE_TRACE_POINT_REGISTER() Hello Jerin, Sunil, On Thu, Jan 30, 2025 at 3:59 PM David Marchand <[email protected]<mailto:[email protected]>> wrote: > > Registering a tracepoint handler was resulting so far in undefined > behavior at runtime. > > The RTE_TRACE_POINT_REGISTER() macro was casting the tracepoint handler > (which expects arguments) to a void (*)(void). > At runtime, calling this handler while registering resulted in > reading the current stack with no relation to this function prototype. > > Instead, declare an additional inline _register() handler for each > tracepoint and make sure that the emitting macros in > rte_trace_point_register.h only work on arguments name and type. > > The original tracepoint handler prototype is adjusted by adding a > __rte_unused for each argument (since emitting macros do nothing > with them). > This last part introduces an implementation limit of 15 arguments. > > With this change in place, the workaround in dmadev tracepoints can be > removed. > > Signed-off-by: David Marchand > <[email protected]<mailto:[email protected]>> Can I have your opinion and review on this patch? Thanks. -- David Marchand
