All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Ruchi Kandoi <kandoiruchi@google.com>
Cc: gregkh@linuxfoundation.org, arve@android.com,
	riandrews@android.com, sumit.semwal@linaro.org, arnd@arndb.de,
	labbott@redhat.com, jlayton@poochiereds.net,
	bfields@fieldses.org, mingo@redhat.com, peterz@infradead.org,
	akpm@linux-foundation.org, keescook@chromium.org,
	mhocko@suse.com, oleg@redhat.com, john.stultz@linaro.org,
	mguzik@redhat.com, jdanis@google.com, adobriyan@gmail.com,
	ghackmann@google.com, kirill.shutemov@linux.intel.com,
	vbabka@suse.cz, dave.hansen@linux.intel.com,
	dan.j.williams@intel.com, hannes@cmpxchg.org,
	iamjoonsoo.kim@lge.com, luto@kernel.org, tj@kernel.org,
	vdavydov.dev@gmail.com, ebiederm@xmission.com,
	linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org,
	linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linaro-mm-sig@lists.linaro.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [RFC 0/6] Module for tracking/accounting shared memory buffers
Date: Wed, 12 Oct 2016 01:26:34 +0100	[thread overview]
Message-ID: <20161012002634.GN19539@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1476229810-26570-1-git-send-email-kandoiruchi@google.com>

On Tue, Oct 11, 2016 at 04:50:04PM -0700, Ruchi Kandoi wrote:

> memtrack maintains a per-process list of shared buffer references, which is
> exported to userspace as /proc/[pid]/memtrack.  Buffers can be optionally
> "tagged" with a short string: for example, Android userspace would use this
> tag to identify whether buffers were allocated on behalf of the camera stack,
> GL, etc.  memtrack also exports the VMAs associated with these buffers so
> that pages already included in the process's mm counters aren't double-counted.
> 
> Shared-buffer allocators can hook into memtrack by embedding
> struct memtrack_buffer in their buffer metadata, calling
> memtrack_buffer_{init,remove} at buffer allocation and free time, and
> memtrack_buffer_{install,uninstall} when a userspace process takes or
> drops a reference to the buffer.  For fd-backed buffers like dma-bufs, hooks in
> fdtable.c and fork.c automatically notify memtrack when references are added or
> removed from a process's fd table.
> 
> This patchstack adds memtrack hooks into dma-buf and ion.  If there's upstream
> interest in memtrack, it can be extended to other memory allocators as well,
> such as GEM implementations.

No, with a side of Hell, No.  Not to mention anything else,
	* descriptor tables do not belong to any specific task_struct and
actions done by one show up in all who share that thing.
	* shared descriptor table does not imply belonging to the same
group.
	* shared descriptor table can become unshared at any point, invisibly
for that Fine Piece Of Software.
	* while we are at it, blocking allocation under several spinlocks
(and with interrupts disabled, for good measure) is generally considered
a bloody bad idea.

That - just from the quick look through that patchset.  Bringing task_struct
into the API is already sufficient for a NAK.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Ruchi Kandoi <kandoiruchi@google.com>
Cc: gregkh@linuxfoundation.org, arve@android.com,
	riandrews@android.com, sumit.semwal@linaro.org, arnd@arndb.de,
	labbott@redhat.com, jlayton@poochiereds.net,
	bfields@fieldses.org, mingo@redhat.com, peterz@infradead.org,
	akpm@linux-foundation.org, keescook@chromium.org,
	mhocko@suse.com, oleg@redhat.com, john.stultz@linaro.org,
	mguzik@redhat.com, jdanis@google.com, adobriyan@gmail.com,
	ghackmann@google.com, kirill.shutemov@linux.intel.com,
	vbabka@suse.cz, dave.hansen@linux.intel.com,
	dan.j.williams@intel.com, hannes@cmpxchg.org,
	iamjoonsoo.kim@lge.com, luto@kernel.org, tj@kernel.org,
	vdavydov.dev@gmail.com, ebiederm@xmission.com,
	linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org,
	linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linaro-mm-sig@lists.linaro.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [RFC 0/6] Module for tracking/accounting shared memory buffers
Date: Wed, 12 Oct 2016 01:26:34 +0100	[thread overview]
Message-ID: <20161012002634.GN19539@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1476229810-26570-1-git-send-email-kandoiruchi@google.com>

On Tue, Oct 11, 2016 at 04:50:04PM -0700, Ruchi Kandoi wrote:

> memtrack maintains a per-process list of shared buffer references, which is
> exported to userspace as /proc/[pid]/memtrack.  Buffers can be optionally
> "tagged" with a short string: for example, Android userspace would use this
> tag to identify whether buffers were allocated on behalf of the camera stack,
> GL, etc.  memtrack also exports the VMAs associated with these buffers so
> that pages already included in the process's mm counters aren't double-counted.
> 
> Shared-buffer allocators can hook into memtrack by embedding
> struct memtrack_buffer in their buffer metadata, calling
> memtrack_buffer_{init,remove} at buffer allocation and free time, and
> memtrack_buffer_{install,uninstall} when a userspace process takes or
> drops a reference to the buffer.  For fd-backed buffers like dma-bufs, hooks in
> fdtable.c and fork.c automatically notify memtrack when references are added or
> removed from a process's fd table.
> 
> This patchstack adds memtrack hooks into dma-buf and ion.  If there's upstream
> interest in memtrack, it can be extended to other memory allocators as well,
> such as GEM implementations.

No, with a side of Hell, No.  Not to mention anything else,
	* descriptor tables do not belong to any specific task_struct and
actions done by one show up in all who share that thing.
	* shared descriptor table does not imply belonging to the same
group.
	* shared descriptor table can become unshared at any point, invisibly
for that Fine Piece Of Software.
	* while we are at it, blocking allocation under several spinlocks
(and with interrupts disabled, for good measure) is generally considered
a bloody bad idea.

That - just from the quick look through that patchset.  Bringing task_struct
into the API is already sufficient for a NAK.

  parent reply	other threads:[~2016-10-12  0:26 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-11 23:50 [RFC 0/6] Module for tracking/accounting shared memory buffers Ruchi Kandoi
2016-10-11 23:50 ` Ruchi Kandoi
2016-10-11 23:50 ` Ruchi Kandoi
2016-10-11 23:50 ` [RFC 1/6] fs: add installed and uninstalled file_operations Ruchi Kandoi
2016-10-11 23:50   ` Ruchi Kandoi
2016-10-11 23:50   ` Ruchi Kandoi
2016-10-11 23:50 ` [RFC 2/6] drivers: misc: add memtrack Ruchi Kandoi
2016-10-11 23:50   ` Ruchi Kandoi
2016-10-11 23:50   ` Ruchi Kandoi
2016-10-11 23:50 ` [RFC 3/6] dma-buf: add memtrack support Ruchi Kandoi
2016-10-11 23:50   ` Ruchi Kandoi
2016-10-11 23:50   ` Ruchi Kandoi
2016-10-11 23:50 ` [RFC 4/6] memtrack: Adds the accounting to keep track of all mmaped/unmapped pages Ruchi Kandoi
2016-10-11 23:50   ` Ruchi Kandoi
2016-10-11 23:50   ` Ruchi Kandoi
2016-10-11 23:50 ` [RFC 5/6] memtrack: Add memtrack accounting for forked processes Ruchi Kandoi
2016-10-11 23:50   ` Ruchi Kandoi
2016-10-11 23:50 ` [RFC 6/6] drivers: staging: ion: add ION_IOC_TAG ioctl Ruchi Kandoi
2016-10-11 23:50   ` Ruchi Kandoi
2016-10-12  3:29   ` Hillf Danton
2016-10-12  3:29     ` Hillf Danton
2016-10-12  3:29     ` Hillf Danton
2016-10-12  3:29     ` Hillf Danton
2016-10-12  0:26 ` Al Viro [this message]
2016-10-12  0:26   ` [RFC 0/6] Module for tracking/accounting shared memory buffers Al Viro
2016-10-12  1:14 ` Rob Clark
2016-10-12  1:14   ` Rob Clark
2016-10-12  1:14   ` Rob Clark
2016-10-12  9:09 ` Christian König
2016-10-12  9:09   ` Christian König
2016-10-12  9:09   ` Christian König
2016-10-12  9:09   ` Christian König
2016-10-12 17:15 ` Dave Hansen
2016-10-12 17:15   ` Dave Hansen

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=20161012002634.GN19539@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=arve@android.com \
    --cc=bfields@fieldses.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ebiederm@xmission.com \
    --cc=ghackmann@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=jdanis@google.com \
    --cc=jlayton@poochiereds.net \
    --cc=john.stultz@linaro.org \
    --cc=kandoiruchi@google.com \
    --cc=keescook@chromium.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=labbott@redhat.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mguzik@redhat.com \
    --cc=mhocko@suse.com \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=riandrews@android.com \
    --cc=sumit.semwal@linaro.org \
    --cc=tj@kernel.org \
    --cc=vbabka@suse.cz \
    --cc=vdavydov.dev@gmail.com \
    /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.