Re: [PATCH v3 00/22] Add support for shared PTEs across processes

[Kalesh Singh <kaleshsingh@google.com>]

On Tue, Feb 24, 2026 at 1:40 AM David Hildenbrand (Arm)
<david@kernel.org> wrote:
>
> > I believe that managing a pseudo-filesystem (msharefs) and mapping via
> > ioctl during process creation could introduce overhead that impacts
> > app startup latency. Ideally, child apps shouldn't be aware of this
> > sharing or need to manage the pseudo-filesystem on their end.
> All process must be aware of these special semantics.
>
> I'd assume that fork() would simply replicate mshare region into the
> fork'ed child process. So from that point of view, it's "transparent" as
> in "no special mshare() handling required after fork".

Hi David,

That's agood  point. If fork() simply replicates the mshare region, it
does achieve transparency in terms of setup.

I am still concerned about transparency in terms of observability.
Applications and sometimes inspect their own mappings (from
/proc/self/maps) to locate specific code or data regions for various
anti-tamper and obfuscation techniques. [2] If those mappings suddenly
point to an msharefs pseudo-file instead of the expected shared
library backing, it may break user-space assumptions and cause
compatibility issues.

Perhaps we could advertise the shared VMAs in the /proc/*/[s]maps
entries for the processes sharing these areas?

[2] https://lore.kernel.org/all/CAC_TJveMB1_iAUt81D5-+z8gArbVcbfDM=djCZG_bRVaCEMRmg@mail.gmail.com/

Thanks,
Kalesh


>
> --
> Cheers,
>
> David