On Tue, Jul 01, 2014 at 01:00:18PM +0200, Joerg Roedel wrote:
> On Tue, Jul 01, 2014 at 09:29:49AM +0000, Gabbay, Oded wrote:
> > In the KFD, we need to maintain a notion of each compute process.
> > Therefore, we have an object called "kfd_process" that is created for
> > each process that uses the KFD. Naturally, we need to be able to track
> > the process's shutdown in order to perform cleanup of the resources it
> > uses (compute queues, virtual address space, gpu local memory
> > allocations, etc.).
> 
> If it is only that, you can also use the task_exit notifier already in
> the kernel.

No task_exit will happen per thread not once per mm.

> 
> > To enable this tracking mechanism, we decided to associate the
> > kfd_process with mm_struct to ensure that a kfd_process object has
> > exactly the same lifespan as the process it represents. We preferred to
> > use the mm_struct and not a file description because using a file
> > descriptor to track “process” shutdown is wrong in two ways:
> > 
> > * Technical: file descriptors can be passed to unrelated processes using
> > AF_UNIX sockets. This means that a process can exit while the file stays
> > open. Even if we implement this “correctly” i.e. holding the address
> > space & page tables alive until the file is finally released, it’s
> > really dodgy.
> 
> 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.

Anyother idea than task_exit ?

Cheers,
Jérôme
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Reply via email to