Thread (55 messages) 55 messages, 12 authors, 2021-08-17

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)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help