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 -- 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>