From: David Laight <david.laight.linux@gmail.com>
To: Maciej Wieczor-Retman <m.wieczorretman@pm.me>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
tglx@kernel.org, peterz@infradead.org, xin@zytor.com,
maciej.wieczor-retman@intel.com, babu.moger@amd.com,
chang.seok.bae@intel.com, sohil.mehta@intel.com,
dave.hansen@linux.intel.com, jpoimboe@kernel.org,
elena.reshetova@intel.com, ak@linux.intel.com,
darwi@linutronix.de, bp@alien8.de, mingo@redhat.com,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v11 3/4] x86/cpu: Do a sanity check on required feature bits
Date: Mon, 30 Mar 2026 22:24:24 +0100 [thread overview]
Message-ID: <20260330222424.39948b9c@pumpkin> (raw)
In-Reply-To: <acpIvIYg_6goTRIW@wieczorr-mobl1.localdomain>
On Mon, 30 Mar 2026 10:09:47 +0000
Maciej Wieczor-Retman <m.wieczorretman@pm.me> wrote:
> On 2026-03-27 at 18:52:30 -0700, H. Peter Anvin wrote:
...
> >One thing that matters here is that these bitmaps are *already* accessed using
> >bitop operations. Therefore, if this is a problem *here*, then it is a problem
> >*everywhere*.
>
> I think for example the set_bit()/clear_bit() bitops are not problematic while
> for_each_set_bit() is, specfically used in this context. Most operations seem to
> not affect or not be affected by the potential unaligned 32-bit.
Oh they are...
Look up 'split lock'.
You must not cast int[] to long[] for the 'bit' functions.
Basically if the 'long' gets split over a cache-line boundary the cpu
has to do an 'old fashioned' lock of the inter-cpu bus in order to
perform the locked memory accesses.
That is both slow and kills the rest of the machine.
David
next prev parent reply other threads:[~2026-03-30 21:24 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 12:50 [PATCH v11 0/4] x86: Capability bits fix and required bits sanity check Maciej Wieczor-Retman
2026-03-20 12:50 ` [PATCH v11 1/4] x86/cpu: Clear feature bits disabled at compile-time Maciej Wieczor-Retman
2026-03-20 12:50 ` [PATCH v11 2/4] x86/cpu: Check if feature string is non-zero Maciej Wieczor-Retman
2026-03-23 14:24 ` Borislav Petkov
2026-03-23 15:52 ` Maciej Wieczor-Retman
2026-03-23 16:23 ` Borislav Petkov
2026-03-23 16:58 ` Maciej Wieczor-Retman
2026-03-23 17:51 ` Borislav Petkov
2026-03-23 18:11 ` Maciej Wieczor-Retman
2026-03-23 18:15 ` H. Peter Anvin
2026-03-20 12:50 ` [PATCH v11 3/4] x86/cpu: Do a sanity check on required feature bits Maciej Wieczor-Retman
2026-03-21 0:31 ` Pawan Gupta
2026-03-21 5:58 ` Maciej Wieczór-Retman
2026-03-23 18:16 ` Pawan Gupta
2026-03-23 18:33 ` Maciej Wieczor-Retman
2026-03-26 18:36 ` Maciej Wieczor-Retman
2026-03-26 19:04 ` Pawan Gupta
2026-03-26 19:11 ` Maciej Wieczor-Retman
2026-03-28 1:52 ` H. Peter Anvin
2026-03-28 2:01 ` H. Peter Anvin
2026-03-30 9:47 ` Maciej Wieczor-Retman
2026-03-30 10:09 ` Maciej Wieczor-Retman
2026-03-30 16:01 ` Pawan Gupta
2026-03-30 21:24 ` David Laight [this message]
2026-03-31 8:12 ` Maciej Wieczor-Retman
2026-03-31 13:29 ` Maciej Wieczor-Retman
2026-03-23 16:31 ` Borislav Petkov
2026-03-23 17:05 ` Maciej Wieczor-Retman
2026-03-23 17:55 ` Borislav Petkov
2026-03-23 18:43 ` H. Peter Anvin
2026-03-23 18:43 ` H. Peter Anvin
2026-03-23 19:19 ` Borislav Petkov
2026-03-23 20:24 ` H. Peter Anvin
2026-03-23 20:58 ` Borislav Petkov
2026-03-23 21:40 ` H. Peter Anvin
2026-03-23 21:50 ` Borislav Petkov
2026-03-23 21:56 ` Borislav Petkov
2026-03-23 22:03 ` H. Peter Anvin
2026-03-23 22:09 ` Borislav Petkov
2026-03-24 1:16 ` H. Peter Anvin
2026-03-20 12:50 ` [PATCH v11 4/4] x86/cpu: Clear feature bits whose dependencies were cleared Maciej Wieczor-Retman
2026-03-23 16:35 ` Borislav Petkov
2026-03-23 17:23 ` Maciej Wieczor-Retman
2026-03-23 17:59 ` Borislav Petkov
2026-03-23 18:18 ` Maciej Wieczor-Retman
2026-03-23 18:57 ` H. Peter Anvin
2026-03-23 19:30 ` Borislav Petkov
2026-03-25 9:33 ` Maciej Wieczor-Retman
2026-03-23 19:33 ` Ahmed S. Darwish
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=20260330222424.39948b9c@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=ak@linux.intel.com \
--cc=babu.moger@amd.com \
--cc=bp@alien8.de \
--cc=chang.seok.bae@intel.com \
--cc=darwi@linutronix.de \
--cc=dave.hansen@linux.intel.com \
--cc=elena.reshetova@intel.com \
--cc=hpa@zytor.com \
--cc=jpoimboe@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.wieczorretman@pm.me \
--cc=maciej.wieczor-retman@intel.com \
--cc=mingo@redhat.com \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=peterz@infradead.org \
--cc=sohil.mehta@intel.com \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
--cc=xin@zytor.com \
/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.