From: Stephen Hemminger <stephen@networkplumber.org>
To: Chengwen Feng <fengchengwen@huawei.com>
Cc: <thomas@monjalon.net>, <ferruh.yigit@amd.com>, <dev@dpdk.org>,
<huangdengdui@huawei.com>, <mb@smartsharesystems.com>,
<roretzla@linux.microsoft.com>
Subject: Re: [PATCH] ethdev: fix strict aliasing lead to link cannot be up
Date: Thu, 11 Apr 2024 08:05:30 -0700 [thread overview]
Message-ID: <20240411080530.1f5030c6@hermes.local> (raw)
In-Reply-To: <20240411030749.41874-1-fengchengwen@huawei.com>
On Thu, 11 Apr 2024 03:07:49 +0000
Chengwen Feng <fengchengwen@huawei.com> wrote:
> Fix a problem introduced by a compiler upgrade (from gcc10 to gcc12.3),
> which will lead the hns3 NIC can't link up. The root cause is strict
> aliasing violation in rte_eth_linkstatus_set() with hns3 driver, see
> [1] for more details.
>
> This commit use union to avoid such aliasing violation.
>
> [1] Strict aliasing problem with rte_eth_linkstatus_set()
> https://marc.info/?l=dpdk-dev&m=171274148514777&w=3
>
> Cc: stable@dpdk.org
>
> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> Signed-off-by: Dengdui Huang <huangdengdui@huawei.com>
> ---
The patch to use union is correct.
Examining the link status fuller raises a couple of pre-existing issues.
1. Why is this an inline function, there is no way this is in the
fast path of any driver or application?
2. Why is it marked sequential consistent and not relaxed? How could there be a visible
relationship between link status and other variables. Drivers would
not be using the link status state as internal variable.
next prev parent reply other threads:[~2024-04-11 15:05 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-11 3:07 Chengwen Feng
2024-04-11 6:53 ` Morten Brørup
2024-04-11 6:58 ` Morten Brørup
2024-04-11 11:57 ` fengchengwen
2024-04-11 12:44 ` Morten Brørup
2024-04-11 12:04 ` [PATCH v3] " Chengwen Feng
2024-04-11 12:44 ` Morten Brørup
2024-04-12 3:27 ` fengchengwen
2024-04-12 7:24 ` Morten Brørup
2024-04-11 15:05 ` Stephen Hemminger [this message]
2024-04-12 8:16 ` [PATCH] " fengchengwen
2024-04-12 8:49 ` [PATCH v4] " Chengwen Feng
2024-04-13 8:04 ` [PATCH v5] " Chengwen Feng
2024-04-13 8:48 ` [PATCH v6] " Chengwen Feng
2024-04-15 13:15 ` Morten Brørup
2024-04-18 7:28 ` [PATCH v7] " Chengwen Feng
2024-04-19 15:15 ` Ferruh Yigit
2024-04-19 15:25 ` Ferruh Yigit
2024-04-22 6:42 ` fengchengwen
2024-04-22 6:38 ` [PATCH v8] " Chengwen Feng
2024-04-22 10:54 ` 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=20240411080530.1f5030c6@hermes.local \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--cc=fengchengwen@huawei.com \
--cc=ferruh.yigit@amd.com \
--cc=huangdengdui@huawei.com \
--cc=mb@smartsharesystems.com \
--cc=roretzla@linux.microsoft.com \
--cc=thomas@monjalon.net \
/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).