Re: gABI extension proposal: PT_SHMMAP

["H. Peter Anvin" <hpa@zytor.com>]

On 06/07/17 17:30, Cary Coutant wrote:
>> Why is MAP_SHARED even needed for the linux vdso use-case?
>>
>> All the mappings created for the vdso are read-only mappings, right?
>> And on Linux, MAP_PRIVATE mappings already reflect changes made to the
>> underlying file, so long as the process hasn't written to the page, I
>> think?
>>
>> So, if you're intending to use this to implement the "vvar" mapping,
>> isn't the default MAP_PRIVATE already sufficient?
> 
> He mentioned that this was for the kernel-provided *data* page,
> implying to me that he wants a writable, but still sharable (i.e., not
> copy-on-write) mapping.
> 
> It seems generally useful to me. I probably wouldn't object to a new
> gABI bit, but a little more background would be helpful in deciding.
> 

It's not writable, at least not in the intended usage.  I will
experiment and see if PT_LOAD might just do the right thing.  Even so,
it might be safer to have a PF_MMAP bit indicating that this *must* be
mmapped.

That legacy Unix kernels doesn't support this feature is in my opinion a
total red herring.  If anything, this would permit these systems to
error out rather than do something that is completely unexpected.

The user space usage I was considering would amount to a shared bss
section.  This way multiple processes could have a shared memory area
with symbols.  It could either be done as an anonymous mapping (p_memsz
> p_filesz) in which case it would be shared among fork() clients, or as
a file-based mapping (in which case the file would, unfortunately, have
to be writable.)

However, if the consensus is that this is not interesting outside this
particular use case, then putting it under PF_MASKOS makes sense.

	-hpa