Re: [v4] Update mmap() flags and errors lists

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

On 2024-06-18 16:57, DJ Delorie wrote:
> Mathieu Desnoyers <mathieu.desnoyers@efficios.com> writes:
[...]
> 
>>> +@item MAP_FIXED_NOREPLACE
>>> +Similar to @code{MAP_FIXED} except the call will fail with
>>> +@code{EEXIST} if the new mapping would overwrite an existing mapping.
>>> +To test for this, specify MAP_FIXED_NOREPLACE without MAP_FIXED, and
>>> +check the actual address returned.  If it does not match the address
>>> +passed, then this flag is not supported.
>>
>> mmap(2) states that older kernels fallback to non-MAP_FIXED behavior if
>> the mapping would overwrite an existing mapping, which requires to
>> carefully handle the return value. Is this backward-compatibility
>> handling somehow abstracted within the libc wrapper ?
> 
> The man page says that older kernels which do not support
> MAP_FIXED_NOREPLACE would act as if that flag were just omitted, which
> means no MAP_FIXED either.  It does not imply that there's an older
> kernel that *does* support MAP_FIXED_NOREPLACE but acts differently than
> today.  In either case, testing the returned address to see if it
> matches the desired one is the correct response.
> 
> There's no special backwards compatibility for mmap() in glibc, other
> than to call mmap2 instead of mmap if available.

OK

[...]

> 
>>> +@item MAP_SYNC
>>> +This flag is used to map persistent memory devices into the running
>>> +program in such a way that writes to the mapping are immediately
>>> +written to the device as well.  Unlike most other flags, this one will
>>> +fail unless @code{MAP_SHARED_VALIDATE} is also given.
>>
>> Note that this wording is misleading. Users of persistent memory devices
>> need to issue explicit "flush" instructions to ensure that writes are
>> made persistent to the device. The MAP_SYNC merely guarantees that
>> memory mappings within a file on a dax-enabled filesystem will appear
>> at the same file offset after a crash/reboot. It goes not guarantee
>> anything about write persistence.
> 
>    "This flag is supported only for files supporting DAX (direct mapping
>     of persistent memory)"
> 
>    "it will be visible in the same file at the same offset even after the
>     system crashes or is rebooted."
> 
> That sounds like persistence to me?

AFAIU it states persistence of the mapping location within the file, but
it does not guarantee anything about persistence of the writes to that 
mapping.

In many cases, persistence of the writes to the mapping are only made
persistent after specific cache-flushing instructions have been issued.

See this man page for reference:

https://manpages.debian.org/experimental/libpmem-dev/pmem_flush.3

> 
>>> +@item EAGAIN
>>> +
>>> +The system has temporarily run out of resources.
>>
>> or file has been locked.
> 
> I was asked to avoid mentioning certiain types of locks that glibc
> chooses not to support...

OK

[...]

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com