On Thu, Apr 19, 2018 at 05:47:51PM -0400, Jerome Glisse wrote: > On Thu, Apr 19, 2018 at 10:21:37PM +0100, Al Viro wrote: > > 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. > > Yes and that's fine, on close(fd) the device driver is tear down No, it is not. _NOTHING_ is done on that close(fd), other than removing a reference from descriptor table. In this case struct file is still open and remains such until munmap(). That's why descriptor table is a very bad place for sticking that kind of information. Besides, as soon as your syscall (ioctl, write, whatever) has looked struct file up, the mapping from descriptors to struct file can change. Literally before fdget() has returned to caller. Another thread could do dup() and close() of the original descriptor. Or just plain close(), for that matter - struct file will remain open until fdput(). > and > struct i want to store is tear down too and free. So do a hash table indexed by pair (void *, struct mm_struct *) and do lookups there... And use radeon_device as the first half of the key. Or struct file *, or pointer to whatever private data you maintain for an opened file...
