DPDK patches and discussions
 help / color / mirror / Atom feed
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] $


  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).