From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpout.efficios.com (smtpout.efficios.com [167.114.26.122]) by sourceware.org (Postfix) with ESMTPS id 1B1493895FE3 for ; Fri, 21 Jun 2024 13:01:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1B1493895FE3 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=efficios.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=efficios.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1B1493895FE3 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=167.114.26.122 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718974891; cv=none; b=Zk0RS558jDEVsedjNVM2DkH0gxrJ2/d3C21hKtYZGEuEhKnY/CoA9nwKWSX7lCz4aWJUJVA/LqLs8iPs3NQGvS7mB9piYvv9vEnUwjksDTYz9h+Iqga2ZCed6rmIT2XIs4PmykwlGS2gIxGAIP9oNqsarzPMR023afj7943sqY4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718974891; c=relaxed/simple; bh=N2xyPZ8vd+BP6gQrZXMnRiAs83pWoiUuIe1r4o9tDzg=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=UhKtFXvZH4XLeKfBVS7XyieujxkHZldJ1XOO3uATgX8FJer93aUIYVWNJmSpRLuyr1PjQJuEmPdSUmsGFKs62H15bam/a43qj0h8SN0148FjxmVzDW1LADqEjUSUrUkSivJPZ0dgQz1gdwstM06PSwACFRIBzeLij50jLtuTRMc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1718974887; bh=N2xyPZ8vd+BP6gQrZXMnRiAs83pWoiUuIe1r4o9tDzg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=rwQIzI4/op7xSCqBzdvHgw5f7Glfd7voYd8geEdFBZmId6Pp6TuD+tgJ9IpgpGZeA NhoGX4ocUP+E7Lkh1/61SdNmhptRwpzfOtSDwiTSHciGs6/8cO8vArganij822ML5h c0u+Fcf9KKKdt7TsHv3DxcCgNVgSqj5miJ4mknLipjAabA8vE5sc4oSi4MGuY0hm6d FxiuMNJMd1wkl6c3GcsWfAL5RPx0kBnlDNe/Kjxg9aO9rKgOlSDzNb6Rjh7ax7zKcU exRlSdcD1HXSfDYYofgy7CeCtugRnMH1C7wqivbX6Ph2bnLwL9NKffx1R79BaZygUH olJY9xyyA06iA== Received: from [172.16.0.134] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4W5HYM1LBtz172m; Fri, 21 Jun 2024 09:01:27 -0400 (EDT) Message-ID: <7b23e187-3d73-4eab-9ef6-c15679666676@efficios.com> Date: Fri, 21 Jun 2024 09:02:29 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [v4] Update mmap() flags and errors lists To: DJ Delorie Cc: libc-alpha@sourceware.org References: Content-Language: en-US From: Mathieu Desnoyers In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2024-06-18 16:57, DJ Delorie wrote: > Mathieu Desnoyers 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