[Linaro-mm-sig] [PATCH] dma-buf: Add debugfs support

Maarten Lankhorst maarten.lankhorst at canonical.com
Fri Dec 14 06:35:24 PST 2012


Op 14-12-12 15:11, Rob Clark schreef:
> On Fri, Dec 14, 2012 at 5:57 AM, Maarten Lankhorst
> <m.b.lankhorst at gmail.com> wrote:
>> Op 14-12-12 10:36, sumit.semwal at ti.com schreef:
>>> From: Sumit Semwal <sumit.semwal at linaro.org>
>>>
>>> Add debugfs support to make it easier to print debug information
>>> about the dma-buf buffers.
>>>
>> I like the idea, I don't know if it could be done in a free manner, but for bonus points
>> could we also have the dma-buf fd be obtainable that way from a debugfs entry?
>>
>> Doing so would allow me to 'steal' a dma-buf from an existing mapping easily, and test against that.
>>
>> Also I think the name of the device and process that exported the dma-buf would be useful
>> to have as well, even if in case of the device that would mean changing the api slightly to record it.
>>
>> I was thinking of having a directory structure like this:
>>
>> /sys/kernel/debug/dma_buf/stats
>>
>> and then for each dma-buf:
>>
>> /sys/kernel/debug/dma-buf/exporting_file.c/<number>-fd
>> /sys/kernel/debug/dma-buf/exporting_file.c/<number>-attachments
>> /sys/kernel/debug/dma-buf/exporting_file.c/<number>-info
>>
>> Opening the fd file would give you back the original fd, or fail with -EIO if refcount was dropped to 0.
>>
>> Would something like this be doable? I don't know debugfs that well, but I don't see why it wouldn't be,
> yeah.. but sort of back-door's the security benefits of an anonymous fd..
>
> BR,
> -R
If you have access to debugfs you're root, so what stops you from stealing it through a ptrace?

~Maarten


More information about the dri-devel mailing list