On Tue, Aug 4, 2020 at 12:28 AM Al Viro viro@zeniv.linux.org.uk wrote:
On Mon, Aug 03, 2020 at 09:22:53AM -0700, Suren Baghdasaryan wrote:
On Mon, Aug 3, 2020 at 9:12 AM Matthew Wilcox willy@infradead.org wrote:
On Mon, Aug 03, 2020 at 09:00:00AM -0700, Suren Baghdasaryan wrote:
On Mon, Aug 3, 2020 at 8:41 AM Matthew Wilcox willy@infradead.org wrote:
On Mon, Aug 03, 2020 at 02:47:19PM +0000, Kalesh Singh wrote:
+static void dma_buf_fd_install(int fd, struct file *filp) +{
trace_dma_buf_fd_ref_inc(current, filp);
+}
You're adding a new file_operation in order to just add a new tracepoint? NACK.
Hi Matthew, The plan is to attach a BPF to this tracepoint in order to track dma-buf users. If you feel this is an overkill, what would you suggest as an alternative?
I'm sure BPF can attach to fd_install and filter on file->f_ops belonging to dma_buf, for example.
Sounds like a workable solution. Will explore that direction. Thanks Matthew!
No, it is not a solution at all.
What kind of locking would you use? With _any_ of those approaches.
How would you use the information that is hopelessly out of date/incoherent/whatnot at the very moment you obtain it?
IOW, what the hell is that horror for? You do realize, for example, that there's such thing as dup(), right? And dup2() as well. And while we are at it, how do you keep track of removals, considering the fact that you can stick a file reference into SCM_RIGHTS datagram sent to yourself, close descriptors and an hour later pick that datagram, suddenly getting descriptor back?
Besides, "I have no descriptors left" != "I can't be currently sitting in the middle of syscall on that sucker"; close() does *NOT* terminate ongoing operations.
You are looking at the drastically wrong abstraction level. Please, describe what it is that you are trying to achieve.
For added entertainment (since this is specifically about dma-buf) you can stuff them into various gpu drivers, and convert to a native gpu driver handle thing. That's actually the expected use case, first a buffer sharing gets established with AF_UNIX, then both sides close the dma-buf fd handle.
GPU drivers then internally cache the struct file so that we can hand out the same (to avoid confusion when re-importing it on some other driver), so for the case of dma-buf the "it's not actually an installed fd anywhere for unlimited time" is actually the normal use-case, not some odd corner.
Cheers, Daniel