On Fri, Jan 11, 2019 at 2:03 PM Jane Chu <[email protected]> wrote: > > On 1/11/2019 1:54 PM, Luck, Tony wrote: > > > Jane, > > > > It does look a bit fishy. But if there is an issue with “memdev” > > changing once we release the locks, > > > > then it will only help a little to move the “*flags = memdev->flags” > > back before we release the locks. > > > > Note that we access memdev one more time with the “return > > memdev->physical_id” > > > Indeed, that line too. > > > But I’m not at all sure what the possible races are here. I hope > > someone from the linx-nvdimm list > > > > can comment. I think I just cut & pasted the bulk of those nested > > loops from elsewhere. As far as I > > > > know we don’t currently have any support for hotplug NFIT devices, so > > I suspect there is currently > > > > no race here. > > > I don't understand the bulk of the code, just trying to follow what you said > here. So if we *ever* decide to support hotplug NFIT device, what would > remind > us to close the race here? Is there any harm to reference memdev while we > still have the locks?
No harm in fixing it up, I'd take that patch if you wrote it up. There is potentially a race today if the kernel was calling this routine, but some other thread was doing: echo "ACPI0012:00" > /sys/bus/acpi/drivers/nfit/unbind _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
