Re: [PATCH 1/6] mmput: use notifier chain to call subsystem exit handler.

[Jerome Glisse <j.glisse@gmail.com>]

On Fri, Jul 04, 2014 at 01:15:41AM +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 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?

It could be setup on behalf of another process through others means like
local socket. Thought main use case i am thinking about is you open device
fd you setup your gpu queue and then you close the fd but you keep using
the gpu and the gpu keep accessing the address space.

Further done the lane we might even see gpu code as directly executable
thought that seems yet unreleasistic at this time.

Anyway whole point is that no matter how you turn the matter anything that
mirror a process address is linked to the lifetime of the mm_struct so in
order to have some logic there it is far best to have destruction match
the destruction of mm. This also make things like fork lot cleaner, as on
work the device file descriptor is duplicated inside the child process
but nothing setup child process to keep using the gpu. Thus you might
end up with way delayed file closure compare to parent process mm
destruction.

Cheers,
Jerome


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>