From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 35BD540DFC9 for ; Sat, 28 Mar 2026 02:33:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774665220; cv=none; b=qzW8DExntq2IMbehUwdY/BsNOHmNV1szZGTjZMoDwa2nI1YrzNugANqrwSZDAk7oSweh2LnR0gsUuMjtVJGPi5C5N3/MAOq6UbPnaa+VvN4u7DnUI0Q0CX72OC01nEu+fjXpkZ3AkjvJIWqZZ1pR2L11T9h+TYRDOvd2knm2cis= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774665220; c=relaxed/simple; bh=GbYsGFUz53sxp31naVX04CFsRnYEeuD9QeDh3UQuAQg=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=iLmBTl6GSJ9raJ0e22E3TOQd7Hp9Zbk1xneLi7SndUKT7Ll+FIfNXomBQD51bxz5gHqX/6yZs/4tq4ToK+Jf/QYPluCOkO2r22hdv45brUJHPmKl+wZUSiRdM9owJQt0keBIjRlDUSAFU2ABxLHH3n3I7zoFEkmWNVmhy6Nyeyo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=CC29H8Vb; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="CC29H8Vb" Received: from [172.27.2.41] (c-76-133-66-138.hsd1.ca.comcast.net [76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 62S2165l363187 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 27 Mar 2026 19:01:07 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 62S2165l363187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026032601; t=1774663269; bh=Yp8Fyo5M8Vj02q5q1+pCFq2RfSFT3VFiRhl9hjFAt8k=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=CC29H8Vbd00+cl/O9g+GlqjzVnUuGdvAS4oscXbda87Uvdsep05dYFyQOGZKK0mtC QHhoMVlY6oCGV8ReX8xXhTv5ONWdekBZhGIn/jfyH/JBF5B7Pu8DppWsgir/4SQtDH ptfP5V606X3kIWiLOgfCDKkPn3yd7TOq6zMkg1+cdAxfWmV+hLa7LoMEuoqrZpfEIX fHUK33Rke1/T+Oo6DnTfDc2+IzxeX8fBSGm6fq/ptkMZGK0YFLfRFL4pYBk9T0Krra /o4Oeh5/JttStZVvRNgesrvw/kwff6+aiXhgbapZiO30Hp1nFRCL7CaMJs4KW+uqJi Kb930C3+YHd9g== Message-ID: <4389fd82-e5a3-487f-9166-5bd2f3a434e3@zytor.com> Date: Fri, 27 Mar 2026 19:01:01 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 3/4] x86/cpu: Do a sanity check on required feature bits From: "H. Peter Anvin" To: Maciej Wieczor-Retman , Pawan Gupta Cc: 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 References: <7312c9f2feab8aea4612ed9a1841e8c22f5f69b1.1774008873.git.m.wieczorretman@pm.me> <20260321003015.4i7wrqmaunbljguw@desk> <20260326190430.i4dt2dxqpfzwlhcc@desk> Content-Language: en-US, sv-SE In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2026-03-27 18:52, 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*. The simplest way to deal with it is probably to require NCAPINTS > and NBUGINTS to be even, even (pun intended) if that means a temporarily > unused word at the end of the array. That doesn't even require any code > changes, just a statement at the top of cpufeatures.h (see attached patch for > an untested example.) > Untested indeed. I just realized this breaks cpufeaturemasks.awk: # Note: this blithely assumes that each word has at least one # feature defined in it; if not, something else is wrong! -hpa