linux-kernel - Re: [PATCH v3] mm, drm/i915: mark pinned shmemfs pages as unevictable

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]

Message-ID: <039b2768-39ff-6196-9615-1f0302ee3e0e@intel.com>
Date:   Wed, 31 Oct 2018 07:19:21 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     owner-linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        intel-gfx@...ts.freedesktop.org, linux-mm@...ck.org
Cc:     Kuo-Hsin Yang <vovoy@...omium.org>,
        Chris Wilson <chris@...is-wilson.co.uk>,
        Michal Hocko <mhocko@...e.com>,
        Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v3] mm, drm/i915: mark pinned shmemfs pages as unevictable

On 10/31/18 1:19 AM, owner-linux-mm@...ck.org wrote:
> -These are currently used in two places in the kernel:
> +These are currently used in three places in the kernel:
>  
>   (1) By ramfs to mark the address spaces of its inodes when they are created,
>       and this mark remains for the life of the inode.
> @@ -154,6 +154,8 @@ These are currently used in two places in the kernel:
>       swapped out; the application must touch the pages manually if it wants to
>       ensure they're in memory.
>  
> + (3) By the i915 driver to mark pinned address space until it's unpinned.

mlock() and ramfs usage are pretty easy to track down.  /proc/$pid/smaps
or /proc/meminfo can show us mlock() and good ol' 'df' and friends can
show us ramfs the extent of pinned memory.

With these, if we see "Unevictable" in meminfo bump up, we at least have
a starting point to find the cause.

Do we have an equivalent for i915?