All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Nathan Chancellor' <nathan@kernel.org>, Arnd Bergmann <arnd@arndb.de>
Cc: Masahiro Yamada <masahiroy@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"llvm@lists.linux.dev" <llvm@lists.linux.dev>,
	# 3.4.x <stable@vger.kernel.org>
Subject: RE: [PATCH] Makefile.extrawarn: Move -Wunaligned-access to W=2
Date: Wed, 2 Feb 2022 17:33:41 +0000	[thread overview]
Message-ID: <df408e1fb00442e296f63b8ebd66f9a5@AcuMS.aculab.com> (raw)
In-Reply-To: <YfqwnMB2lLXOuahI@dev-arch.archlinux-ax161>

From: Nathan Chancellor
> Sent: 02 February 2022 16:26
> 
> On Wed, Feb 02, 2022 at 09:12:06AM +0100, Arnd Bergmann wrote:
> > On Wed, Feb 2, 2022 at 12:22 AM Nathan Chancellor <nathan@kernel.org> wrote:
> > >
> > > -Wunaligned-access is a new warning in clang that is default enabled for
> > > arm and arm64 under certain circumstances within the clang frontend (see
> > > LLVM commit below). Under an ARCH=arm allmodconfig, there are
> > > 1284 total/70 unique instances of this warning (most of the instances
> > > are in header files), which is quite noisy.
> > >
...
> >
> > The warning seems important enough to be considered for W=1 on 32-bit arm,
> > otherwise the chances of anyone actually fixing drivers for it is
> > relatively slim.
> 
> Fair point, I suppose barely anyone does W=2 builds, which means we
> might as well just disable it outright.
> 
> > Can you point post the (sufficiently trimmed) output that you get with
> > the warning
> > enabled in an allmodconfig build?
> 
> Sure thing.
> 
> Here is the trimmed version:
> 
> https://gist.github.com/nathanchance/6682e6894f75790059ca698c29212c71/raw/f63d54819afeb96f3ea0bb055096
> 849912ac0185/trimmed.log

So it is objecting to non-packed structures inside packed ones?
I'd have thought it ought to generate the byte accesses for code
that references the data from the __packed structure.

Recent gcc enable -Waddress-of-packed-member (even on x86) if you
take the address to pass somewhere else.
That is a bug if CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=n.

...
> There is this comment above this block in the source code:
> 
>     // Assume pre-ARMv6 doesn't support unaligned accesses.
>     //
>     // ARMv6 may or may not support unaligned accesses depending on the
>     // SCTLR.U bit, which is architecture-specific. We assume ARMv6
>     // Darwin and NetBSD targets support unaligned accesses, and others don't.
>     //
>     // ARMv7 always has SCTLR.U set to 1, but it has a new SCTLR.A bit
>     // which raises an alignment fault on unaligned accesses. Linux
>     // defaults this bit to 0 and handles it as a system-wide (not
>     // per-process) setting. It is therefore safe to assume that ARMv7+
>     // Linux targets support unaligned accesses. The same goes for NaCl
>     // and Windows.
>     //
>     // The above behavior is consistent with GCC.
> 
> I notice that CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS under certain
> conditions in arch/arm/Kconfig. Would it be worth telling clang that it
> can generate unaligned accesses in those cases via -munaligned-access or
> would that be too expensive? If we did, these warnings would be
> eliminated for configs with CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y,
> then it could be safely placed under W=1.

You really never want to do the fixup.
Except, maybe, if it is a very common path and the data is actually aligned
99.9999% of the time.

Part of the problem is almost certainly structures that are marked __packed
but can never be misaligned.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


  reply	other threads:[~2022-02-02 17:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-01 23:22 [PATCH] Makefile.extrawarn: Move -Wunaligned-access to W=2 Nathan Chancellor
2022-02-02  8:12 ` Arnd Bergmann
2022-02-02 16:26   ` Nathan Chancellor
2022-02-02 17:33     ` David Laight [this message]
2022-02-02 21:10     ` Arnd Bergmann

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=df408e1fb00442e296f63b8ebd66f9a5@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=arnd@arndb.de \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=masahiroy@kernel.org \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=stable@vger.kernel.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 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.