On Thu, Apr 19, 2018 at 12:56:37PM -0700, Matthew Wilcox wrote: > On Thu, Apr 19, 2018 at 03:31:08PM -0400, Jerome Glisse wrote: > > > > Basicly i want a callback in __fd_install(), do_dup2(), dup_fd() and > > > > add void * *private_data; to struct fdtable (also a default array to > > > > struct files_struct). The callback would be part of struct file_operations. > > > > and only call if it exist (os overhead is only for device driver that > > > > care). > > > > > > > > Did i miss something fundamental ? copy_files() call dup_fd() so i > > > > should be all set here. > > > > > > > > I will work on patches i was hoping this would not be too much work. > > > > Well scratch that whole idea, i would need to add a new array to task > > struct which make it a lot less appealing. Hence a better solution is > > to instead have this as part of mm (well indirectly). > > It shouldn't be too bad to add a struct radix_tree to the fdtable. > > I'm sure we could just not support weird cases like sharing the fdtable > without sharing the mm. Does anyone actually do that? Well like you pointed out what i really want is a 1:1 structure linking a device struct an a mm_struct. Given that this need to be cleanup when mm goes away hence tying this to mmu_notifier sounds like a better idea. I am thinking of adding a hashtable to mmu_notifier_mm using file id for hash as this should be a good hash value for common cases. I only expect few drivers to need that (GPU drivers, RDMA). Today GPU drivers do have a hashtable inside their driver and they has on the mm struct pointer, i believe hash mmu_notifier_mm using file id will be better. Jérôme
