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] [day] [month] [year] [list]

Message-ID: <57FE6FC6.70205@linux.intel.com>
Date:   Wed, 12 Oct 2016 10:15:50 -0700
From:   Dave Hansen <dave.hansen@...ux.intel.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,
        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

On 10/11/2016 04:50 PM, Ruchi Kandoi wrote:
> Any process holding a reference to these buffers will keep the kernel from
> reclaiming its backing pages.  mm counters don't provide a complete picture of
> these allocations, since they only account for pages that are mapped into a
> process's address space.  This problem is especially bad for systems like
> Android that use dma-buf fds to share graphics and multimedia buffers between
> processes: these allocations are often large, have complex sharing patterns,
> and are rarely mapped into every process that holds a reference to them.

What do you end up _doing_ with all this new information that you have
here?  You know which processes have "pinned" these shared buffers, and
exported that information in /proc.  But, then what?