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 4047E2F87B for ; Tue, 31 Mar 2026 00:14:41 +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=1774916083; cv=none; b=IA8g+2D1lQkld/GaukuCvQ7ITRK4I169904vaoz3bf3LbHTKuwX/xIlRFfLxLgZRuvyhvHb9Azf2uhwUrJLS4LdwJPaV7CDcqdfh/RcfP9oqS1pNfl5GXWyTc5kI+FR8mvpWEml7uBAjczA79qhpW21zbVbf/uqFuocNMg22hlU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774916083; c=relaxed/simple; bh=jGd5N3rUy0zSVz7fj0d/EgB0WSvb9kqSBHeTnv45JKw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=u8z5MHkz2eMjI0dwij/RuVmyni4s4u1gvUr67xDYwV3rsHtsXP+O2wppQzmQSLhsly1ebAHR05zy7npAC6Kw94pnUZYc8kfV9zvLJbh0Ri4md6Ya6QhoD+oPCPSwxI0BxJiKOtUktZsSDR/6qoP9tNIiAQ+Y6db8h+FWQHmhh50= 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=dosspBwk; 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="dosspBwk" 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 62UNg9Jh2858585 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 30 Mar 2026 16:42:10 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 62UNg9Jh2858585 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026032601; t=1774914131; bh=Qg8HaNwxiz9wKbwPVi+mdMyNhWy+sVVNdXUf1hmctnY=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=dosspBwkq4OmmtWwio3/pH19vhj3GV7Qcns1VBYdDsuLcMYwrMb6mZ3hWMcKdWabZ wO9FDJ0Ugd6WN0bMWqvk2Laxv5rFart0AaG96/vYNg6mkwdtVJByAgyd7OsUmsvh7f FaHemxoqZy3AkjLIqMpsr3634bSO3F4Sd0lWlqJmodjzy4nTUJgzL3fnQpPPNmXWDt vwCJjhV2fz8IcyBfFGZNwftrJLyVy8ZEnHBJvG1ko7pARoUY2VmUz0w8Re9Gu/NuZk yCytnge+Tioic7WmgjGteKkVCgEJZkhU4kiZfGpby53NjesRrpYLYchOUBo9gobrVM sJ3JVEv6Ip8og== Message-ID: <5dda018c-9d7d-47ca-a414-cf2593813042@zytor.com> Date: Mon, 30 Mar 2026 16:42:04 -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 2/4] x86/cpu: Check if feature string is non-zero To: Borislav Petkov Cc: Maciej Wieczor-Retman , 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, linux-kernel@vger.kernel.org, x86@kernel.org References: <20260330200045.GUacrWbcsBhp9a-kfb@fat_crate.local> <20260330211511.GIacrn373-FN3Yy_p4@fat_crate.local> <3CFC48BC-615C-4A39-A660-2B348DF13B9E@zytor.com> <20260330225915.GKacsAQ6o_LuNY0hbc@fat_crate.local> Content-Language: en-US, sv-SE From: "H. Peter Anvin" In-Reply-To: <20260330225915.GKacsAQ6o_LuNY0hbc@fat_crate.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 2026-03-30 15:59, Borislav Petkov wrote: > On Mon, Mar 30, 2026 at 02:44:56PM -0700, H. Peter Anvin wrote: >> The Right Thing™ would be to have a table in the kernel which includes *all* >> the feature bit names, not just the ones exported to /proc/cpuinfo, and use >> the unfiltered string table for kernel messages (/proc/cpuinfo being >> filtered via a bitmask, list, or a flag in the table.) > > Meh, not convinced. Not sure it is worth the effort and bloating if we can > simply look up the feature from word and bit number. > Bloating? Drop in the bucket compared to other kernel messages. Getting kernel messages in cleartext is a good thing. It's testing a flag... not exactly complicated, just didn't want Maciej to complicate this one patchset with it. -hpa