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

[David Hildenbrand (Arm)]

On 2/26/26 00:06, Kalesh Singh wrote:
> On Tue, Feb 24, 2026 at 1:40 AM David Hildenbrand (Arm)
> <david@xxxxxxxxxx> 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?
The current plan is to have special "mshare container VMA" representing
an mshare region. What's actually hiding in there is defined in the
mshare MM.

One could, add support to walk the VMAs hiding in there instead; I don't
remember what out latest opinion about that was. But I do recall that it
involves a lot of complexity :)

Applications must be aware that this mshare region behaves completely
different than non-mshare regions. There should definitely be an
interface for an app to introspect what exactly is (currently, anybody
else could modify it concurrently) hiding in there.

-- 
Cheers,

David