From: Will Deacon <will@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel-team@android.com,
maz@kernel.org, rananta@google.com
Subject: Re: [GIT PULL] arm64 fixes for -rc7
Date: Mon, 17 Mar 2025 16:00:35 +0000 [thread overview]
Message-ID: <20250317160034.GA12267@willie-the-truck> (raw)
In-Reply-To: <CAHk-=wgiX0q0WCL+SFwVCYtG7JR3=2Rshse-5J3AO2Y4AgT7Jw@mail.gmail.com>
Hi Linus,
On Fri, Mar 14, 2025 at 10:34:57AM -1000, Linus Torvalds wrote:
> On Fri, 14 Mar 2025 at 06:05, Will Deacon <will@kernel.org> wrote:
> >
> > Summary in the tag, but the main one is a horrible macro fix for our
> > TLB flushing code which resulted in over-invalidation on the MMU
> > notifier path.
>
> From a quick look, that macro is still quite broken. Maybe not in ways
> that matter, but still...
>
> In particular, the 'stride' argument is used multiple times, and
> without parentheses.
>
> The 'lpa' argument is also used multiple times, and the input to that
> is typically something like kvm_lpa2_is_enabled(), so I think it
> potentially generates lots of pointless duplicate code with that
> BUG_ON() in system_supports_lpa2() -> cpus_have_final_cap().
>
> Maybe the compiler figures it out. But that macro is bad, bad, bad.
> When it looks like a function, it should act like a function, and not
> evaluate its arguments multiple times.
>
> The most immediate bug may have been fixed, but not the actual real
> horror of that thing.
Yes, the minimal fix for -rc7 avoids explicitly mutating the macro
arguments but we still have the multiple-evaluation problem you point
out above.
Ideally, this function would be rewritten as a 'static inline' but it
was moved from C code into a macro as part of 360839027a6e ("arm64: tlb:
Refactor the core flush algorithm of __flush_tlb_range") because we need
to propagate the 'op' argument down to the low-level asm where it's
stringified as part of the instruction mnemonic.
I'll have a crack at reworking things to take a 'const char *' instead,
but it won't be for 6.14 as it'll be reasonably invasive.
Will
next prev parent reply other threads:[~2025-03-17 16:02 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-14 16:04 [GIT PULL] arm64 fixes for -rc7 Will Deacon
2025-03-14 20:34 ` Linus Torvalds
2025-03-17 16:00 ` Will Deacon [this message]
2025-03-18 11:43 ` Will Deacon
2025-03-18 11:46 ` Marc Zyngier
2025-03-14 21:03 ` pr-tracker-bot
-- strict thread matches above, loose matches on Subject: below --
2024-11-08 11:57 Will Deacon
2024-11-08 17:39 ` pr-tracker-bot
2022-09-23 18:28 Will Deacon
2022-09-23 22:43 ` Linus Torvalds
2022-09-28 10:46 ` Mark Rutland
2022-09-23 22:53 ` pr-tracker-bot
2022-05-13 16:52 Will Deacon
2022-05-13 17:30 ` pr-tracker-bot
2021-08-20 8:53 Will Deacon
2021-08-20 20:09 ` pr-tracker-bot
2020-12-02 17:17 Will Deacon
2020-12-02 20:48 ` pr-tracker-bot
2020-03-20 15:35 Will Deacon
2020-03-20 17:15 ` pr-tracker-bot
2019-08-28 17:32 [GIT PULL] arm64: Fixes " Will Deacon
2019-08-28 17:45 ` pr-tracker-bot
2018-07-27 11:51 [GIT PULL] arm64: fixes " Will Deacon
2018-05-25 16:04 Will Deacon
2016-07-08 14:49 Will Deacon
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=20250317160034.GA12267@willie-the-truck \
--to=will@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=kernel-team@android.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=rananta@google.com \
--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