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 0F1D533FE27 for ; Sat, 28 Mar 2026 02:39:16 +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=1774665558; cv=none; b=PouAsmsJcZp2G6hRlmRAHqRPkklGUPgra5fjKC5vQc9ZvxsuDTvK7fkSFPwnLW/8WSrglp4eOarcHtIRkCgWFkF/dLHgPfxUd0DWMxDlXvglqd8t35AYyzQ6xEMV/dOX4COtbGGuVP7DNXvrTOQ0EeafIMFpSD2TVAp+a5URhi0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774665558; c=relaxed/simple; bh=dbURGEGYfdmOdekl0UthkCrgI1LlSsU9SaCAsgUn36U=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=tfsjto/kSaRCDJsu40EVnT4+nhTBj3jr8E4TUcI5bx8JkMCzN1ICtEXSXYaGsm/V+esgukeVpORSy5ZYZl+A40m6OXPeLAnqeVlcqRx8k8+BJrDsqpzDXHl3Qebersc/rRBTQg20+JTRhHjnqOeMUYpcyUQ08WYe7kP7Xnua4Ic= 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=MVkhXi4/; 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="MVkhXi4/" 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 62S2MW2s396272 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 27 Mar 2026 19:22:33 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 62S2MW2s396272 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026032601; t=1774664554; bh=oZyXVT63lT08pwdlALQuLcThi2V4J8CmDP0dm4X8ugA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=MVkhXi4/HrY5OLhpp3Xh1H4OhFSMLrwZS0TgQdYzSBqlo6MPno1fSCFzC2yhMyf1p gUEgiu9qjlqGS1z1kI0E9scM5BAd2BNfeO0NRui0G6El7lDT2sTkGpB//7sqxJqthZ p7h1QWcDpWXgybtsxwGm5vrEzewtneA5kTnMJtLERzXG1fFIaGYzY9UnPYgVKSv0Q4 AzzqaiX+8FixMUTa/vc9F3gC8cz4ZdmTWq6yzfLPofIRp+5Gztl/EOW3Pg0LWYY6vB 9jyzQvp9r3Cpeh61QtyFDuzc+lFjXwT8Tbiw+Eq02wKiPajH8arfMHDLqy1F1i9dez 1FK2vodA1E9Cw== Message-ID: Date: Fri, 27 Mar 2026 19:22:27 -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 v12 4/4] x86/cpu: Clear feature bits whose dependencies were cleared To: Maciej Wieczor-Retman , bp@alien8.de, dave.hansen@linux.intel.com, xin@zytor.com, chang.seok.bae@intel.com, mingo@redhat.com, elena.reshetova@intel.com, maciej.wieczor-retman@intel.com, babu.moger@amd.com, sohil.mehta@intel.com, pawan.kumar.gupta@linux.intel.com, pmladek@suse.com, nik.borisov@suse.com, ptesarik@suse.com, darwi@linutronix.de, tglx@kernel.org, peterz@infradead.org, jpoimboe@kernel.org, ak@linux.intel.com Cc: linux-kernel@vger.kernel.org, x86@kernel.org References: <48fda57397205a062b752e37e63948fa668946f7.1774623092.git.m.wieczorretman@pm.me> Content-Language: en-US, sv-SE From: "H. Peter Anvin" In-Reply-To: <48fda57397205a062b752e37e63948fa668946f7.1774623092.git.m.wieczorretman@pm.me> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2026-03-27 08:11, Maciej Wieczor-Retman wrote: > From: Maciej Wieczor-Retman > > After cpu_caps_cleared[] is initialized with DISABLED_MASK_INIT, > features present in disabled bitmasks are cleared from x86_capability[]. > However features that depend on them and are not part of any disabled > mask are not cleared by anything. They can trigger the warning in > check_cpufeature_deps(), as before both features would show up as > enabled even though they weren't. The uncleared features can also still > falsely show up in /proc/cpuinfo. > > Take such cases into account before applying the cpu_caps_cleared[] > array. > > +/* > + * If the dependency was cleared through the disabled bitmasks while the > + * feature wasn't it also needs to be cleared. > + */ > +void clear_feature_disabled_deps(struct cpuinfo_x86 *c) > +{ > + const struct cpuid_dep *d; > + > + for (d = cpuid_deps; d->feature; d++) { > + if (!DISABLED_MASK_BIT_SET(d->feature) && DISABLED_MASK_BIT_SET(d->depends)) > + set_bit(d->feature, (unsigned long *)cpu_caps_cleared); > + } > +} > + Thinking about it, if this is discovered at runtime, it is really too late, because in a sense we have miscompiled the kernel with unwanted code (as we should have compiled out these features just as with other DISABLED features.) This ultimately reflects a failed dependency in Kconfig.cpufeatures, which may have caused kconfig to do the Wrong Thing[TM]. So at the very least it might be a good thing to print a message here saying Kconfig.cpufeatures should be fixed. The better option, which I don't know how difficult it would be, would be to make the dependencies available to Kconfig. This sounds like something that would fall in the scope of Ahmed's rework rather than this patchset, though (Ahmed, would you agree?) -hpa