On Tue, Aug 04, 2020 at 02:09:13AM +0100, Al Viro wrote:
On Mon, Aug 03, 2020 at 11:28:31PM +0100, Al Viro wrote:
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.
Hi Al. Thank you for the comments. Ultimately what we need is to identify processes that hold a file reference to the dma-buf. Unfortunately we can't use only explicit dma_buf_get/dma_buf_put to track them because when an FD is being shared between processes the file references are taken implicitly.
For example, on the sender side: unix_dgram_sendmsg -> send_scm -> __send_scm -> scm_fp_copy -> fget_raw and on the receiver side: unix_dgram_recvmsg -> scm_recv -> scm_detach_fds -> __scm_install_fd -> get_file
I understand now that fd_install is not an appropriate abstraction level to track these. Is there a more appropriate alternative where we could use to track these implicit file references?
_IF_ it's "who keeps a particularly long-lived sucker pinned", I would suggest fuser(1) run when you detect that kind of long-lived dmabuf. With events generated by their constructors and destructors, and detection of longevity done based on that.
But that's only a semi-blind guess at the things you are trying to achieve; please, describe what it really is.