Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp540051pxa; Tue, 4 Aug 2020 11:30:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwlKW/YJeVtaECf2EukSXfRXyJR6mazYuogy5vjHrLBoJDluxiUFnapOYrXYEpuTAzO+6qd X-Received: by 2002:a50:ec95:: with SMTP id e21mr21314335edr.250.1596565810523; Tue, 04 Aug 2020 11:30:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596565810; cv=none; d=google.com; s=arc-20160816; b=a/QatQXk/ufy7Z0YdkLGFtoyYircgQiyIc/LxPtd0h+DLLetPVQ/4xeStBbZzg+7XK qMlRGNmrQ3PU4nu+ikggpBP1PSCJOJfQWoVJPcaVfZToJrFuAryBJ+3uJjGkIpAGxYLV n+BUR4/wvjng2xN94ixKPPWTvnlNu6sDvM3vXBgvo1FAvFpJ3wWh8jQfRlnzi/Pd6etr UiaEd6QmKUoSqzbwYTERO/6JhxRyE6Y7iYlixMjMLv2OhODbQEjy0uMKKCwK3LsjMlZg 9dLOYjzV1hyYXIMy45DAJLjnlMwPHkFl47ANqB5Sw9f1VR+rqvVT2xOSZnnqd7toZiNp Zjww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=GaPzyHB+wyaSSxBf5WSTJEOUsd3NJGHDpxbi9Md03oA=; b=dBGMF93Gl4bO2MCvXDKo+3QFmJa7JJI4KKTYmZpBOpTEgJXxX7zgoY9SFUUpC1xkXq 1BOFARuykNtfihzrg2loMxdqAMLNDOLuadP/YCqVVtDD0Qt4CX+NRnGYL0Mwi210o1q4 KdqGnS8rXI71+V91g6ud3qnxEFlTptTTx8H3bZtY2NIccxpnzyb3kh74Cn89TGPU7z+b 7OIRk90Zl/4Nr/d3+HBUXtm+HZELDj7CmGRLjk6CzDl2k9a+stkXtDrg36hW0Q8Qznxm MAlHNj9DUEBv35CJ9Ejv6eLUuZf/ZgEDYiXQ9gU7mj0IxiYgCDsAtzWvjnRZBB8AcmvO IcWA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x18si13704743ejd.265.2020.08.04.11.29.46; Tue, 04 Aug 2020 11:30:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726515AbgHDS1m (ORCPT + 99 others); Tue, 4 Aug 2020 14:27:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37582 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725826AbgHDS1m (ORCPT ); Tue, 4 Aug 2020 14:27:42 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 89AA0C06174A; Tue, 4 Aug 2020 11:27:41 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1k31em-009HhW-2E; Tue, 04 Aug 2020 18:27:24 +0000 Date: Tue, 4 Aug 2020 19:27:24 +0100 From: Al Viro To: Kalesh Singh Cc: Suren Baghdasaryan , Matthew Wilcox , Jonathan Corbet , Sumit Semwal , Steven Rostedt , Ingo Molnar , linux-doc@vger.kernel.org, LKML , linux-media@vger.kernel.org, DRI mailing list , linaro-mm-sig@lists.linaro.org, linux-fsdevel@vger.kernel.org, Hridya Valsaraju , Ioannis Ilkos , John Stultz , kernel-team Subject: Re: [PATCH 2/2] dmabuf/tracing: Add dma-buf trace events Message-ID: <20200804182724.GK1236603@ZenIV.linux.org.uk> References: <20200803144719.3184138-1-kaleshsingh@google.com> <20200803144719.3184138-3-kaleshsingh@google.com> <20200803154125.GA23808@casper.infradead.org> <20200803161230.GB23808@casper.infradead.org> <20200803222831.GI1236603@ZenIV.linux.org.uk> <20200804010913.GA2096725@ZenIV.linux.org.uk> <20200804154451.GA948167@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200804154451.GA948167@google.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 04, 2020 at 03:44:51PM +0000, Kalesh Singh wrote: > 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? There is no single lock that would stabilize the descriptor tables of all processes. And there's not going to be one, ever - it would be a contention point from hell, since that would've been a system-wide lock that would have to be taken by *ALL* syscalls modifying any descriptor table. Not going to happen, for obvious reasons. Moreover, you would have to have fork(2) take the same lock, since it does copy descriptor table. And clone(2) either does the same, or has the child share the descriptor table of parent. What's more, a reference to struct file can bloody well survive without a single descriptor refering to that file. In the example you've mentioned above, sender has ever right to close all descriptors it has sent. Files will stay opened as long as the references are held in the datagram; when that datagram is received, the references will be inserted into recepient's descriptor table. At that point you again have descriptors refering to that file, can do any IO on it, etc. So "the set of processes that hold a file reference to the dma-buf" is * inherently unstable, unless you are willing to freeze every process in the system except for the one trying to find that set. * can remain empty for any amount of time (hours, weeks, whatever), only to get non-empty later, with syscalls affecting the object in question done afterwards. So... what were you going to do with that set if you could calculate it? If it's really "how do we debug a leak?", it's one thing; in that case I would suggest keeping track of creation/destruction of objects (not gaining/dropping references - actual constructors and destructors) to see what gets stuck around for too long and use fuser(1) to try and locate the culprits if you see that something *was* living for too long. "Try" since the only reference might indeed have been stashed into an SCM_RIGHTS datagram sitting in a queue of some AF_UNIX socket. Note that "fuser needs elevated priveleges" is not a strong argument - the ability to do that sort of tracking does imply elevated priveleges anyway, and having a root process taking requests along the lines of "gimme the list of PIDs that have such-and-such dma_buf in their descriptor table" is not much of an attack surface. If you want to use it for something else, you'll need to describe that intended use; there might be sane ways to do that, but it's hard to come up with one without knowing what's being attempted...