linux-kernel - Re: [RFC 0/6] Module for tracking/accounting shared memory buffers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 12 Oct 2016 11:09:47 +0200
From:   Christian König <christian.koenig@....com>
To:     Ruchi Kandoi <kandoiruchi@...gle.com>,
        <gregkh@...uxfoundation.org>, <arve@...roid.com>,
        <riandrews@...roid.com>, <sumit.semwal@...aro.org>,
        <arnd@...db.de>, <labbott@...hat.com>, <viro@...iv.linux.org.uk>,
        <jlayton@...chiereds.net>, <bfields@...ldses.org>,
        <mingo@...hat.com>, <peterz@...radead.org>,
        <akpm@...ux-foundation.org>, <keescook@...omium.org>,
        <mhocko@...e.com>, <oleg@...hat.com>, <john.stultz@...aro.org>,
        <mguzik@...hat.com>, <jdanis@...gle.com>, <adobriyan@...il.com>,
        <ghackmann@...gle.com>, <kirill.shutemov@...ux.intel.com>,
        <vbabka@...e.cz>, <dave.hansen@...ux.intel.com>,
        <dan.j.williams@...el.com>, <hannes@...xchg.org>,
        <iamjoonsoo.kim@....com>, <luto@...nel.org>, <tj@...nel.org>,
        <vdavydov.dev@...il.com>, <ebiederm@...ssion.com>,
        <linux-kernel@...r.kernel.org>, <devel@...verdev.osuosl.org>,
        <linux-media@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>,
        <linaro-mm-sig@...ts.linaro.org>, <linux-fsdevel@...r.kernel.org>,
        <linux-mm@...ck.org>
Subject: Re: [RFC 0/6] Module for tracking/accounting shared memory buffers

Am 12.10.2016 um 01:50 schrieb Ruchi Kandoi:
> 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.
We have run into similar problems before. Because of this I already 
proposed a solution for this quite a while ago, but never pushed on 
upstreaming this since it was only done for a special use case.

Instead of keeping track of how much memory a process has bound (which 
is very fragile) my solution  only added some more debugging info on a 
per fd basis (e.g. how much memory is bound to this fd).

This information was then used by the OOM killer (for example) to make a 
better decision on which process to reap.

Shouldn't be to hard to expose this through debugfs or maybe a new fcntl 
to userspace for debugging.

I haven't looked at the code in detail, but messing with the per process 
memory accounting like you did in this proposal is clearly not a good 
idea if you ask me.

Regards,
Christian.