On Tue, Feb 24, 2026 at 1:40 AM David Hildenbrand (Arm)
[off-list ref] wrote:

quoted

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/ (local)

Thanks,
Kalesh

--
Cheers,

David