linux-kernel - Re: [PATCH v3 00/22] 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: <bff57a63-4383-4890-8c68-8778b3a75571@oracle.com>
Date: Mon, 8 Sep 2025 14:14:20 -0700
From: Anthony Yznaga <anthony.yznaga@...cle.com>
To: Matthew Wilcox <willy@...radead.org>, David Hildenbrand <david@...hat.com>
Cc: linux-mm@...ck.org, akpm@...ux-foundation.org, andreyknvl@...il.com,
        arnd@...db.de, bp@...en8.de, brauner@...nel.org, bsegall@...gle.com,
        corbet@....net, dave.hansen@...ux.intel.com, dietmar.eggemann@....com,
        ebiederm@...ssion.com, hpa@...or.com, jakub.wartak@...lbox.org,
        jannh@...gle.com, juri.lelli@...hat.com, khalid@...nel.org,
        liam.howlett@...cle.com, linyongting@...edance.com,
        lorenzo.stoakes@...cle.com, luto@...nel.org, markhemm@...glemail.com,
        maz@...nel.org, mhiramat@...nel.org, mgorman@...e.de, mhocko@...e.com,
        mingo@...hat.com, muchun.song@...ux.dev, neilb@...e.de,
        osalvador@...e.de, pcc@...gle.com, peterz@...radead.org,
        pfalcato@...e.de, rostedt@...dmis.org, rppt@...nel.org,
        shakeel.butt@...ux.dev, surenb@...gle.com, tglx@...utronix.de,
        vasily.averin@...ux.dev, vbabka@...e.cz, vincent.guittot@...aro.org,
        viro@...iv.linux.org.uk, vschneid@...hat.com, x86@...nel.org,
        xhao@...ux.alibaba.com, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH v3 00/22] Add support for shared PTEs across processes



On 9/8/25 1:59 PM, Matthew Wilcox wrote:
> On Mon, Sep 08, 2025 at 10:32:22PM +0200, David Hildenbrand wrote:
>> In the context of this series, how do we handle VMA-modifying functions like
>> mprotect/some madvise/mlock/mempolicy/...? Are they currently blocked when
>> applied to a mshare VMA?
> 
> I haven't been following this series recently, so I'm not sure what
> Anthony will say.  My expectation is that the shared VMA is somewhat
> transparent to these operations; that is they are faulty if they span
> the boundary of the mshare VMA, but otherwise they pass through and
> affect the shared VMAs.
> 
> That does raise the interesting question of how mlockall() affects
> an mshare VMA.  I'm tempted to say that it should affect the shared
> VMA, but reasonable people might well disagree with me and have
> excellent arguments.
> 
>> And how are we handling other page table walkers that don't modify VMAs like
>> MADV_DONTNEED, smaps, migrate_pages, ... etc?
> 
> I'd expect those to walk into the shared region too.

I've received conflicting feedback in previous discussions that things 
like protection changes should be done via ioctl. I do thing somethings 
are appropriate for ioctl like map and unmap, but I also like the idea 
of the existing APIs being transparent to mshare so long as they are 
operating entirely with an mshare range and not crossing boundaries.