On 10/16/25 12:06 PM, [email protected] wrote:
> Dave Jiang wrote:
> [..]
>>> diff --git a/drivers/acpi/numa/hmat.c b/drivers/acpi/numa/hmat.c
>>> index 5a36d57289b4..9f9f09480765 100644
>>> --- a/drivers/acpi/numa/hmat.c
>>> +++ b/drivers/acpi/numa/hmat.c
>>> @@ -867,6 +867,9 @@ static void hmat_register_target_devices(struct
>>> memory_target *target)
>>> if (!IS_ENABLED(CONFIG_DEV_DAX_HMEM))
>>> return;
>>>
>>> + if (target->registered)
>>> + return;
>>> +
>>
>> So this still triggers the lockdep warning. I don't think it's smart
>> enough to know that it gets around the issue. My changes with a new
>> flag does not trigger the lockdep.
>
> You have a case where target->registered is false in the
> hmat_callback() path? How does that happen?
It seems the ELC nodes are not on CPU node and also not generic port nodes.
This platform has socket 0 and 1 where the memory targets are registered.
However, node 2 and 3 gets hot-plugged and does not target registered at
hmat_callback() time. >
> ...and the splat is the same hmem_resource lock entanglement?
yes
Yes.
