On Tue, Dec 10, 2024 at 1:58 AM fengchengwen <fengcheng...@huawei.com> wrote:
> > + @Chengwen Feng
> >
> > This kind of patten is not used other places like ethdev traces, Why we
> > need this kind of pattern in dmadev?
> > Looks like, it can be fixed by caller of this function by initializing
> > struct rte_dma_info. So may not need a fixup patch to begin with
>
> It's strange that no other library doesn't have this problem.
>
> When I first add tracepoints support for dmadev, there is no such macro (just
> like other library),
> but the CI report ASAN error.
>
> The rootcause is that register:
> RTE_TRACE_POINT_REGISTER(rte_dma_trace_info_get,
> lib.dmadev.info_get)
> it will invoke :
> __rte_trace_point_register(&__rte_dma_trace_info_get,
> __rte_dma_trace_info_get_lib.dmadev.info_get,
> (void (*)(void)rte_dma_trace_info_get) {
> rte_dma_trace_info_get();
> }
>
> But rte_dma_trace_info_get() it was defined with parameters: int16_t dev_id,
> struct rte_dma_info *dev_info
> If we force invoke rte_dma_trace_info_get() without pass any parameter, it
> may lead to ASAN problem because
> the parameter's corresponding register was not set (and it's value undefine).
I remember of an issue with tracepoint and *UB*SAN, but I fail to see
how ASAN is affected (plus I see that the CI runs the tracepoint
autotests with ASAN).
Can you clarify?
In any case, this looks like something that should be handled at the
tracepoint framework level, and not silenced/wrapped around in the
dmadev library.
--
David Marchand
