Messages in this thread | | | Date | Fri, 20 May 2022 13:18:52 +0800 | Subject | Re: [RFC PATCH] mm, pmem, xfs: Introduce MF_MEM_REMOVE for unbind | From | Shiyang Ruan <> |
| |
在 2022/4/11 15:06, Christoph Hellwig 写道: > On Mon, Apr 11, 2022 at 01:16:23AM +0800, Shiyang Ruan wrote: >> diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c >> index bd502957cfdf..72d9e69aea98 100644 >> --- a/drivers/nvdimm/pmem.c >> +++ b/drivers/nvdimm/pmem.c >> @@ -359,7 +359,6 @@ static void pmem_release_disk(void *__pmem) >> struct pmem_device *pmem = __pmem; >> >> dax_remove_host(pmem->disk); >> - kill_dax(pmem->dax_dev); >> put_dax(pmem->dax_dev); >> del_gendisk(pmem->disk); >> >> @@ -597,6 +596,8 @@ static void nd_pmem_remove(struct device *dev) >> pmem->bb_state = NULL; >> } >> nvdimm_flush(to_nd_region(dev->parent), NULL); >> + >> + kill_dax(pmem->dax_dev); > > I think the put_dax will have to move as well.
After reading the implementation of 'devm_add_action_or_reset()', I think there is no need to move kill_dax() and put_dax() into ->remove().
In unbind, it will call both drv->remove() and devres_release_all(). The action, pmem_release_disk(), added in devm_add_action_or_reset() will be execute in devres_release_all(). So, during the unbind process, {kill,put}_dax() will finally be called to notify the REMOVE signal.
In addition, if devm_add_action_or_reset() fails in pmem_attach_disk(), pmem_release_disk() will be called to cleanup the pmem->dax_dev.
-- Thanks, Ruan.
> > This part should probably also be a separate, well-documented > cleanup patch.
| |