From: Dave Hansen <dave.hansen@intel.com>
To: "H. Peter Anvin" <hpa@zytor.com>,
Sohil Mehta <sohil.mehta@intel.com>,
x86@kernel.org, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Sean Christopherson <seanjc@google.com>,
Tony Luck <tony.luck@intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/cpufeatures: Free up unused feature bits
Date: Fri, 8 Nov 2024 10:42:24 -0800 [thread overview]
Message-ID: <551e8238-84a1-4d5d-91c1-8d2adfde62e0@intel.com> (raw)
In-Reply-To: <4c01a30a-67d9-4918-8781-240b78944c42@intel.com>
On 11/7/24 17:12, Dave Hansen wrote:
> and then we recycled number 67:
>
> -#define X86_FEATURE_P3 ( 3*32+ 6) /* P3 */
> +#define X86_FEATURE_WHIZZY_NEW_FEATURE ( 3*32+ 6) /* P3 */
>
> udev might try to load the old module on a new CPU with
> X86_FEATURE_WHIZZY_NEW_FEATURE that's not a P3.
Thinking about this a bit more...
The kernel generates _both_ the
"cpu:type:x86,ven*fam*mod*:feature:*0067*" string and the sysfs modalias
string. So the issue isn't practically a mismatch between those.
It's if some consumer of those fields (like /lib/udev/hwdb.d/) was
looking for feature 67.
The good news is that I don't see any of those today. But it's totally
possible that folks have some crazy rules out there. So we should
probably be _careful_ about changing those values and not just change
them *ALL*. But I think it's pretty unlikely we'll break anybody by
reusing a bit or two.
next prev parent reply other threads:[~2024-11-08 18:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-07 23:30 [PATCH] x86/cpufeatures: Free up unused feature bits Sohil Mehta
2024-11-07 23:36 ` Dave Hansen
2024-11-07 23:44 ` Sohil Mehta
2024-11-07 23:49 ` H. Peter Anvin
2024-11-08 0:35 ` Sohil Mehta
2024-11-08 0:37 ` H. Peter Anvin
2024-11-08 1:12 ` Dave Hansen
2024-11-08 2:17 ` Sohil Mehta
2024-11-08 15:31 ` H. Peter Anvin
2024-11-08 18:42 ` Dave Hansen [this message]
2024-11-08 18:42 ` Sohil Mehta
2024-11-08 18:46 ` Dave Hansen
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=551e8238-84a1-4d5d-91c1-8d2adfde62e0@intel.com \
--to=dave.hansen@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=seanjc@google.com \
--cc=sohil.mehta@intel.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=x86@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.