Op 14-12-12 15:11, Rob Clark schreef: > On Fri, Dec 14, 2012 at 5:57 AM, Maarten Lankhorst > <m.b.lankhorst@xxxxxxxxx> wrote: >> Op 14-12-12 10:36, sumit.semwal@xxxxxx schreef: >>> From: Sumit Semwal <sumit.semwal@xxxxxxxxxx> >>> >>> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
