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 EAD9234C128 for ; Sat, 28 Mar 2026 01:53:21 +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=1774662803; cv=none; b=umrFBdejdA4R8LpnP0ecp8zh3aqdf82h/LGef10DYTjhMyfRY6XqiLnAplwjCPBwQBMsULgzznO1wjjpmT/d2pff/X1KIFYeDQW3rBQiB/lV3YJsOFMGg4z2vWHt3W1WTbYdCmwlpaCX8emlhsAX+bS3YMhFjqZSNlLgKmJx9wY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774662803; c=relaxed/simple; bh=BG70tfelFDhvTQEJlRu7zS8tT5U3EriWBNxIccwtmFE=; h=Content-Type:Message-ID:Date:MIME-Version:Subject:To:Cc: References:From:In-Reply-To; b=jDpx0xFxavvAj79kNRLZKnjiMeQOhiAlpyCavgVkHVLrZx8mc7yHb8w4dOJjyafOMe9X23DzIoVvqJA9IzNhlaNgT4IPYTsxR8bzTDEvvr8i7bQ3V+oYb/49kJAa9+5kgLH3xpZid73SpWrNPm4kDSCLqIRtlY1JB1mnUU0STSA= 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=Bg7rFkZu; 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="Bg7rFkZu" 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 62S1qZ55349912 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 27 Mar 2026 18:52:36 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 62S1qZ55349912 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026032601; t=1774662758; bh=5LMihXrvIMB+ij97/s5JAY1FgSA46Py1lAq6jBINTSs=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Bg7rFkZun74F4ap7+CByOxscCboRr/bmmO1LayV3FrgYlRdcW78EtrXL6hWcViD2U HDp6o02jiX5XWDlxVY7nqJ8/aa8EsfOiU60fqXkcNCXRs4E5kv0cP+hkMC2Y7iTC/6 1zXxPfG736DGOtfTHcQ3nKefJ1e9wN55Vy8aqTW8drebcHT9/j74gDJ28ddHqG2Bjb Wb6DyNFbONxe8zIzF9phXxeOjTC5rk+R9KV+jkp1suETLV7ogK9dkyX2MchRSMoe/F nKgAoM7sJxP+MLNPCaLFLiNEcqc6rsds/4qLxiVqPhyjodhLIMWppKZfi/cwl9BFyB IIrdwMSG8aJzQ== Content-Type: multipart/mixed; boundary="------------Rt6yJokvOiVPCWzzXgSbFGJ0" Message-ID: Date: Fri, 27 Mar 2026 18:52:30 -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 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 From: "H. Peter Anvin" In-Reply-To: This is a multi-part message in MIME format. --------------Rt6yJokvOiVPCWzzXgSbFGJ0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2026-03-26 12:11, Maciej Wieczor-Retman wrote: > On 2026-03-26 at 12:04:30 -0700, Pawan Gupta wrote: >> On Thu, Mar 26, 2026 at 06:36:15PM +0000, Maciej Wieczor-Retman wrote: >>>> Do we need 2 loops? Can this be simplified as below: >>>> >>>> static void verify_required_features(const struct cpuinfo_x86 *c) >>>> { >>>> u32 required_features[NCAPINTS + 1] = REQUIRED_MASK_INIT; >>>> char cap_buf[X86_CAP_BUF_SIZE]; >>>> int i, error = 0; >>> >>> Isn't this [NCAPINTS + 1] still a problem because for_each_set_bit() works in 64 >>> bit chunks? If NCAPINTS becomes an odd number in the future, the >>> required_features[] last 32 bits will be uninitialized - REQUIRED_MASK_INIT is >>> of (NCAPINTS * sizeof(u32)) size. So they might have some bits set and trigger >>> the pr_warn() below. >> >> Isn't a partially initialized array always zeroed out for the uninitialized >> part? > > Ah okay, my bad. Right, it should be okay then. Thanks! > That being said, I would personally like to see an explicit assignment from REQUIRED_MASK_INIT into an automatic variable replaced with a memcpy() from a (possibly static) const array. It might be useful elsewhere, and it would avoid compilers sometimes creating really ugly code. 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.) A more bespoke variant would be to script-generate NCAPINTS and NBUGINTS, but that might have other problems. -hpa --------------Rt6yJokvOiVPCWzzXgSbFGJ0 Content-Type: text/plain; charset=UTF-8; name="diff" Content-Disposition: attachment; filename="diff" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmVzLmggYi9hcmNo L3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlcy5oCmluZGV4IGRiZTEwNGRmMzM5Yi4uY2E5 YWI4YTdhNGVlIDEwMDY0NAotLS0gYS9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJl cy5oCisrKyBiL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmVzLmgKQEAgLTMsMTgg KzMsMzcgQEAKICNkZWZpbmUgX0FTTV9YODZfQ1BVRkVBVFVSRVNfSAogCiAvKgotICogRGVm aW5lcyB4ODYgQ1BVIGZlYXR1cmUgYml0cworICogRGVmaW5lcyB4ODYgQ1BVIGZlYXR1cmUg Yml0cy4KKyAqLworCisvKgorICogTnVtYmVyIG9mIHdvcmRzIG9mIGZlYXR1cmVzIGFuZCBi dWdzLCByZXNwZWN0aXZlbHkuCisgKgorICogVGhlc2Ugc2hvdWxkIGJlIGV2ZW4sIGFzIHRo ZXNlIGFycmF5cyBjYW4gYmUgYWNjZXNzZWQgYnkgYml0bWFzayBvcGVyYXRpb25zIHRoYXQK KyAqIHVzZSAidW5zaWduZWQgbG9uZyIsIHdoaWNoIGlzIDY0IGJpdHMgb24geDg2LTY0Lgor ICoKKyAqIFRoZXNlIG11c3QgYmUgZXhwcmVzc2VkIGFzIGRlY2ltYWwgY29uc3RhbnRzIGFz IHRoZXkgYXJlIHJlYWQKKyAqIGJ5IHNjcmlwdHMuCiAgKi8KICNkZWZpbmUgTkNBUElOVFMJ CQkyMgkgICAvKiBOIDMyLWJpdCB3b3JkcyB3b3J0aCBvZiBpbmZvICovCiAjZGVmaW5lIE5C VUdJTlRTCQkJMgkgICAvKiBOIDMyLWJpdCBidWcgZmxhZ3MgKi8KIAorI2lmIChOQ0FQSU5U UyB8IE5CVUdJTlRTKSAmIDEKKyMgZXJyb3IgIk5DQVBJTlRTIGFuZCBOQlVHSU5UUyBtdXN0 IGJlIGV2ZW4sIGp1c3QgaW5jcmVtZW50IGFueSBvZGQgbnVtYmVyIGJ5IG9uZSIKKyNlbmRp ZgorCiAvKgotICogTm90ZTogSWYgdGhlIGNvbW1lbnQgYmVnaW5zIHdpdGggYSBxdW90ZWQg c3RyaW5nLCB0aGF0IHN0cmluZyBpcyB1c2VkCi0gKiBpbiAvcHJvYy9jcHVpbmZvIGluc3Rl YWQgb2YgdGhlIG1hY3JvIG5hbWUuICBPdGhlcndpc2UsIHRoaXMgZmVhdHVyZQotICogYml0 IGlzIG5vdCBkaXNwbGF5ZWQgaW4gL3Byb2MvY3B1aW5mbyBhdCBhbGwuCisgKiBOb3RlOiBJ ZiB0aGUgY29tbWVudCBiZWdpbnMgd2l0aCBhIHF1b3RlZCBzdHJpbmcsIHRoYXQgc3RyaW5n IGlzCisgKiBkaXNwbGF5ZWQgaW4gL3Byb2MvY3B1aW5mby4gT3RoZXJ3aXNlLCB0aGlzIGZl YXR1cmUgYml0IGlzIG5vdAorICogZGlzcGxheWVkIGluIC9wcm9jL2NwdWluZm8gYXQgYWxs LgorICoKKyAqIFRoaXMgc3RyaW5nIHNob3VsZCBiZSBpbiBsb3dlciBjYXNlIGFuZCBtYXRj aCBDIGlkZW50aWZpZXIgcnVsZXMuCiAgKgogICogV2hlbiBhZGRpbmcgbmV3IGZlYXR1cmVz IGhlcmUgdGhhdCBkZXBlbmQgb24gb3RoZXIgZmVhdHVyZXMsCiAgKiBwbGVhc2UgdXBkYXRl IHRoZSB0YWJsZSBpbiBrZXJuZWwvY3B1L2NwdWlkLWRlcHMuYyBhcyB3ZWxsLgorICoKKyAq IEFzIHRoaXMgZmlsZSBpcyByZWFkIGJ5IHNjcmlwdHMsIHRoZSBmb3JtYXQgb2YgZWFjaCBv ZiB0aGVzZSBsaW5lcworICogbXVzdCBiZSBzdHJpY3RseSBmb2xsb3dlZC4KICAqLwogCiAv KiBJbnRlbC1kZWZpbmVkIENQVSBmZWF0dXJlcywgQ1BVSUQgbGV2ZWwgMHgwMDAwMDAwMSAo RURYKSwgd29yZCAwICovCg== --------------Rt6yJokvOiVPCWzzXgSbFGJ0--