On 2/28/2023 11:29 AM, David Marchand wrote:
> On Tue, Feb 28, 2023 at 12:05 PM Ferruh Yigit <ferruh.yi...@amd.com> wrote:
>>
>> On 2/23/2023 12:30 PM, Ankur Dwivedi wrote:
>>> The speed_fec_capa pointer can be null. So dereferencing the pointer is
>>> removed and only the pointer is captured in trace function.
>>> Fixed few more trace functions in which null pointer can be dereferenced.
>>>
>>> Coverity issue: 383238
>>> Bugzilla ID: 1162
>>> Fixes: 6679cf21d608 ("ethdev: add trace points")
>>> Fixes: ed04fd4072e9 ("ethdev: add trace points for flow")
>>>
>>> Signed-off-by: Ankur Dwivedi <adwiv...@marvell.com>
>>
>> Hi Ankur,
>>
>> There is another bug report: https://bugs.dpdk.org/show_bug.cgi?id=1167
>>
>>
>> As far as I can see that is caused by '__rte_trace_point_register()' is
>> calling 'register_fn()' [1].
>>
>> At registering trace point stage, most of the pointers can be invalid,
>> and this can crash other locations too.
>
> I remember hitting this issue when running with UBsan.
>
>>
>> Why 'register_fn()' called withing the trace point register? Can we
>> remove it?
>
> IIRC, this is used to evaluate the size of the trace point event.
>
>
Yes, as checked with Jerin, it is used to evaluate size and some sanity
checks fro size.
We need either find a way to calculate size without really reading the
pointer content during register phase, all convert all pointer tracing
to emit_ptr().
I prefer first option if we can.
