From: Ferruh Yigit <ferruh.yigit@amd.com>
To: Jerin Jacob <jerinjacobk@gmail.com>
Cc: David Marchand <david.marchand@redhat.com>,
Ankur Dwivedi <adwivedi@marvell.com>,
dev@dpdk.org, Thomas Monjalon <thomas@monjalon.net>,
jerinj@marvell.com, Ali Alnubani <alialnu@nvidia.com>,
"Li, WeiyuanX" <weiyuanx.li@intel.com>
Subject: Re: [PATCH v1 1/2] ethdev: fix null pointer dereference
Date: Tue, 28 Feb 2023 13:39:25 +0000 [thread overview]
Message-ID: <2fddd022-f95e-aac3-8da5-3a3f6f064f55@amd.com> (raw)
In-Reply-To: <CALBAE1NNY78ZPQQOeyTver3D6R+JcVEmD+4GSkA45StWkPgjkw@mail.gmail.com>
On 2/28/2023 1:17 PM, Jerin Jacob wrote:
> On Tue, Feb 28, 2023 at 6:16 PM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
>>
>> On 2/28/2023 11:29 AM, David Marchand wrote:
>>> On Tue, Feb 28, 2023 at 12:05 PM Ferruh Yigit <ferruh.yigit@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 <adwivedi@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.
>
> Looking at the root of the issue.
>
> rte_trace_point_emit_* has two variant
> a)trace point version - Which will emit the trace
> b)trace register version - Which will find the size of trace
> automatically with single definition of trace point to make life easy
> for defining the trace point
>
> In this case, conf value is junk, as we are referencing the value at
> registration time. Looks like in PPC arch, the stack content comes as
> junk at this point and got this issue.
> And other arch or other environment that adders is OK and since we're
> just _reading_ the value. It is not making any issue. But it is a bug.
>
> RTE_TRACE_POINT was designed to just use
> rte_trace_point_emit_u16(conf->my_value) so that in registration scope
> "conf->my_value" will be omitted by compiler.
> But there as issue in using bitfiled[1] as trace is not supporting
> bitfield. Ankur added a local variable to work around the bitfiled
> tracing.
>
> So couple of options, I can think of
>
> 1)Remove the bitfiled trace point( There are only some trace point
> uses that, Just we need to remove bitfield items from that)
> 2)It is possible to have anonymous union of type like u16, u32 for
> tracing the the bitfields[2], but that would need change in public
> structure
> 3) Another option is to have a #define to define the scope of
> registration. Something like [3] which is noisy.
>
> I think, we can just do 1 now for rc2 and (2) or (3) or some other
> ideas we can think in next release.
>
+1 to go for option 1, specially at this phase of the release.
Only limited number of traces are affected by this bitfield related
issue anyway.
btw, this is for the Bug 1167,
I thought 1167 & 1162 share same root cause but they don't,
so 1162 is still open.
>
> [1]
> ../lib/ethdev/ethdev_trace.h: In function
> ‘rte_eth_trace_tx_hairpin_queue_setup’:
> ../lib/eal/include/rte_trace_point.h:378:21: error: cannot take
> address of bit-field ‘peer_count’
> 378 | memcpy(mem, &(in), sizeof(in)); \
> | ^
>
>
> [2]
> struct abc {
> union {
> uint32_t val;
> struct {
> val_5_bit:5
>
> }
> }
> }
>
> [3]
>
> [main]dell[dpdk.org] $ git diff
> diff --git a/lib/eal/include/rte_trace_point_register.h
> b/lib/eal/include/rte_trace_point_register.h
> index a9682d3f22..266350b29c 100644
> --- a/lib/eal/include/rte_trace_point_register.h
> +++ b/lib/eal/include/rte_trace_point_register.h
> @@ -16,6 +16,8 @@ extern "C" {
> #include <rte_per_lcore.h>
> #include <rte_trace_point.h>
>
> +#define RTE_TRACE_SCOPE_IS_REGISTRATION
> +
> RTE_DECLARE_PER_LCORE(volatile int, trace_point_sz);
>
> #define RTE_TRACE_POINT_REGISTER(trace, name) \
> diff --git a/lib/ethdev/ethdev_trace.h b/lib/ethdev/ethdev_trace.h
> index 53d1a71ff0..ba42c3d10a 100644
> --- a/lib/ethdev/ethdev_trace.h
> +++ b/lib/ethdev/ethdev_trace.h
> @@ -237,13 +237,23 @@ RTE_TRACE_POINT(
> RTE_TRACE_POINT_ARGS(uint16_t port_id, uint16_t rx_queue_id,
> uint16_t nb_rx_desc, const struct rte_eth_hairpin_conf *conf,
> int ret),
> - uint16_t peer_count = conf->peer_count;
> - uint8_t tx_explicit = conf->tx_explicit;
> - uint8_t manual_bind = conf->manual_bind;
> - uint8_t use_locked_device_memory = conf->use_locked_device_memory;
> - uint8_t use_rte_memory = conf->use_rte_memory;
> - uint8_t force_memory = conf->force_memory;
>
> + uint16_t peer_count;
> + uint8_t tx_explicit;
> + uint8_t manual_bind;
> + uint8_t use_locked_device_memory;
> + uint8_t use_rte_memory;
> + uint8_t force_memory;
> +#ifdef RTE_TRACE_SCOPE_IS_REGISTRATION
> + RTE_SET_USED(conf);
> +#else
> + peer_count = conf->peer_count;
> + tx_explicit = conf->tx_explicit;
> + manual_bind = conf->manual_bind;
> + use_locked_device_memory = conf->use_locked_device_memory;
> + use_rte_memory = conf->use_rte_memory;
> + force_memory = conf->force_memory;
> +#endif
> rte_trace_point_emit_u16(port_id);
> rte_trace_point_emit_u16(rx_queue_id);
> rte_trace_point_emit_u16(nb_rx_desc);
> [main]dell[dpdk.org] $
next prev parent reply other threads:[~2023-02-28 13:39 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-23 12:30 [PATCH v1 0/2] bug fix in ethdev trace Ankur Dwivedi
2023-02-23 12:30 ` [PATCH v1 1/2] ethdev: fix null pointer dereference Ankur Dwivedi
2023-02-28 11:04 ` Ferruh Yigit
2023-02-28 11:29 ` David Marchand
2023-02-28 12:46 ` Ferruh Yigit
2023-02-28 13:17 ` Jerin Jacob
2023-02-28 13:39 ` Ferruh Yigit [this message]
2023-02-28 15:01 ` Ferruh Yigit
2023-02-28 15:40 ` [EXT] " Ankur Dwivedi
2023-02-28 16:08 ` Ferruh Yigit
2023-02-28 16:27 ` Ferruh Yigit
2023-03-02 9:58 ` Ferruh Yigit
2023-03-02 16:49 ` Ankur Dwivedi
2023-02-23 12:30 ` [PATCH v1 2/2] ethdev: pass structure pointer Ankur Dwivedi
2023-02-28 15:01 ` Ferruh Yigit
2023-03-03 11:31 ` [PATCH v2 0/2] bug fix in ethdev trace Ankur Dwivedi
2023-03-03 11:31 ` [PATCH v2 1/2] ethdev: fix null pointer dereference Ankur Dwivedi
2023-03-03 13:38 ` Ferruh Yigit
2023-03-03 11:31 ` [PATCH v2 2/2] ethdev: pass structure pointer Ankur Dwivedi
2023-03-03 13:39 ` [PATCH v2 0/2] bug fix in ethdev trace Ferruh Yigit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2fddd022-f95e-aac3-8da5-3a3f6f064f55@amd.com \
--to=ferruh.yigit@amd.com \
--cc=adwivedi@marvell.com \
--cc=alialnu@nvidia.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=jerinj@marvell.com \
--cc=jerinjacobk@gmail.com \
--cc=thomas@monjalon.net \
--cc=weiyuanx.li@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).