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? ...and the splat is the same hmem_resource lock entanglement?
