This looks good to my eye. Don't know if it will work...

Nice, that it works.

Thanks!

Adding jkim@ as a review and subscriber.

Update patch to ports tree r453973

Update diff to latest ports tree snapshot.

Removed wrong stanza modifying OPTIONS_DEFAULTS depending on external variable.

Thanks for the heads up!

Updated patch.

destroy_dev() will make sure all system calls have returned. In your patch are you destroying the device first?

Thank you.

Make a test app like this:

I'm afraid that pending read/write/ioctls might use freed structures. I'll try to analyze your patch carefully next week. Currently at bsdcan2017 .

No.
How I can check mem use after free and how turn on mem debug?

Did you check that no memory is used after free?

Replaced by populate, which although it still insists on doing a great deal of accounting not needed for device mappings (COW cargo culting AFAICT) that complicates mapping the same device memory at different VAs - it is quite close to what is expected by graphics drivers. Thanks go to Kostik and Alan.

In D6620#181218, @emaste wrote:

Related change in rS309710, rS309712

Related change in rS309710, rS309712

@kib To clarify: I only need 1 change to the VM and that is provided by your patch. I abandoned the other revision changing the device pager interface. Everything else is handled out of tree in the (soon to be) ports linuxkpi.

In D6620#140369, @kib wrote:

In D6620#140367, @kmacy wrote:

Why cannot you just install all pages into the object queue at once ?

In D6620#140367, @kmacy wrote:

Why cannot you just install all pages into the object queue at once ? I do not understand why do you want to also force-map them into userspace simultaneously. The difference would be in soft-faults indeed. But softfaults in vm_fault() would only result in looking up the page and installation of pte, without even touching the pager. More, I believe (but did not verified) that softfault would be handled by the vm_fault() 'fast path', which allows simultaneous faults handling (the object is read-locked).

This is the core of the i915_gem_fault routine. You will notice how it calls vm_insert_pfn for every page in the view - which in my testing can be as many as 1030+ pages.

If by aperture you mean the mappable portion of GTT, I in fact do not see why you statement is true. More, from what I remember from the times when I had to work on that code, it is in fact can be mapped more than once.

In D6620#140319, @kmacy wrote:

Passing the mapping address is the huge layering violation. Digging the curproc map to find the faulting address is even larger one. What would happen if there is already another mapping in the same map for the same object ?

You would never have the same aperture mapped twice, and if you did it would not have any adverse effect. We really to need stop conflating device memory's behavior with RAM.

Passing the mapping address is the huge layering violation. Digging the curproc map to find the faulting address is even larger one. What would happen if there is already another mapping in the same map for the same object ?

You would never have the same aperture mapped twice, and if you did it would not have any adverse effect. We really to need stop conflating device memory's behavior with RAM.

In D6620#140142, @kmacy wrote:

I can find the entry by searching the map for the object at fault time. This gives me the start of the mapping. I can then cache that start and cache the map address to look up a new entry if a second process maps the device. In the instances where the driver's fault routine returns more than one page I can simply call pmap_enter_object after all the pages have been added to the object.
In summary, the only ABI change I need to is to permit the fault routine to manage devp_pglist (along with passing down the actual fault type).

Switch to kib's patch, dropping the changes to VOP_GETPAGES

It looks like there's no clean way to work backwards from an object to a map_entry. Admittedly, it would be a bit of a layering violation and would cause problems for aliasing. Perhaps rather than pass in count and *rahead we can pass in the actual fault address?

It occurs to me that if I can identify the virtual address that the object starts at I don't actually need to change the device pager ABI beyond adding a new OBJ type to indicate that the fault routine will manage the pglist itself. If the fault routine knows the actual base of where the object is being mapped it can insert the additional mappings itself. Additionally, it means the VM doesn't need to learn that COW is not relevant to device memory.

In D6620#140020, @kib wrote:

I revived my patch, it grown several mis-merges from the time of being written.
Main differences from yours is the use of VM_PROT_ALL for other places, and keeping VOP_GETPAGES() interface. I do not see it useful to pass fault type to VOP.
https://kib.kiev.ua/kib/cdev_prot.1.patch

I revived my patch, it grown several mis-merges from the time of being written.

This patch doesn't include the necessary update to md and tmpfs. If there's any chance of it going in as is I will update the patch.