Hello, everyone. It appears that in GNU/Hurd, memory mappings obtained by 'mmap' with MAP_SHARED and MAP_ANON as its flags are not being inherited by children processes. Here's a simple program that illustrates the issue: =============================== #include <stdio.h> #include <unistd.h> #include <sys/mman.h> #include <sys/wait.h> int main (void) { void *p = mmap (0, 4096, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0); if (p == MAP_FAILED) { puts ("mmap failed."); return (1); } int pid = fork (); if (pid < 0) { puts ("fork failed."); return (1); } else if (pid == 0) { *(int *)p = 69; puts ("value was set."); } else { int r; wait (&r); printf ("done waiting for the child" "\nvalue is: %d\n", *(int *)p); } return (0); } ================================== The parent process ends up printing zero, which is wrong. A quick inspection at the source code tells me that this code ends up calling 'vm_allocate' as an optimization when it sees that the user requested an anonymous mapping with protection RW. However, it's not taking into account that 'vm_allocate' has a default inheritance value of 'COPY'. An easy workaround is to simply remove the 'vm_allocate' optimization, and always use 'vm_map' by removing the if ((flags & (MAP_TYPE|MAP_INHERIT)) == MAP_ANON block.
The master branch has been updated by Samuel Thibault <sthibaul@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=c9536b7b9ddb111bded10e7252da28a6826771d1 commit c9536b7b9ddb111bded10e7252da28a6826771d1 Author: Samuel Thibault <samuel.thibault@ens-lyon.org> Date: Fri Aug 30 01:41:50 2019 +0200 hurd: Remove optimizing anonymous maps as __vm_allocate. Optimizing anonymous maps brings bugs, and does not optimize much anyway. [BZ #19903] * sysdeps/mach/hurd/mmap.c (__mmap): Remove optimizing anonymous maps as __vm_allocate.
Fixed by c9536b7b9ddb111bded10e7252da28a6826771d1 ("hurd: Remove optimizing anonymous maps as __vm_allocate.")
When marking a bug as FIXED, please set the target milestone to the first mainline release with the fix (so 2.31 at present) so the bug appears in the automatically-generated list of fixed bugs in NEWS.
Oh, right, Ok.