On Fri, 2022-07-08 at 15:43 +0200, Thomas Hellström wrote: > > The vm_bind/bound_list and the non_priv_vm_bind_list are there for > > very different reasons. > > > > The reason for having separate vm_bind_list and vm_bound_list is > > that > > during the execbuf path, we can rebind the unbound mappings by > > scooping > > all unbound vmas back from bound list into the bind list and > > binding > > them. In fact, this probably can be done with a single vm_bind_list > > and > > a 'eb.bind_list' (local to execbuf3 ioctl) for rebinding. > > > > The non_priv_vm_bind_list is just an optimization to loop only > > through > > non-priv objects while taking the locks in > > eb_lock_persistent_vmas() > > as only non-priv objects needs that (private objects are locked in > > a > > single shot with vm_priv_lock). A non-priv mapping will also be in > > the > > vm_bind/bound_list. > > > > I think, we need to add this as documentation to be more clear. > > OK, I understood it as private objects were either on the vm_bind > list > or vm_bound_list depending on whether they needed rebinding or not, > and > shared objects only on the non_priv_vm_bind list, and were always > locked, validated and fenced... > > Need to take a deeper look... > > /Thomas > > > > > > > Niranjana > > > >
Hmm. Just a quick thought on this, Since the non-private vm-bind objects all need to be iterated through (locked and fenced and userptr valid) on each execbuf, and checking for validation (resident and bound) is a very quick check, then we'd never need to add them to the rebind list at all, right? If so the rebind list would be exclusive to vm-private objects. Also I don't think the vm_bind list can be execbuf-local, since binding may not have completed at vma_release time, at which point the objects need to remain on the vm_bind list until the next execbuf... /Thomas
