linux-kernel - Re: [RFC PATCH v3 00/10] Add support for shared PTEs across processes

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: <843ee8cf-bd9a-45c4-b136-79a11a4396de@oracle.com>
Date: Mon, 7 Oct 2024 12:46:52 -0700
From: Anthony Yznaga <anthony.yznaga@...cle.com>
To: David Hildenbrand <david@...hat.com>,
        "Kirill A. Shutemov" <kirill@...temov.name>
Cc: akpm@...ux-foundation.org, willy@...radead.org, markhemm@...glemail.com,
        viro@...iv.linux.org.uk, khalid@...nel.org, andreyknvl@...il.com,
        dave.hansen@...el.com, luto@...nel.org, brauner@...nel.org,
        arnd@...db.de, ebiederm@...ssion.com, catalin.marinas@....com,
        linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, mhiramat@...nel.org, rostedt@...dmis.org,
        vasily.averin@...ux.dev, xhao@...ux.alibaba.com, pcc@...gle.com,
        neilb@...e.de, maz@...nel.org
Subject: Re: [RFC PATCH v3 00/10] Add support for shared PTEs across processes


On 10/7/24 12:41 PM, David Hildenbrand wrote:
> On 07.10.24 21:23, Anthony Yznaga wrote:
>>
>> On 10/7/24 2:01 AM, Kirill A. Shutemov wrote:
>>> On Tue, Sep 03, 2024 at 04:22:31PM -0700, Anthony Yznaga wrote:
>>>> This patch series implements a mechanism that allows userspace
>>>> processes to opt into sharing PTEs. It adds a new in-memory
>>>> filesystem - msharefs. A file created on msharefs represents a
>>>> shared region where all processes mapping that region will map
>>>> objects within it with shared PTEs. When the file is created,
>>>> a new host mm struct is created to hold the shared page tables
>>>> and vmas for objects later mapped into the shared region. This
>>>> host mm struct is associated with the file and not with a task.
>>> Taskless mm_struct can be problematic. Like, we don't have access to 
>>> it's
>>> counters because it is not represented in /proc. For instance, 
>>> there's no
>>> way to check its smaps.
>>
>> Definitely needs exposure in /proc. One of the things I'm looking into
>> is the feasibility of showing the mappings in maps/smaps/etc..
>>
>>
>>>
>>> Also, I *think* it is immune to oom-killer because oom-killer looks 
>>> for a
>>> victim task, not mm.
>>> I hope it is not an intended feature :P
>>
>> oom-killer would have to kill all sharers of an mshare region before the
>> mshare region itself could be freed, but I'm not sure that oom-killer
>> would be the one to free the region. An mshare region is essentially a
>> shared memory object not unlike a tmpfs or hugetlb file. I think some
>> higher level intelligence would have to be involved to release it if
>> appropriate when under oom conditions.
>
>
> I thought we discussed that at LSF/MM last year and the conclusion was 
> that a process is needed (OOM kill, cgroup handling, ...), and it must 
> remain running. Once it stops running, we can force-unmap all pages etc.
>
> Did you look at the summary/(recording if available) of that, or am I 
> remembering things wrongly or was there actually such a discussion?

You're likely right. I'll review the discussion.


Anthony


>
> I know, it's problematic that this feature switched owners, ...