mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Linus Torvalds" <torvalds@linux-foundation.org>,
	"Nathan Chancellor" <nathan@kernel.org>
Cc: "Jann Horn" <jannh@google.com>, "Marco Elver" <elver@google.com>,
	Linux-Arch <linux-arch@vger.kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rwonce: fix crash by removing READ_ONCE() for unaligned read
Date: Thu, 27 Mar 2025 11:58:31 +0100	[thread overview]
Message-ID: <0149da8d-957d-47e2-8711-6043a7701b6d@app.fastmail.com> (raw)
In-Reply-To: <CAHk-=wgJRECUF-7yt9pNxW_bc=4nJcxn5H3duW_HefY3pKwZag@mail.gmail.com>

On Thu, Mar 27, 2025, at 01:49, Linus Torvalds wrote:
> On Wed, 26 Mar 2025 at 15:54, Nathan Chancellor <nathan@kernel.org> wrote:
>>
>> > Put another way: I wonder what other cases may lurk around this all...
>>
>> That change has caused only one issue that I know of, which was fixed by
>> commit d3f450533bbc ("efi: tpm: Avoid READ_ONCE() for accessing the
>> event log"). I have not seen any since then until this point and I do
>> daily boots of -next with LTO enabled on both of my arm64 test machines.
>
> Ahh, ok. That makes me happier.

I've sent a new v2 pull request now.

> I guess unaligned READ_ONCE() code really shouldn't exist in generic
> code anyway, since some architectures will fail any unaligned access.

Even if the unaligned READ_ONCE()/WRITE_ONCE() doesn't fail, it may
be surprising to callers when it is not atomic.

> But those architectures tend to not get a lot of testing (they are a
> dying breed - good riddance), so "shouldn't exist" doesn't necessarily
> equate to really not existing.

Unfortunately, they don't seem to quite die out just yet, as both
riscv and loongarch have gained support for CPUs without unaligned
access even though they started out requiring it:

https://lore.kernel.org/lkml/20231004151405.521596-1-cleger@rivosinc.com/
https://lore.kernel.org/lkml/20230202084238.2408516-1-chenhuacai@loongson.cn/

ARMv7 also has the annoying behavior of supporting unaligned word
access, but not unaligned multi-word load/store with ldrd/strd
on u64 variables.

     Arnd

      reply	other threads:[~2025-03-27 10:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-26 21:04 Jann Horn
2025-03-26 21:23 ` Arnd Bergmann
2025-03-26 22:41   ` Linus Torvalds
2025-03-26 22:50     ` Jann Horn
2025-03-26 22:54     ` Nathan Chancellor
2025-03-27  0:49       ` Linus Torvalds
2025-03-27 10:58         ` Arnd Bergmann [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=0149da8d-957d-47e2-8711-6043a7701b6d@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=elver@google.com \
    --cc=jannh@google.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nathan@kernel.org \
    --cc=torvalds@linux-foundation.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

all inboxes | Powered by JetHome®