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) 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 > Cheers, > Jerome Glisse ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
