From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 642DE3882ACB for ; Tue, 18 Jun 2024 20:57:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 642DE3882ACB Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 642DE3882ACB Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718744251; cv=none; b=doMc9339qjP7Cyw+0Z91/Rin5U4z0tVH2bLlXa+RZg1uq2hK/W5UjhrZDTTmkZXnVdYwtUAy7X+U2Q7wUkuRIHHOrfpNB1iTDdA3QnXH+/XoFJy912WtfmRpoRfvwhEvcZg2y1ryZlXzFmWaxyUni3lPeAd85PnSuoJH3pYXKqk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718744251; c=relaxed/simple; bh=Ls4avvk90fP8OBQPph5X/PAXjZanWky3pybdvnPZcwM=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=MGmec/Y7CRYcyZx0UKK8pfMIzpu1doCFeK5JbjtlYcaDzz4iZGtigM04LnpDq8nj464ZwnJWbOJwkW63o4Dis4bocfdC0Hed6bh8oWa1vJA+H6+QekO+f34EShnvvJ+lD3xhDRjSn7/my2gie4pp3ywzsr1G5721lc4oSTFcD30= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1718744249; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=JmX4OfRLXvCoUbvzkBByIVMX0ivkqTwKyPdC/CupXAA=; b=LX5YSQVBvQe/nZdifFEl9Ef5BGD/Rg0yNmuJ633JpwEpiot3UcQQOfKx+MUaBEEa3/PR6U 3W2MgKS6NC5i7kjpBKWDTrDQUacijpwZSJ6BqDIY46rroHiikbb9DkNU9TmrIqJmkD8E3X eQax7/13PYfNj1EuIXMxLHgNtf5yHHY= Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-404-xv8eo92vNaajARyOJZ1uiQ-1; Tue, 18 Jun 2024 16:57:26 -0400 X-MC-Unique: xv8eo92vNaajARyOJZ1uiQ-1 Received: from mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id B1C5A1956094; Tue, 18 Jun 2024 20:57:24 +0000 (UTC) Received: from greed.delorie.com (unknown [10.22.10.3]) by mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 3DE0419560B0; Tue, 18 Jun 2024 20:57:23 +0000 (UTC) Received: from greed.delorie.com.redhat.com (localhost [127.0.0.1]) by greed.delorie.com (8.16.1/8.16.1) with ESMTP id 45IKvHq11618063; Tue, 18 Jun 2024 16:57:17 -0400 From: DJ Delorie To: Mathieu Desnoyers Cc: libc-alpha@sourceware.org Subject: Re: [v4] Update mmap() flags and errors lists In-Reply-To: (message from Mathieu Desnoyers on Tue, 18 Jun 2024 16:13:04 -0400) Date: Tue, 18 Jun 2024 16:57:17 -0400 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.40 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Mathieu Desnoyers writes: > I will review this patch based on my understanding of the Linux mmap(2) > manual from Linux man-pages 6.03 2023-02-05. It is very much possible > that your intent is not to match that specific syscall man page, in > which case feel free to dismiss my concerns. My intent was to not cut-n-paste the man pages, as the licenses do not allow that. So I summarized the man pages into my notes, and at a later date, confirmed those notes against the kernel sources, and wrote my text. So there's no intent to match or not match the man pages, just intent to keep the work separated enough to not cause copyright problems. >> +@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. >> +@item MAP_POPULATE >> +@itemx MAP_NONBLOCK >> +These two are opposites. @code{MAP_POPULATE} is a hint that requests >> +that the kernel read-ahead a file-backed mapping, causing more pages >> +to be mapped before they're needed. @code{MAP_NONBLOCK} is a hint >> +that requests that the kernel @emph{not} attempt such, only mapping >> +pages when they're actually needed. Note that neither of these hints >> +affects future paging activity, use @code{mlock} if such needs to be >> +controlled. > > This explanation does not match my understanding of the mmap(2) man > page. MAP_NONBLOCK appears to be only meaningful in conjunction _with_ > MAP_POPULATE. I suspect the goal here when those are combined is to > opportunistically populate the page table entries when those do not > require read-ahead from a file (AFAIU). Sigh ;-) >> + >> +@item MAP_NORESERVE >> +Asks the kernel to not reserve physical backing for a mapping. > > What is "physical backing" ? I guess that you mean not backed by a swap > block device (or anything that requires I/O), but I am not sure that > "physical backing" conveys this clearly. I'll reword this some. >> +@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? >> +@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... >> +@item EBADF >> + >> +The @var{fd} passes is invalid, and a valid file descriptor is > > passes -> passed ? Sigh ;-) >> -@item ENODEV >> - >> -This file is of a type that doesn't support mapping. >> +There is not enough memory for the operation, the process is out of >> +address space, or there are too many mappings. On Linux, the maximum >> +number of mappings can be controlled via >> +@file{/proc/sys/vm/max_map_count} or, if your OS supports it, via >> +the @code{vm.max_map_count} @code{sysctl} setting. > > Also getrlimit(2) RLIMIT_DATA exceeded, or @addr exceeds virtual address > space of the CPU. Noted. >> +@item EPERM >> + >> +@code{PROT_EXEC} was requested but the file is on a filesystem that >> +was mounted with execution denied. > > Also operation was prevented by a file seal (fcntl(2)). > Also MAP_HUGETLB flag was specified, but the caller was not priviledged. Noted.