RE: [RFC PATCH 0/5] madvise MADV_DOEXEC
From: David Laight <hidden>
Date: 2021-08-16 08:07:52
Also in:
lkml
From: Longpeng
Sent: 16 August 2021 01:26 Hi David, 在 2021/8/15 4:07, David Laight 写道:quoted
...quoted
quoted
quoted
quoted
Let me describe my use case more clearly (just ignore if you're not interested in it): 1. Prog A mmap() 4GB memory (anon or file-mapping), suppose the allocated VA range is [0x40000000,0x140000000) 2. Prog A specifies [0x48000000,0x50000000) and [0x80000000,0x100000000) will be shared by its child. 3. Prog A fork() Prog B and then Prog B exec() a new ELF binary. 4. Prog B notice the shared ranges (e.g. by input parameters or ...) and remap them to a continuous VA range.Remapping to contiguous VA is going to be difficult in the general case for (IIRC) VIVT caches. The required cache coherence may only be attainable by using uncached mappings.The Prog B uses mremap() syscall to remapping the shared ranges to other places, this is a common case for mremap in userspace. The cache coherence should already be processed in mremap core logic, otherwise there's maybe something wrong in mremap().
Maybe it does, and probably mremap() makes it work. But with VIVT caches if a pages gets mapped in two processes at the same time at different offsets into the cache then then both mappings end up being uncached. This was always a problem with normal file mmap. I don't know if Linux manages to pick the VA after finding the page has another mapping - SVR4 didn't. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)