On Tue, Aug 10, 2021 at 6:22 PM Dan Williams <[email protected]> wrote: [..] > > > > What's the concurrency this lock is trying to protect against? > > > > > > I can add a comment. It synchronizes against in-flight ioctl users to > > > make sure that any requests have completed before the policy changes. > > > I.e. do not allow userspace to race the nvdimm subsystem attaching to > > > get a consistent state of the persistent memory configuration. > > > > > > > Ah, so the expectation is that these things will be set not just on > > probe/unregister()? I would assume an IOCTL couldn't happen while > > probe/unregister is happening. > > The ioctl is going through the cxl_pci driver. That driver has > finished probe and published the ioctl before this lockout can run in > cxl_nvdimm_probe(), so it's entirely possible that label writing > ioctls are in progress when cxl_nvdimm_probe() eventually fires. > > The current policy for /sys/bus/nd/devices/nmemX devices are that > label writes are allowed as long as the nmemX device is not active in > any region. I was thinking the CXL policy is coarser. Label writes via > /sys/bus/cxl/devices/memX ioctls are disallowed as long as the bridge > for that device into the nvdimm subsystem is active.
Oh, whoops, the mbox_mutex is not taken until we're deep inside mbox_send. So this synchronization needs to move to the cxl_memdev rwsem. Thanks for the nudge, I missed that.
