On Thu, Apr 19, 2018 at 01:25:13PM -0700, Matthew Wilcox wrote: > On Thu, Apr 19, 2018 at 04:15:02PM -0400, Jerome Glisse wrote: > > On Thu, Apr 19, 2018 at 12:56:37PM -0700, Matthew Wilcox wrote: > > > > 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. > > file descriptors are small positive integers ... ... except when there's a lot of them. Or when something uses dup2() in interesting ways, but hey - we could "just not support" that, right? > ideal for the radix tree. > If you need to find your data based on the struct file address, then by > all means a hashtable is the better data structure. Perhaps it would be a good idea to describe whatever is being attempted? FWIW, passing around descriptors is almost always a bloody bad idea. There are very few things really associated with those and just about every time I'd seen internal APIs that work in terms of those "small positive numbers" they had been badly racy and required massive redesign to get something even remotely sane.
