Re: bo block user mapping

[Jerome G. <gl...@fr...>]

Thomas Hellström wrote:
> Jerome Glisse wrote:
>> Thomas Hellström wrote:
>>> Jerome Glisse wrote:
>>>> Hi,
>>>>
>>>> Got a question about buffer mapping is it possible to block user space
>>>> from mapping a buffer that was previously allocated. My use case is
>>>> to have user space allocate a buffer put things into it then register
>>>> this buffer (with need for user space to first unmap it) through device
>>>> specific ioctl and in this ioctl forbid all user space to map this 
>>>> buffer.
>>>> Does this sounds possible with current infrastructure (i am looking
>>>> through code but i still don't understand it all :)) ?
>>>>
>>>>   
>>> It's not implemented yet, but in principle it wouldn't be too hard to 
>>> temporarily block user-space
>>> from accessing a buffer:
>>>
>>> 1) Call drm_bo_unmap_virtual( bo) to remove all user-space mappings.
>>> 2) The next time the buffer is accessed by user-space, it will 
>>> page-fault in drm_bo_vm_nopfn,
>>>     where the buffer-object is available. Here we could implement an 
>>> interruptible wait for buffer_block,
>>>     possibly indicated in one of the bo flags. Each buffer object 
>>> already has an "event" wait queue that we could use.
>>>     When the buffer_block flag is clear, just issue a 
>>> wake-on-interruptible on the bo event queue.
>>
>> I was thinking of definitely blocking all mapping, ie the buffer won't
>> able to get mapped anymore.
> Ok, then you would need to take a look at
> 
> drm_bo_takedown_vm_locked(bo)


Will take a look at that, thanks for the pointer :)

> 
> which deregisters a buffer object from the vm system.
> User buffers and kernel-only buffers already use this facility.
> 
>>
>>>> Side question can then i also block user space from unreference the 
>>>> buffer
>>>> as i might also would like to take over buffer management.
>>>>
>>>>   
>>> Hmm, not really? What if the user process dies?
>>> /Thomas
>>
>> If process dies the file descriptor it has on the drm module is closed
>> right ? Then i could do the cleanup there and unreference all buffers
>> which this process was using and that got handled over through this
>> driver specific ioctl.
>>
>> Btw as i want to be able to block mapping a solution to my problem
>> would be to allocate a buffer in this specific ioctl copy over the
>> data from the original buffer and unreference the original buffer or
>> let user space deal with the unreferencing.
>>
>> Also does reference store how many times a process have referenced
>> a buffer ? The idea is that if the process dies badly we will have
>> to decrement the reference by the number of times the process references
>> buffer.
>>
> This is already taken care of in the drm_release() function, That is, if 
> a user-process dies,
> all its buffer references and mappings are freed. I thought you wanted 
> to disable that
> functionality as well.
> 
> However, I don't understand why you would want to block a process from 
> being able to
> dereference a buffer object?
> 
> /Thomas
> 

As user space won't be able to map buffer anymore i did think it makes
sense to takeover buffer responsibility (ie free it once we know its
not used anymore whether it's because process dies or because this
is just not used anymore).

Cheers,
Jerome Glisse