DPDK patches and discussions
 help / color / mirror / Atom feed
From: Owen Hilyard <ohilyard@iol.unh.edu>
To: Aaron Conole <aconole@redhat.com>,
	David Marchand <david.marchand@redhat.com>
Cc: dev <dev@dpdk.org>
Subject: [dpdk-dev] Define statement with UB prevents compilation using UBSAN
Date: Thu, 10 Jun 2021 16:51:37 -0400	[thread overview]
Message-ID: <CAHx6DYC32D9FTsCXpRbShgCcKTwMB9GOp0HZBBcUBc8NjZ7y5A@mail.gmail.com> (raw)

Hello,

While starting work on adding UBSAN to the community lab CI, I found that
DPDK does not compile in its default configuration with UBSAN enabled,
failing with the error message:

../drivers/net/bnx2x/bnx2x.c: In function ‘bnx2x_check_blocks_with_parity3’:
../drivers/net/bnx2x/bnx2x.c:3363:4: error: case label does not reduce to
an integer constant
 3363 |    case AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY:
      |    ^~~~

Working backward to the define
statement, AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY is defined as

#define AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY (0x1 << 31)

While this does set the most significant bit of the integer, it also seems
to make UBSAN unable to properly track its type. Replacing this with

#define AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY (-2147483648)

or

#define AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY
(0b10000000000000000000000000000000)

Allows compilation to finish on x86_64, but substantially breaks the style
of the rest of the file. There are a few other places where this undefined
behavior happens:

./drivers/baseband/acc100/rte_acc100_pmd.c:4490: value = (1 << 31) + (23 <<
8) + (1 << 6) + 7;
./drivers/net/bnxt/tf_core/tf_shadow_tcam.c:60:#define
TF_SHADOW_TCAM_HB_HANDLE_IS_VALID(hndl) (((hndl) & (1 << 31)) != 0)
./drivers/net/bnxt/tf_core/tf_shadow_tcam.c:61:#define
TF_SHADOW_TCAM_HB_HANDLE_CREATE(idx, be) ((1 << 31) | \
./drivers/net/bnxt/tf_core/tf_shadow_tbl.c:60:#define
TF_SHADOW_HB_HANDLE_IS_VALID(hndl) (((hndl) & (1 << 31)) != 0)
./drivers/net/bnxt/tf_core/tf_shadow_tbl.c:61:#define
TF_SHADOW_HB_HANDLE_CREATE(idx, be) ((1 << 31) | \
./drivers/net/e1000/base/e1000_regs.h:197:#define E1000_TQAVCC_QUEUE_MODE
(1 << 31) /* SP vs. SR Tx mode */
./drivers/net/e1000/base/e1000_regs.h:607:#define E1000_ETQF_QUEUE_ENABLE
(1 << 31)
./drivers/net/igc/base/igc_regs.h:201:#define IGC_TQAVCC_QUEUE_MODE (1 <<
31) /* SP vs. SR Tx mode */
./drivers/net/igc/base/igc_82575.h:248:#define IGC_ETQF_QUEUE_ENABLE (1 <<
31)
./drivers/net/igc/base/igc_82575.h:271:#define IGC_DTXSWC_VMDQ_LOOPBACK_EN
(1 << 31)  /* global VF LB enable */
./drivers/net/bnx2x/ecore_hsi.h:2597: #define TRIGGER_MDUMP_ONCE      (1 <<
31)
./drivers/net/bnx2x/ecore_hsi.h:3904:#define IGU_REGULAR_BCLEANUP (0x1 <<
31)
./drivers/net/bnx2x/ecore_reg.h:4366:#define
AEU_INPUTS_ATTN_BITS_CCM_HW_INTERRUPT (0x1 << 31)
./drivers/net/bnx2x/ecore_reg.h:4391:#define
AEU_INPUTS_ATTN_BITS_PBCLIENT_HW_INTERRUPT (0x1 << 31)
./drivers/net/ixgbe/base/ixgbe_type.h:4295:#define
IXGBE_KRM_LINK_CTRL_1_TETH_AN_RESTART (1 << 31)
./drivers/net/ixgbe/base/ixgbe_type.h:4325:#define
IXGBE_KRM_TX_COEFF_CTRL_1_OVRRD_EN (1 << 31)
./drivers/crypto/qat/qat_sym_pmd.h:24:#define QAT_SYM_CAP_VALID (1 << 31)
./drivers/bus/fslmc/portal/dpaa2_hw_pvt.h:301:#define
DPAA2_SET_FLE_FIN(fle) ((fle)->fin_bpid_offset |= 1 << 31)
./drivers/raw/ioat/ioat_spec.h:329:#define CMDSTATUS_ACTIVE_MASK (1 << 31)
./drivers/common/mlx5/windows/mlx5_win_defs.h:114: IBV_RX_HASH_INNER = (1
<< 31)

Aside from normal CI, I don't have a good way to verify that a patch to fix
this wouldn't have hard to detect effects. As far as I know, some of these
drivers don't have DTS run on them in the course of CI, so I'm somewhat
wary of trying to make a change to them. Until this is fixed, deploying
UBSAN in any real capacity won't be useful since every patch will fail.
What do the two of you think about steps moving forward on this problem?

Owen Hilyard

             reply	other threads:[~2021-06-10 20:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-10 20:51 Owen Hilyard [this message]
2021-06-10 21:36 ` Stephen Hemminger
2021-06-11  9:19   ` Morten Brørup
2021-06-11 14:34   ` Aaron Conole
2021-06-11 18:15     ` Owen Hilyard

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=CAHx6DYC32D9FTsCXpRbShgCcKTwMB9GOp0HZBBcUBc8NjZ7y5A@mail.gmail.com \
    --to=ohilyard@iol.unh.edu \
    --cc=aconole@redhat.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    /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).