On Mon, Aug 3, 2020 at 6:09 PM Al Viro viro@zeniv.linux.org.uk 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.
Thanks for your feedback, Al. I see your points and sorry for not realizing these shortcomings.
You are looking at the drastically wrong abstraction level. Please, describe what it is that you are trying to achieve.
_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.
That is the intention here. IIUC fuser(1) would require root access to collect this information from a process other than the caller. Ideally what we would like to have is a non-root process with specific capabilities (in our case a process that can access BPF maps) to be able to obtain the information on dma-buf users. However, it might make more sense to track dma-buf usage from dma_buf_getfile, dma_buf_get and dma_buf_put since these calls are the ones that affect file refcount. Will dig some more into this. Thanks for your time and sorry for not thinking it through beforehand.
But that's only a semi-blind guess at the things you are trying to achieve; please, describe what it really is.