All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ian Rogers" <irogers@google.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v1 1/2] vdso: Add VDSO_UNALIGNED_PACKED config option for ARMv5
Date: Mon, 19 Oct 2026 20:39:06 +0000	[thread overview]
Message-ID: <sashiko-outbox-178182@kernel.org> (raw)
In-Reply-To: <20261019201257.3805356-1-irogers@google.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] vdso: VDSO_UNALIGNED_PACKED default omits non-ARMv5 strict-alignment targets
--

commit 1a3f0256f7d442ba6867246bd156ba9784b5b9a5
Author: Ian Rogers <irogers@google.com>

vdso: Add VDSO_UNALIGNED_PACKED config option for ARMv5

This commit adds CONFIG_VDSO_UNALIGNED_PACKED, defaulted to CPU_32v5, to
restore the packed struct implementation of __get_unaligned_t() and
__put_unaligned_t() on ARMv5 where GCC may emit out-of-line memcpy() calls
for __builtin_memcpy().

> diff --git a/lib/vdso/Kconfig b/lib/vdso/Kconfig
> index 597f5f0f96819..709eb193999fd 100644
> --- a/lib/vdso/Kconfig
> +++ b/lib/vdso/Kconfig
> @@ -23,3 +23,11 @@ config VDSO_GETRANDOM
>  	select VDSO_DATASTORE
>  	help
>  	  Selected by architectures that support vDSO getrandom().
> +
> +config VDSO_UNALIGNED_PACKED
> +	bool
> +	default CPU_32v5
> +	help
> +	  Use packed structs rather than memcpy() in include/vdso/unaligned.h
> +	  for unaligned memory accesses. Enabled on ARMv5 where GCC may emit
> +	  out-of-line memcpy() calls instead of inlining byte accesses.

[Severity: Medium]
Does defaulting VDSO_UNALIGNED_PACKED only to CPU_32v5 leave out other
strict-alignment targets that experience the same GCC __builtin_memcpy()
regression from commit a339671db64b ("vdso: Switch get/put_unaligned() from
packed struct to memcpy()")?

include/linux/unaligned.h includes include/vdso/unaligned.h to define
get_unaligned() and put_unaligned() across the entire kernel and boot
decompressors. On strict-alignment targets, GCC cannot fold
__builtin_memcpy() into a scalar access when the pointer alignment is
smaller than the type alignment, resulting in stack spills or out-of-line
memcpy() calls instead of the register shifts generated for a __packed
struct access.

In arch/arm/Makefile, ARMv3, ARMv4, and ARMv4T targets use separate Kconfig
symbols without selecting CPU_32v5, and !CONFIG_MMU builds pass
-mno-unaligned-access:

    ifeq ($(CONFIG_MMU),)
    CFLAGS_ABI	+=-mno-unaligned-access
    endif
    ...
    arch-$(CONFIG_CPU_32v5)		:=-march=armv5te
    arch-$(CONFIG_CPU_32v4T)	:=-march=armv4t
    arch-$(CONFIG_CPU_32v4)		:=-march=armv4
    arch-$(CONFIG_CPU_32v3)		:=-march=armv3m

In arch/arm/Kconfig, hardware unaligned access support is distinguished via
HAVE_EFFICIENT_UNALIGNED_ACCESS:

    select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && MMU

Should VDSO_UNALIGNED_PACKED default to !HAVE_EFFICIENT_UNALIGNED_ACCESS (or
could include/vdso/unaligned.h use a single __packed __may_alias definition)
so that ARMv3, ARMv4, ARMv4T, ARM !MMU, and other strict-alignment
architectures are covered as well?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261019201257.3805356-1-irogers@google.com?part=1

  parent reply	other threads:[~2026-10-19 20:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-19 20:12 [PATCH v1 1/2] vdso: Add VDSO_UNALIGNED_PACKED config option for ARMv5 Ian Rogers
2026-10-19 20:12 ` [PATCH v1 2/2] tools headers: Update the vdso/unaligned.h copy with the kernel sources Ian Rogers
2026-10-19 20:23   ` sashiko-bot
2026-10-19 20:39 ` sashiko-bot [this message]
2026-10-19 22:12 ` [PATCH v1 1/2] vdso: Add VDSO_UNALIGNED_PACKED config option for ARMv5 Arnd Bergmann
2026-10-20  6:44   ` Marc Kleine-Budde
2026-10-20  8:24     ` Arnd Bergmann
2026-10-20  8:41       ` Marc Kleine-Budde
2026-10-20  9:06         ` Arnd Bergmann
2026-10-20 14:56       ` Marc Kleine-Budde
2026-10-20 15:51         ` David Laight
2026-10-20 15:54         ` Arnd Bergmann
2026-10-20 14:00 ` David Laight

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=sashiko-outbox-178182@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=irogers@google.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.