Re: [EXTERNAL] Re: [PATCH 1/2] lib/dmadev: eliminate undefined behavior

[David Marchand <david.marchand@redhat.com>]

On Fri, Jan 24, 2025 at 12:13 PM David Marchand
<david.marchand@redhat.com> wrote:
>
> On Tue, Dec 10, 2024 at 1:58 AM fengchengwen <fengchengwen@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.marchand@redhat.com/


Thanks!

-- 
David Marchand