From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D99C9C433E0 for ; Tue, 4 Aug 2020 07:27:31 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E2AA822B45 for ; Tue, 4 Aug 2020 07:27:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E2AA822B45 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id CB07F6E43B; Tue, 4 Aug 2020 07:27:05 +0000 (UTC) X-Greylist: delayed 567 seconds by postgrey-1.36 at gabe; Mon, 03 Aug 2020 22:28:46 UTC Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7448D6E162 for ; Mon, 3 Aug 2020 22:28:46 +0000 (UTC) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1k2iwZ-008hXp-IY; Mon, 03 Aug 2020 22:28:31 +0000 Date: Mon, 3 Aug 2020 23:28:31 +0100 From: Al Viro To: Suren Baghdasaryan Subject: Re: [PATCH 2/2] dmabuf/tracing: Add dma-buf trace events Message-ID: <20200803222831.GI1236603@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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Mailman-Approved-At: Tue, 04 Aug 2020 07:27:04 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jonathan Corbet , DRI mailing list , linux-doc@vger.kernel.org, Ioannis Ilkos , LKML , Steven Rostedt , linaro-mm-sig@lists.linaro.org, Hridya Valsaraju , Ingo Molnar , Matthew Wilcox , Kalesh Singh , linux-fsdevel@vger.kernel.org, kernel-team , linux-media@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Mon, Aug 03, 2020 at 09:22:53AM -0700, Suren Baghdasaryan wrote: > On Mon, Aug 3, 2020 at 9:12 AM Matthew Wilcox 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 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. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel