On Thu, Sep 01, 2022 at 12:14:25PM -0600, Logan Gunthorpe wrote: > > > > On 2022-09-01 10:42, Greg Kroah-Hartman wrote: > > On Thu, Sep 01, 2022 at 10:32:55AM -0600, Logan Gunthorpe wrote: > >> On 2022-09-01 10:20, Greg Kroah-Hartman wrote: > >>> On Thu, Aug 25, 2022 at 09:24:24AM -0600, Logan Gunthorpe wrote: > >>>> + /* > >>>> + * Removing the alloc attribute from sysfs will call > >>>> + * unmap_mapping_range() on the inode, teardown any existing userspace > >>>> + * mappings and prevent new ones from being created. > >>>> + */ > >>>> + sysfs_remove_file_from_group(&pdev->dev.kobj, &p2pmem_alloc_attr.attr, > >>>> + p2pmem_group.name); > >>> > >>> Wait, why are you manually removing the sysfs file here? It's part of > >>> the group, if you do this then it is gone for forever, right? Why > >>> manually do this the sysfs core should handle this for you if the device > >>> is removed. > >> > >> We have to make sure the mappings are all removed before the cleanup of > >> devm_memremap_pages() which will wait for all the pages to be freed. > > > > Then don't use devm_ functions. Why not just use the manual functions > > instead as you know when you want to tear this down. > > Well we haven't plugged in a remove call into p2pdma, that would be more > work and more interfaces touching the PCI code. Note: this code isn't a > driver but a set of PCI helpers available to other PCI drivers. > Everything that's setup is using the devm interfaces and gets torn down > with the same. So I don't really see the benefit of making the change > you propose. The issue is the classic one with the devm helpers. They do not lend themselves to resource management issues that require ordering or other sort of dependencies. Please do not use them here, just put in a remove callback as you eventually will need it anyway, as you have a strong requirement for what gets freed when, and the devm api does not provide for that well. thanks, greg k-h
