On Fri, 2014-07-04 at 01:15 +0200, Joerg Roedel wrote: > Hi Jerome, > > On Thu, Jul 03, 2014 at 02:30:26PM -0400, Jerome Glisse wrote: > > Joerg do you still object to this patch ? > > Yes. > > > 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. > > Device drivers are something different than subsystems. I think that hsa (kfd) and hmm _are_ subsystems, if not in definition than in practice. Our model is not a classic device-driver model in the sense that our ioctl's are more like syscalls than traditional device-driver ioctls. e.g our kfd_open() doesn't open a kfd device or even a gpu device, it *binds* a *process* to a device. So basically, our ioctls are not related to a specific H/W instance (specific GPU in case of kfd) but more related to a specific process. Once we can agree on that, than I think we can agree that kfd and hmm can and should be bounded to mm struct and not file descriptors. Oded > I think the > point that the mmu_notifier struct can not be freed in the .release > call-back is a weak reason for introducing a new notifier. In the end > every user of mmu_notifiers has to call mmu_notifier_register somewhere > (file-open/ioctl path or somewhere else where the mm<->device binding is > set up) and can call mmu_notifier_unregister in a similar path which > destroys the binding. > > > 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. > > Please tell me more about these 'new users', how does mm<->device binding > is set up there if no fd is used? > > > Joerg > > ��.n������g��� �a��� �&ޖ)���)��h���&������梷���� �Ǟ�m������)������^�����������v���O��zf������