lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1442ea88-ae86-4ffa-9c79-13879d729bd8@zohomail.com>
Date: Fri, 16 Jan 2026 17:54:13 +0800
From: Li Ming <ming.li@...omail.com>
To: Alison Schofield <alison.schofield@...el.com>, dave.jiang@...el.com
Cc: dave@...olabs.net, jonathan.cameron@...wei.com, vishal.l.verma@...el.com,
 ira.weiny@...el.com, dan.j.williams@...el.com, linux-cxl@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] cxl/acpi: Fix using extra xormaps for address
 translation


在 2026/1/16 01:56, Alison Schofield 写道:
> On Thu, Jan 15, 2026 at 09:16:48PM +0800, Li Ming wrote:
>> CXL r3.1 Table 9-22 defines a fixed number of XOR maps for interleave
>> arithmetic based on the number of interleave ways, as reflected by
>> hbiw_to_nr_maps[].
>>
>> The current implementation applies all XOR maps during address
>> translation, but it should use the spec-defined number of XOR maps
>> derived from the number of interleave ways.
>>
>> Fixes: 3b2fedcd75e3 ("cxl: Restore XOR'd position bits during address translation")
>> Signed-off-by: Li Ming <ming.li@...omail.com>
> Ming,
>
> I previously sent similar patch and then recalled it for the reason
> described in this thread.
> https://lore.kernel.org/linux-cxl/26c7ca6f-eb5f-4f20-8dba-e62e43e3e1b5@intel.com
>
> The above was all before
> 	"4fe516d2ad1a6 cxl/acpi: Make the XOR calculations available for testing"
> where I added input param checking and introduced nr_maps_to_apply.
>
> I don't think it is necessary to use nr_maps_to_apply in the
> for loop once the params have been validated. So maybe this patch
> is a cleanup on commit 4fe516d2ad1a6 rather than a fix.
>
> Please take a look again and let me know if I'm wrong again ;)
>
> --Alison

Hi Alison,


Thanks for pointing it out, you are right, it is not a bug. After 
reviewing cxl_parse_cxims(), the cxmisd->xormaps stores the correct 
number of xor maps based on the interleave ways. In fact, 
nr_maps_to_apply is equal to cximsd->nr_maps in cxl_do_xormap_calc(), So 
it is not needed to change it.


Hi Alison and Dave,


Please ignore this patch, apologies for the noise.


Thanks

Ming

>
>> ---
>>   drivers/cxl/acpi.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/cxl/acpi.c b/drivers/cxl/acpi.c
>> index 77ac940e3013..5f84d01e7d39 100644
>> --- a/drivers/cxl/acpi.c
>> +++ b/drivers/cxl/acpi.c
>> @@ -61,7 +61,7 @@ u64 cxl_do_xormap_calc(struct cxl_cxims_data *cximsd, u64 addr, int hbiw)
>>   	 * bits results in val==0, if odd the XOR result is val==1.
>>   	 */
>>   
>> -	for (int i = 0; i < cximsd->nr_maps; i++) {
>> +	for (int i = 0; i < nr_maps_to_apply; i++) {
>>   		if (!cximsd->xormaps[i])
>>   			continue;
>>   		pos = __ffs(cximsd->xormaps[i]);
>> -- 
>> 2.34.1
>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ