public inbox for dev@dpdk.org
 help / color / mirror / Atom feed
From: "Morten Brørup" <mb@smartsharesystems.com>
To: "David Marchand" <david.marchand@redhat.com>,
	<scott.k.mitch1@gmail.com>,
	"Andre Muezerie" <andremue@linux.microsoft.com>,
	"Tyler Retzlaff" <roretzla@linux.microsoft.com>
Cc: <dev@dpdk.org>, <stephen@networkplumber.org>,
	<bruce.richardson@intel.com>,
	"Cyril Chemparathy" <cchemparathy@ezchip.com>, <stable@dpdk.org>
Subject: RE: [PATCH v19 1/2] eal: add __rte_may_alias and __rte_aligned to unaligned typedefs
Date: Mon, 16 Feb 2026 16:00:43 +0100	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35F65724@smartserver.smartshare.dk> (raw)
In-Reply-To: <CAJFAV8zr6zcvOwY920y=Sbo60UUSWhMw4jROs0h=ugNXJAHQ+A@mail.gmail.com>

> From: David Marchand [mailto:david.marchand@redhat.com]
> Sent: Monday, 16 February 2026 15.29
> 
> Hello Scott, Andre, Tyler,
> 
> On Mon, 2 Feb 2026 at 05:48, <scott.k.mitch1@gmail.com> wrote:
> >
> > From: Scott Mitchell <scott.k.mitch1@gmail.com>
> >
> > Add __rte_may_alias attribute to unaligned_uint{16,32,64}_t typedefs
> > to prevent GCC strict-aliasing optimization bugs. GCC has a bug where
> > it incorrectly elides struct initialization when strict aliasing is
> > enabled, causing reads from uninitialized memory.
> >
> > Add __rte_aligned(1) attribute to unaligned_uint{16,32,64}_t typedefs
> > which allows for safe access at any alignment. Without this,
> accessing
> > a uint16_t at an odd address is undefined behavior. Without this
> > UBSan detects `UndefinedBehaviorSanitizer: undefined-behavior`.
> >
> > Fixes: 7621d6a8d0bd ("eal: add and use unaligned integer types")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Scott Mitchell <scott.k.mitch1@gmail.com>
> 
> [snip]
> 
> > diff --git a/lib/eal/include/rte_common.h
> b/lib/eal/include/rte_common.h
> > index 573bf4f2ce..7b36966019 100644
> > --- a/lib/eal/include/rte_common.h
> > +++ b/lib/eal/include/rte_common.h
> > @@ -121,16 +121,42 @@ extern "C" {
> >  #define __rte_aligned(a) __attribute__((__aligned__(a)))
> >  #endif
> >
> > -#ifdef RTE_ARCH_STRICT_ALIGN
> > -typedef uint64_t unaligned_uint64_t __rte_aligned(1);
> > -typedef uint32_t unaligned_uint32_t __rte_aligned(1);
> > -typedef uint16_t unaligned_uint16_t __rte_aligned(1);
> > +/**
> > + * Macro to mark a type that is not subject to type-based aliasing
> rules
> > + */
> > +#ifdef RTE_TOOLCHAIN_MSVC
> > +#define __rte_may_alias
> >  #else
> > -typedef uint64_t unaligned_uint64_t;
> > -typedef uint32_t unaligned_uint32_t;
> > -typedef uint16_t unaligned_uint16_t;
> > +#define __rte_may_alias __attribute__((__may_alias__))
> >  #endif
> >
> > +/* Unaligned types implementation notes:
> > + * __rte_aligned(1) - Reduces alignment requirement to 1 byte,
> allowing
> > + *                    these types to safely access memory at any
> address.
> > + *                    Without this, accessing a uint16_t at an odd
> address
> > + *                    is undefined behavior (even on x86 where
> hardware
> > + *                    handles it).
> > + *
> > + * __rte_may_alias  - Prevents strict-aliasing optimization bugs
> where
> > + *                    compilers may incorrectly elide memory
> operations
> > + *                    when casting between pointer types.
> > + */
> > +
> > +/**
> > + * Type for safe unaligned u64 access.
> > + */
> > +typedef __rte_may_alias __rte_aligned(1) uint64_t
> unaligned_uint64_t;
> > +
> > +/**
> > + * Type for safe unaligned u32 access.
> > + */
> > +typedef __rte_may_alias __rte_aligned(1) uint32_t
> unaligned_uint32_t;
> > +
> > +/**
> > + * Type for safe unaligned u16 access.
> > + */
> > +typedef __rte_may_alias __rte_aligned(1) uint16_t
> unaligned_uint16_t;
> > +
> >  /**
> >   * @deprecated
> >   * @see __rte_packed_begin
> > @@ -159,15 +185,6 @@ typedef uint16_t unaligned_uint16_t;
> >  #define __rte_packed_end __attribute__((__packed__))
> >  #endif
> >
> > -/**
> > - * Macro to mark a type that is not subject to type-based aliasing
> rules
> > - */
> > -#ifdef RTE_TOOLCHAIN_MSVC
> > -#define __rte_may_alias
> > -#else
> > -#define __rte_may_alias __attribute__((__may_alias__))
> > -#endif
> > -
> >  /******* Macro to mark functions and fields scheduled for removal
> *****/
> >  #ifdef RTE_TOOLCHAIN_MSVC
> >  #define __rte_deprecated
> 
> This change raises a warning in checkpatch.
> https://mails.dpdk.org/archives/test-report/2026-February/955237.html
> 
> IIRC, we added this check for MSVC support, making sure no
> __rte_aligned() would be added in unsupported locations.

It looks like MSVC can use alignment for type definitions too:
https://learn.microsoft.com/en-us/cpp/cpp/align-cpp?view=msvc-170#vclrf_declspecaligntypedef

It is applied on a structure, though, so may not be viable for scalar types. IDK.

But it looks like MSVC can only increase alignment:
https://learn.microsoft.com/en-us/cpp/cpp/align-cpp?view=msvc-170#:~:text=__declspec(align(%23))%20can%20only%20increase%20alignment%20restrictions.

So packing may be needed too.

> 
> @Microsoft guys, do you have a suggestion?
> 
> 
> --
> David Marchand


  reply	other threads:[~2026-02-16 15:00 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-12 12:04 [PATCH v14 0/2] net: optimize __rte_raw_cksum scott.k.mitch1
2026-01-12 12:04 ` [PATCH v14 1/2] eal: add __rte_may_alias to unaligned typedefs scott.k.mitch1
2026-01-12 13:28   ` Morten Brørup
2026-01-12 15:00     ` Scott Mitchell
2026-01-12 12:04 ` [PATCH v14 2/2] net: __rte_raw_cksum pointers enable compiler optimizations scott.k.mitch1
2026-01-17 21:21 ` [PATCH v15 0/2] net: optimize __rte_raw_cksum scott.k.mitch1
2026-01-17 21:21   ` [PATCH v15 1/2] eal: add __rte_may_alias to unaligned typedefs scott.k.mitch1
2026-01-20 15:23     ` Morten Brørup
2026-01-23 14:34       ` Scott Mitchell
2026-01-17 21:21   ` [PATCH v15 2/2] net: __rte_raw_cksum pointers enable compiler optimizations scott.k.mitch1
2026-01-17 22:08   ` [PATCH v15 0/2] net: optimize __rte_raw_cksum Stephen Hemminger
2026-01-20 12:45     ` Morten Brørup
2026-01-23 15:43       ` Scott Mitchell
2026-01-23 16:02   ` [PATCH v16 " scott.k.mitch1
2026-01-23 16:02     ` [PATCH v16 1/2] eal: add __rte_may_alias to unaligned typedefs scott.k.mitch1
2026-01-23 16:02     ` [PATCH v16 2/2] net: __rte_raw_cksum pointers enable compiler optimizations scott.k.mitch1
2026-01-28 11:05       ` David Marchand
2026-01-28 17:39         ` Scott Mitchell
2026-01-24  8:23     ` [PATCH v16 0/2] net: optimize __rte_raw_cksum Morten Brørup
2026-01-28 18:05     ` [PATCH v17 " scott.k.mitch1
2026-01-28 18:05       ` [PATCH v17 1/2] eal: add __rte_may_alias and __rte_aligned to unaligned typedefs scott.k.mitch1
2026-01-28 18:05       ` [PATCH v17 2/2] net: __rte_raw_cksum pointers enable compiler optimizations scott.k.mitch1
2026-01-28 19:41       ` [PATCH v18 0/2] net: optimize __rte_raw_cksum scott.k.mitch1
2026-01-28 19:41         ` [PATCH v18 1/2] eal: add __rte_may_alias and __rte_aligned to unaligned typedefs scott.k.mitch1
2026-01-29  8:28           ` Morten Brørup
2026-02-02  4:31             ` Scott Mitchell
2026-01-28 19:41         ` [PATCH v18 2/2] net: __rte_raw_cksum pointers enable compiler optimizations scott.k.mitch1
2026-01-29  8:31           ` Morten Brørup
2026-02-02  4:48         ` [PATCH v19 0/2] net: optimize __rte_raw_cksum scott.k.mitch1
2026-02-02  4:48           ` [PATCH v19 1/2] eal: add __rte_may_alias and __rte_aligned to unaligned typedefs scott.k.mitch1
2026-02-03  8:18             ` Morten Brørup
2026-02-16 14:29             ` David Marchand
2026-02-16 15:00               ` Morten Brørup [this message]
2026-02-02  4:48           ` [PATCH v19 2/2] net: __rte_raw_cksum pointers enable compiler optimizations scott.k.mitch1
2026-02-03  8:19             ` Morten Brørup
2026-02-06 14:54           ` [PATCH v19 0/2] net: optimize __rte_raw_cksum David Marchand
2026-02-07  1:29             ` Scott Mitchell
2026-02-10 11:53               ` Thomas Monjalon
2026-02-16 14:04               ` David Marchand

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=98CBD80474FA8B44BF855DF32C47DC35F65724@smartserver.smartshare.dk \
    --to=mb@smartsharesystems.com \
    --cc=andremue@linux.microsoft.com \
    --cc=bruce.richardson@intel.com \
    --cc=cchemparathy@ezchip.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=roretzla@linux.microsoft.com \
    --cc=scott.k.mitch1@gmail.com \
    --cc=stable@dpdk.org \
    --cc=stephen@networkplumber.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