From: David Laight <david.laight.linux@gmail.com>
To: Ian Rogers <irogers@google.com>
Cc: Andy Lutomirski <luto@kernel.org>,
Thomas Gleixner <tglx@kernel.org>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Stefan Kerkmann <s.kerkmann@pengutronix.de>,
Marc Kleine-Budde <mkl@pengutronix.de>,
Arnd Bergmann <arnd@arndb.de>,
Christophe Leroy <chleroy@kernel.org>,
Helge Deller <deller@gmx.de>,
"James E . J . Bottomley" <James.Bottomley@HansenPartnership.com>,
"Jason A . Donenfeld" <Jason@zx2c4.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Eric Biggers <ebiggers@google.com>,
linux-kernel@vger.kernel.org, linux-parisc@vger.kernel.org
Subject: Re: [PATCH v2 1/2] vdso: Add VDSO_UNALIGNED_PACKED config option
Date: Tue, 20 Oct 2026 19:07:18 +0100 [thread overview]
Message-ID: <20261020190718.6cba898b@pumpkin> (raw)
In-Reply-To: <20261020163210.742728-1-irogers@google.com>
On Tue, 20 Oct 2026 09:32:09 -0700
Ian Rogers <irogers@google.com> wrote:
> Commit a339671db64b ("vdso: Switch get/put_unaligned() from packed struct
> to memcpy()") switched __get_unaligned_t() and __put_unaligned_t() from
> using a __packed struct to __builtin_memcpy() to avoid strict aliasing
> undefined behavior.
>
> On targets without efficient unaligned memory accesses (such as ARMv5),
> GCC may not inline __builtin_memcpy() into byte shifts and instead emit
> stack spills or much slower out-of-line memcpy() calls. Add
> CONFIG_VDSO_UNALIGNED_PACKED, defaulting to
> !HAVE_EFFICIENT_UNALIGNED_ACCESS, to use the __packed struct
> implementation on strict-alignment targets while keeping
> __builtin_memcpy() elsewhere and in tools/.
>
> Fixes: a339671db64b ("vdso: Switch get/put_unaligned() from packed struct to memcpy()")
> Reported-by: Stefan Kerkmann <s.kerkmann@pengutronix.de>
> Closes: https://lore.kernel.org/lkml/47f8c30b-e326-4ff0-a2bc-5683209a9e2d@pengutronix.de/
> Signed-off-by: Ian Rogers <irogers@google.com>
> ---
> v2: Default VDSO_UNALIGNED_PACKED to !HAVE_EFFICIENT_UNALIGNED_ACCESS
> instead of CPU_32v5 to cover all strict-alignment targets (Sashiko,
> Arnd Bergmann).
>
> include/vdso/unaligned.h | 16 ++++++++++++++++
> lib/vdso/Kconfig | 10 ++++++++++
> 2 files changed, 26 insertions(+)
>
> diff --git a/include/vdso/unaligned.h b/include/vdso/unaligned.h
> index 9076483c9fbb..726fd15efc82 100644
> --- a/include/vdso/unaligned.h
> +++ b/include/vdso/unaligned.h
> @@ -4,6 +4,20 @@
>
> #include <linux/compiler_types.h>
>
> +#ifdef CONFIG_VDSO_UNALIGNED_PACKED
> +
> +#define __get_unaligned_t(type, ptr) ({ \
> + const struct { type x; } __packed * __get_pptr = (typeof(__get_pptr))(ptr); \
> + __get_pptr->x; \
> +})
> +
> +#define __put_unaligned_t(type, val, ptr) do { \
> + struct { type x; } __packed * __put_pptr = (typeof(__put_pptr))(ptr); \
> + __put_pptr->x = (val); \
> +} while (0)
I'm confused (easily done).
That code relies on strict alignment being disabled regardless of whether
misaligned accesses fault or not.
So it is either always valid or always wrong.
Additionally I think the compiler can sometimes track the alignment through
casts (although it didn't for a quick check I did earlier).
Since having misaligned non-packed structures really doesn't work, the only
places these functions should be used is on u8[] buffers.
Pointers into those can (probably) be cast to packed structure types
without causing issues if strict aliasing is enabled.
If you write the value as u64 then read as u32 I think they could cross
even though the buffer is u8[].
That might mean you need a barrier() before the read in get() and before
and after the write in put().
(Partial barriers may work - dunno.)
David
> +
> +#else /* !CONFIG_VDSO_UNALIGNED_PACKED */
> +
> /**
> * __get_unaligned_t - read an unaligned value from memory.
> * @type: the type to load from the pointer.
> @@ -41,4 +55,6 @@
> sizeof(__put_unaligned_val)); \
> } while (0)
>
> +#endif /* CONFIG_VDSO_UNALIGNED_PACKED */
> +
> #endif /* __VDSO_UNALIGNED_H */
> diff --git a/lib/vdso/Kconfig b/lib/vdso/Kconfig
> index 597f5f0f9681..2436c20ee0ef 100644
> --- a/lib/vdso/Kconfig
> +++ b/lib/vdso/Kconfig
> @@ -23,3 +23,13 @@ config VDSO_GETRANDOM
> select VDSO_DATASTORE
> help
> Selected by architectures that support vDSO getrandom().
> +
> +config VDSO_UNALIGNED_PACKED
> + bool
> + default !HAVE_EFFICIENT_UNALIGNED_ACCESS
> + help
> + Use packed structs rather than memcpy() in include/vdso/unaligned.h
> + for unaligned memory accesses. Enabled by default when the
> + architecture does not have efficient unaligned accesses, as GCC may
> + emit stack spills or out-of-line memcpy() calls instead of inlining
> + byte shifts.
prev parent reply other threads:[~2026-10-20 18:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 16:32 Ian Rogers
2026-10-20 16:32 ` [PATCH v2 2/2] tools headers: Update the vdso/unaligned.h copy with the kernel sources Ian Rogers
2026-10-20 18:07 ` David Laight [this message]
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=20261020190718.6cba898b@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=Jason@zx2c4.com \
--cc=acme@redhat.com \
--cc=arnd@arndb.de \
--cc=chleroy@kernel.org \
--cc=deller@gmx.de \
--cc=ebiggers@google.com \
--cc=irogers@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mkl@pengutronix.de \
--cc=s.kerkmann@pengutronix.de \
--cc=tglx@kernel.org \
--cc=vincenzo.frascino@arm.com \
--cc=viro@zeniv.linux.org.uk \
/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
all inboxes | Powered by JetHome®