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 381B32405E7 for ; Fri, 6 Mar 2026 02:59:58 +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=1772765999; cv=none; b=ikS5Vyiu8+2JMDRHtJjPOYjkj9YW3W8tSGz4boUSM6YY1GeLJoPFr5qmIkA1cwgVP901eop3E+90inqiwH/MHWSm7gDuxI6rmrGZm36vP7MIRwLIsMlRT87JMgxyyF0k/Z0ZqnWT0E5gG8gVEBoyWAiJpWR6L+hx7Yox0a0FSC0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772765999; c=relaxed/simple; bh=aVX2lKOKKG8kx9lFNTPxlAb94bzi8B0Ug6CM4pLwW6c=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=WtgujoSxEYrjrwTy+TU/zikK7AhmHlWoR927IpClbQkpus7/wQ3fNhrwRSNuszgH2kEyGemDl6ZTPww0e5RfUTZVFQN/EnAnk6ltHpla0vB/3wirBlN82ibNzujjRzttYmuAGB06qlTNzwSJpieIqIi5sOo52GFihMkZF1fFYOg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=JNVoKZq5; arc=none smtp.client-ip=192.198.163.14 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="JNVoKZq5" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772765998; x=1804301998; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=aVX2lKOKKG8kx9lFNTPxlAb94bzi8B0Ug6CM4pLwW6c=; b=JNVoKZq5qdZHvPMnoXEVvD4KLJUyWxwgw9ws1yCmQ41YMsHI6qTg1chz WGLZbzigKFChsrrei4qsC0PewlzvfX5VZMhANnlMK/NrtpxrjfbTTq1uC dgcLW0CeWfZOHfV4KHnTH3mfEfjyJxoOAUyjv0fO3wFQFWaUNCxs54Upj Uzj7jSDWJlIBHa5udhmN26ejPgAWul4lCWXrFJLWfQLF0IPuFcw8iMHzG 2pO5C9WESdRc3QJU8scrvuJShHeuWpWkNSyf/9OQhjl5nm3r6P7HLvJMQ Ff6/8xq2ADbLH7JNfQKlX5lq1e7MI4avziMnBSwcgjNuDvHqk9r05xvWr A==; X-CSE-ConnectionGUID: 3u0ujgDlQEu78ZSSN9blsw== X-CSE-MsgGUID: cTScZ2eyRS6oNKkobm+4kA== X-IronPort-AV: E=McAfee;i="6800,10657,11720"; a="73946860" X-IronPort-AV: E=Sophos;i="6.23,104,1770624000"; d="scan'208";a="73946860" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa108.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Mar 2026 18:59:58 -0800 X-CSE-ConnectionGUID: mXKqM1G1QYupaIvHjex3UA== X-CSE-MsgGUID: BcrfKB9rQK2vx7flnXeHoA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,104,1770624000"; d="scan'208";a="215606474" Received: from unknown (HELO [10.238.1.107]) ([10.238.1.107]) by fmviesa006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Mar 2026 18:59:56 -0800 Message-ID: <9ef5afa2-18d8-4076-98ec-5571969aca31@intel.com> Date: Fri, 6 Mar 2026 10:59:53 +0800 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 0/2] x86/split_lock: Fix and cleanup of cpu_model_supports_sld To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org Cc: "H. Peter Anvin" , Tony Luck , linux-kernel@vger.kernel.org References: <20251218080044.2615106-1-xiaoyao.li@intel.com> Content-Language: en-US From: Xiaoyao Li In-Reply-To: <20251218080044.2615106-1-xiaoyao.li@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/18/2025 4:00 PM, Xiaoyao Li wrote: > While considering Kiryl's suggestion[1], I'm wondering why we have > cpu_model_supports_sld defined, which seems like it could be replaced by > X86_FEATURE_SPLIT_LOCK_DETECT. > > Tracing through the history, I find that X86_FEATURE_SPLIT_LOCK_DETECT > originally indicated whether the kernel enabled the split lock detection > feature, rather than enumerating hardware support for the feature, at the > time when cpu_model_supports_sld was introduced. > > Now, the semantics of X86_FEATURE_SPLIT_LOCK_DETECT have changed and > it enuemrates the hardware support for the feature. Therefore, patch 2 > replaces cpu_model_supports_sld with X86_FEATURE_SPLIT_LOCK_DETECT. > > Patch 1 fixes a potential issue where MSR_TEST_CTRL can be written when > the split lock detection feature is not available, which can cause bizarre > behavior. Ping on this series. (It applies cleanly on v7.0-rc2) > [1] https://lore.kernel.org/all/lvobu4gpfsjg63syubgy2jwcja72folflrst7bu2eqv6rhaqre@ttbkykphu32f/ > > Xiaoyao Li (2): > x86/split_lock: Fix handling in split_lock_init() > x86/split_lock: Drop cpu_model_supports_sld > > arch/x86/kernel/cpu/bus_lock.c | 14 ++++---------- > 1 file changed, 4 insertions(+), 10 deletions(-) >