All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Suren Baghdasaryan <surenb@google.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	Kalesh Singh <kaleshsingh@google.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@redhat.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	linux-media@vger.kernel.org,
	DRI mailing list <dri-devel@lists.freedesktop.org>,
	linaro-mm-sig@lists.linaro.org, linux-fsdevel@vger.kernel.org,
	Hridya Valsaraju <hridya@google.com>,
	Ioannis Ilkos <ilkos@google.com>,
	John Stultz <john.stultz@linaro.org>,
	kernel-team <kernel-team@android.com>
Subject: Re: [PATCH 2/2] dmabuf/tracing: Add dma-buf trace events
Date: Tue, 4 Aug 2020 02:09:13 +0100	[thread overview]
Message-ID: <20200804010913.GA2096725@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20200803222831.GI1236603@ZenIV.linux.org.uk>

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.

_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.

WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@zeniv.linux.org.uk>
To: Suren Baghdasaryan <surenb@google.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
	DRI mailing list <dri-devel@lists.freedesktop.org>,
	linux-doc@vger.kernel.org, Ioannis Ilkos <ilkos@google.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	linaro-mm-sig@lists.linaro.org,
	Hridya Valsaraju <hridya@google.com>,
	Ingo Molnar <mingo@redhat.com>,
	Matthew Wilcox <willy@infradead.org>,
	Kalesh Singh <kaleshsingh@google.com>,
	linux-fsdevel@vger.kernel.org,
	kernel-team <kernel-team@android.com>,
	linux-media@vger.kernel.org
Subject: Re: [PATCH 2/2] dmabuf/tracing: Add dma-buf trace events
Date: Tue, 4 Aug 2020 02:09:13 +0100	[thread overview]
Message-ID: <20200804010913.GA2096725@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20200803222831.GI1236603@ZenIV.linux.org.uk>

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.

_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.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-08-04  1:09 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-03 14:47 [PATCH 0/2] Per process tracking of dma buffers Kalesh Singh
2020-08-03 14:47 ` Kalesh Singh
2020-08-03 14:47 ` [PATCH 1/2] fs: Add fd_install file operation Kalesh Singh
2020-08-03 14:47   ` Kalesh Singh
2020-08-03 16:34   ` Christoph Hellwig
2020-08-03 18:26     ` Kalesh Singh
2020-08-03 18:26       ` Kalesh Singh
2020-08-03 22:18   ` Al Viro
2020-08-03 22:18     ` Al Viro
2020-08-04  0:30   ` Joel Fernandes
2020-08-04  0:30     ` Joel Fernandes
2020-08-04 13:54     ` Kalesh Singh
2020-08-04 13:54       ` Kalesh Singh
2020-08-03 14:47 ` [PATCH 2/2] dmabuf/tracing: Add dma-buf trace events Kalesh Singh
2020-08-03 14:47   ` Kalesh Singh
2020-08-03 15:32   ` Steven Rostedt
2020-08-03 15:32     ` Steven Rostedt
2020-08-03 16:33     ` Kalesh Singh
2020-08-03 16:33       ` Kalesh Singh
2020-08-03 15:41   ` Matthew Wilcox
2020-08-03 15:41     ` Matthew Wilcox
2020-08-03 16:00     ` Suren Baghdasaryan
2020-08-03 16:00       ` Suren Baghdasaryan
2020-08-03 16:12       ` Matthew Wilcox
2020-08-03 16:12         ` Matthew Wilcox
2020-08-03 16:22         ` Suren Baghdasaryan
2020-08-03 16:22           ` Suren Baghdasaryan
2020-08-03 22:28           ` Al Viro
2020-08-03 22:28             ` Al Viro
2020-08-04  1:09             ` Al Viro [this message]
2020-08-04  1:09               ` Al Viro
2020-08-04  2:10               ` Suren Baghdasaryan
2020-08-04  2:10                 ` Suren Baghdasaryan
2020-08-04 15:44               ` Kalesh Singh
2020-08-04 15:44                 ` Kalesh Singh
2020-08-04 18:27                 ` Al Viro
2020-08-04 18:27                   ` Al Viro
2020-08-04 20:42                   ` Kalesh Singh
2020-08-04 20:42                     ` Kalesh Singh
2020-08-04 20:26             ` Daniel Vetter
2020-08-04 20:26               ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200804010913.GA2096725@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=corbet@lwn.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hridya@google.com \
    --cc=ilkos@google.com \
    --cc=john.stultz@linaro.org \
    --cc=kaleshsingh@google.com \
    --cc=kernel-team@android.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=sumit.semwal@linaro.org \
    --cc=surenb@google.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.