On Fri, Jan 24, 2025 at 12:13 PM David Marchand
<david.march...@redhat.com> wrote:
>
> 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.
Fengcheng, Jerin, André, could you please have a look at this patch:
https://patchwork.dpdk.org/project/dpdk/patch/20250130145849.82003-3-david.march...@redhat.com/
Thanks!
--
David Marchand
