From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.14]) (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 67BDF379996 for ; Mon, 30 Mar 2026 16:01:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.14 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774886518; cv=none; b=J9YgQ4NlrqXjOOUntGOOS4bbg2X7O7GtaixeM5EsigMNBe9Yy2m5BIGOjv7PQZNFoVaVZK1M+MM0n+Z60xU5h1mv6CYpBrHv0slL0EV3IWFtQLxZhXyscVNbAa7TN5ifLW1rXVFW5XJUm4zCH2zDYTFXbd1fRQ7MyBc0jjJE8mM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774886518; c=relaxed/simple; bh=NcrURQLPqOQl4le9SA8v3tI37OEAFVCkoBvFbxb3duA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kUEDLkNJ7nhQrOjMeGTrZy3CF+tFXD+gF+8FVoSXxkuN2BUTDQDnhdmqF0ts2JhpG2YxAOW9YvUxSZLvWXti7k77ZpOvwnRhH7GFkJTA+o1tODym0MlRByA98bv5KP1NlnfNOjbNMMdgwwP8clrNQKK1o220LgCiK9HGSr5stEQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=VCH00zfm; arc=none smtp.client-ip=192.198.163.14 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="VCH00zfm" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1774886517; x=1806422517; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=NcrURQLPqOQl4le9SA8v3tI37OEAFVCkoBvFbxb3duA=; b=VCH00zfmkeZQ5om/8UyIbgRYYBL45q73Zeh3WeJhwBSw0gEbQsrY1bWc WA73FY7PSodGzIDDQ7L5jHZ0M1dN7/GI+5ErVEseGZZ3nR1s5y99Hlv6S NK/qB35UzMd+84hiC/RSPN2pFUhUwxiBKYXWpeNNrDpW30SxCnL71za/X Ub43czpJhSj2V0SBKJ7vNnbqut/dw9pImvf1enYas2FO4OThbR3/1oT+F dRwiLxOammSBIY97wWEqbk2w4GdFiRD2rvJ6tl3UgM+uzP53/6td0Lej/ hSttnEcNMhVNdCslDTZd4AtW4CfF1aoIlVQl8F5yDiwYodr8F9D165f/z w==; X-CSE-ConnectionGUID: u7Sjosb5R7i7AikztBRP1g== X-CSE-MsgGUID: wll4COcUTFOjPBWktmYswQ== X-IronPort-AV: E=McAfee;i="6800,10657,11743"; a="75948042" X-IronPort-AV: E=Sophos;i="6.23,150,1770624000"; d="scan'208";a="75948042" Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by fmvoesa108.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Mar 2026 09:01:56 -0700 X-CSE-ConnectionGUID: I/OYvNBpTTCh3OyrI8lFYA== X-CSE-MsgGUID: PhaZDwIxTA25k+OY8dAlgA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,150,1770624000"; d="scan'208";a="222787257" Received: from guptapa-desk.jf.intel.com (HELO desk) ([10.165.239.46]) by fmviesa007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Mar 2026 09:01:51 -0700 Date: Mon, 30 Mar 2026 09:01:44 -0700 From: Pawan Gupta To: Maciej Wieczor-Retman Cc: "H. Peter Anvin" , 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 Subject: Re: [PATCH v11 3/4] x86/cpu: Do a sanity check on required feature bits Message-ID: <20260330160144.ylgrbl7ze7iza2zr@desk> References: <7312c9f2feab8aea4612ed9a1841e8c22f5f69b1.1774008873.git.m.wieczorretman@pm.me> <20260321003015.4i7wrqmaunbljguw@desk> <20260326190430.i4dt2dxqpfzwlhcc@desk> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Mar 30, 2026 at 10:09:47AM +0000, Maciej Wieczor-Retman wrote: > On 2026-03-27 at 18:52:30 -0700, H. Peter Anvin wrote: > >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. > > So setting up something similar to cpu_caps_cleared[] that's initialized with > DISABLED_MASK_INIT - only do that with the required one, and then copy that to a > 64-bit aligned local bitmap-array? > > >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*. > > I think for example the set_bit()/clear_bit() bitops are not problematic while > for_each_set_bit() is, specfically used in this context. Most operations seem to > not affect or not be affected by the potential unaligned 32-bit. And while > briefly looking for other such cases I didn't find anything related to features, > ncapints etc. > > But I agree, a systemic solution like trying to keep NCAPINTS even, would be > better than adding band aids to the issue. Maybe use the below alignment trick: struct cpuinfo_x86 { ... /* * Align to size of unsigned long because the x86_capability array * is passed to bitops which require the alignment. Use unnamed * union to enforce the array is aligned to size of unsigned long. */ union { __u32 x86_capability[NCAPINTS + NBUGINTS]; unsigned long x86_capability_alignment; };