On Tue, Jul 01, 2014 at 05:32:09PM -0400, Jerome Glisse wrote: > On Tue, Jul 01, 2014 at 11:06:20PM +0200, Joerg Roedel wrote: > > On Tue, Jul 01, 2014 at 03:33:44PM -0400, Jerome Glisse wrote: > > > On Tue, Jul 01, 2014 at 01:00:18PM +0200, Joerg Roedel wrote: > > > > No, its not in this case. The file descriptor is used to connect a > > > > process address space with a device context. Thus without the mappings > > > > the file-descriptor is useless and the mappings should stay in-tact > > > > until the fd is closed. > > > > > > > > It would be a very bad semantic for userspace if a fd that is passed on > > > > fails on the other side because the sending process died. > > > > > > Consider use case where there is no file associated with the mmu_notifier > > > ie there is no device file descriptor that could hold and take care of > > > mmu_notifier destruction and cleanup. We need this call chain for this > > > case. > > > > Example of such a use-case where no fd will be associated? > > > > Anyway, even without an fd, there will always be something that sets the > > mm->device binding up (calling mmu_notifier_register) and tears it down > > in the end (calling mmu_notifier_unregister). And this will be the > > places where any resources left from the .release call-back can be > > cleaned up. > > > > That's the whole point we can not do what we want without the callback ie > the place where we do the cleanup is the mm callback we need. If you do not > like the call chain than we will just add ourself as another caller in the > exact same spot where the notifier chain is which Andrew disliked because > there are already enough submodule that are interested in being inform of > mm destruction. > > Cheers, > Jérôme Joerg do you still object to this patch ? Knowing that we need to bind the lifetime of our object with the mm_struct. While the release callback of mmu_notifier allow us to stop any further processing in timely manner with mm destruction, we can not however free some of the associated resources namely the structure containing the mmu_notifier struct. We could schedule a delayed job to do it sometimes after we get the release callback but that would be hackish. Again the natural place to call this is from mmput and the fact that many other subsystem already call in from there to cleanup there own per mm data structure is a testimony that this is a valid use case and valid design. This patch realy just try to allow new user to easily interface themself at proper place in mm lifetime. It is just as the task exit notifier chain but i deals with the mm_struct. You pointed out that the cleanup should be done from the device driver file close call. But as i stressed some of the new user will not necessarily have a device file open hence no way for them to free the associated structure except with hackish delayed job. So i do not see any reasons to block this patch. Cheers, Jérôme -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>