On Thu, Apr 19, 2018 at 04:58:20PM -0400, Jerome Glisse wrote:
> I need a struct to link part of device context with mm struct for a
> process. Most of device context is link to the struct file of the
> device file (ie process open has a file descriptor for the device
> file).
Er... You do realize that
fd = open(...)
mmap(fd, ...)
close(fd)
is absolutely legitimate, right? IOW, existence/stability/etc. of
a file descriptor is absolutely *not* guaranteed - in fact, there might
be not a single file descriptor referring to a given openen and mmaped
file.
> Device driver for GPU have some part of their process context tied to
> the process mm (accessing process address space directly from the GPU).
> However we can not store this context information in the struct file
> private data because of clone (same struct file accross different mm).
>
> So today driver have an hashtable in their global device structure to
> lookup context information for a given mm. This is sub-optimal and
> duplicate a lot of code among different drivers.
Umm... Examples?
> Hence why i want something generic that allow a device driver to store
> context structure that is specific to a mm. I thought that adding a
> new array on the side of struct file array would be a good idea but it
> has too many kludges.
>
> So i will do something inside mmu_notifier and there will be no tie to
> any fs aspect. I expect only a handful of driver to care about this and
> for a given platform you won't see that many devices hence you won't
> have that many pointer to deal with.
Let's step back for a second - lookups by _what_? If you are associating
somethin with a mapping, vm_area_struct would be a natural candidate for
storing such data, wouldn't it?
What do you have and what do you want to find?
