From 2603401fa1f899a8ff60ec6a134d5bd511073a9d Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <tschwinge@gnu.org>
Date: Tue, 7 Aug 2012 23:25:26 +0200
Subject: IRC.

---
 open_issues/glibc/t/tls-threadvar.mdwn | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

(limited to 'open_issues/glibc')

diff --git a/open_issues/glibc/t/tls-threadvar.mdwn b/open_issues/glibc/t/tls-threadvar.mdwn
index e72732ab..4afd8a1a 100644
--- a/open_issues/glibc/t/tls-threadvar.mdwn
+++ b/open_issues/glibc/t/tls-threadvar.mdwn
@@ -29,3 +29,32 @@ IRC, freenode, #hurd, 2011-10-23:
 
 After this has been done, probably the whole `__libc_tsd_*` stuff can be
 dropped altogether, and `__thread` directly be used in glibc.
+
+
+# IRC, freenode, #hurd, 2012-08-07
+
+    <tschwinge> r5219: Update libpthread patch to replace threadvar with tls
+      for pthread_self
+    <tschwinge> r5224: revert r5219 too, it's not ready either
+    <youpi> as the changelog says, the __thread revertal is because it posed
+      problems
+    <youpi> and I just didn't have any time to check them while the freeze was
+      so close
+    <tschwinge> OK.  What kind of problems?  Should it be reverted upstream,
+      too?
+    <youpi> I don't remember exactly
+    <youpi> it should just be fixed
+    <youpi> we can revert it upstream, but it'd be good that we manage to
+      progress, at some point...
+    <tschwinge> Of course -- however as long as we don't know what kind of
+      problem, it is a bit difficult.  ;-)
+    <youpi> since I didn't left a note, it was most probably a mere glibc run,
+      or boot with the patched libpthread
+    <youpi> *testsuite run
+    <tschwinge> OK.
+    <tschwinge> The libpthread testsuite doesn't show any issues with that
+      patch applied, though.  But I didn'T test anything else.
+    <tschwinge> youpi: Also, you have probably seen my glibc __thread errno
+      email -- rmcgrath wanted to find some time this week to comment/help, and
+      I take it you don't have any immediate comments to that issue?
+    <youpi> I saw the mails, but didn't investigate at all
-- 
cgit v1.3.1


From 3f1771b57a4ca604cfa5a947e478bc3d7f381c78 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <thomas@codesourcery.com>
Date: Sun, 16 Dec 2012 14:00:37 +0100
Subject: open_issues/binutils: 7c102198e4a1ecee9cf175bd4ad87ee435956cae
 (2012-12-16)

configure --enable-gold
---
 open_issues/binutils.mdwn      |  50 ++++++++++---
 open_issues/binutils_gold.mdwn |  16 ----
 open_issues/gcc.mdwn           |   4 +-
 open_issues/glibc/mremap.mdwn  | 163 ++---------------------------------------
 toolchain/logs                 |   2 +-
 5 files changed, 48 insertions(+), 187 deletions(-)
 delete mode 100644 open_issues/binutils_gold.mdwn

(limited to 'open_issues/glibc')

diff --git a/open_issues/binutils.mdwn b/open_issues/binutils.mdwn
index 2bbdc245..5c309d47 100644
--- a/open_issues/binutils.mdwn
+++ b/open_issues/binutils.mdwn
@@ -39,8 +39,8 @@ git log --reverse --topo-order --pretty=fuller --stat=$COLUMNS,$COLUMNS -w -p -C
 
 -->
 
-Last reviewed up to the [[Git mirror's 81a734055750a1de753adfd86f7ae9e1d72575e4
-(2012-12-15) sources|source_repositories/binutils]].
+Last reviewed up to the [[Git mirror's 7c102198e4a1ecee9cf175bd4ad87ee435956cae
+(2012-12-16) sources|source_repositories/binutils]].
 
   * Globally
 
@@ -123,11 +123,11 @@ Last reviewed up to the [[Git mirror's 81a734055750a1de753adfd86f7ae9e1d72575e4
 
 Here's a log of a binutils build run; this is from our [[Git
 repository|source_repositories/binutils]]'s `tschwinge/Paul_Desmond` branch,
-commit 81a734055750a1de753adfd86f7ae9e1d72575e4 (2012-12-15), run on
+commit 7c102198e4a1ecee9cf175bd4ad87ee435956cae (2012-12-16), run on
 kepler.SCHWINGE and coulomb.SCHWINGE.
 
     $ export LC_ALL=C
-    $ ../Paul_Desmond/configure --prefix="$PWD".install --with-sysroot=/ SHELL=/bin/dash CC=gcc-4.6 CXX=g++-4.6 2>&1 | tee log_build
+    $ ../Paul_Desmond/configure --prefix="$PWD".install --enable-gold --with-sysroot=/ SHELL=/bin/dash CC=gcc-4.6 CXX=g++-4.6 2>&1 | tee log_build
     [...]
     $ make 2>&1 | tee log_build_
     [...]
@@ -137,8 +137,8 @@ harmonized.  Debian GCC (which is used in binutils' testsuite) likes to pass
 `--sysroot=/` to `ld`, so we need to configure binutils with support for
 sysroots.
 
-This takes up around 130 MiB, and needs roughly 5 min on kepler.SCHWINGE and
-14 min on coulomb.SCHWINGE.
+This takes up around 900 MiB, and needs roughly 11 min on kepler.SCHWINGE and
+42 min on coulomb.SCHWINGE.
 
 <!--
 
@@ -155,13 +155,20 @@ formats, and more emulation vectors.
 
     $ toolchain/logs/process binutils build
 
+  * gold GNU/Linux vs. GNU/Hurd
+
+        -checking for glibc ifunc support... both
+        +checking for glibc ifunc support... dyn
+
+    Missing [[IFUNC]] support on GNU/Hurd.
+
 
 # Install
 
     $ make install 2>&1 | tee log_install
     [...]
 
-This takes up around 70 MiB, and needs roughly 1 min on kepler.SCHWINGE and 2
+This takes up around 150 MiB, and needs roughly 1 min on kepler.SCHWINGE and 3
 min on coulomb.SCHWINGE.
 
 
@@ -177,7 +184,7 @@ min on coulomb.SCHWINGE.
     $ make -k check 2>&1 | tee log_test
     [...]
 
-This needs roughly 4 min on kepler.SCHWINGE and 24 min on coulomb.SCHWINGE.
+This needs roughly 6 min on kepler.SCHWINGE and 42 min on coulomb.SCHWINGE.
 
 
 ## Analysis
@@ -213,7 +220,7 @@ This needs roughly 4 min on kepler.SCHWINGE and 24 min on coulomb.SCHWINGE.
         WARNING: program timed out.
         FAIL: gas/i386/rept
 
-  * IFUNC execution tests
+  * ld IFUNC execution tests
 
     Missing [[IFUNC]] support on GNU/Hurd.
 
@@ -221,3 +228,28 @@ This needs roughly 4 min on kepler.SCHWINGE and 24 min on coulomb.SCHWINGE.
 
         FAIL: Common symbol override ifunc test 1a
         FAIL: Common symbol override ifunc test 1b
+
+  * gold GNU/Linux vs. GNU/Hurd
+
+        -FAIL: relro_test.sh
+        +PASS: relro_test.sh
+
+        -PASS: ver_matching_test.sh
+        +FAIL: ver_matching_test.sh
+
+        -PASS: script_test_3
+        +FAIL: script_test_3
+
+        -PASS: tls_phdrs_script_test
+        +FAIL: tls_phdrs_script_test
+
+        -PASS: ifuncmain1static
+        -PASS: ifuncmain1picstatic
+        -PASS: ifuncmain2static
+        -PASS: ifuncmain2picstatic
+        -PASS: ifuncmain4static
+        -PASS: ifuncmain4picstatic
+        -PASS: ifuncmain5static
+        -PASS: ifuncmain5picstatic
+        -PASS: ifuncmain7static
+        -PASS: ifuncmain7picstatic
diff --git a/open_issues/binutils_gold.mdwn b/open_issues/binutils_gold.mdwn
deleted file mode 100644
index 9eeebf2d..00000000
--- a/open_issues/binutils_gold.mdwn
+++ /dev/null
@@ -1,16 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation,
-Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!tag open_issue_binutils open_issue_porting]]
-
-Have a look at gold / port as needed.
-
-Apparently it needs [[glibc/mremap]].
diff --git a/open_issues/gcc.mdwn b/open_issues/gcc.mdwn
index f5022c16..679cb6fb 100644
--- a/open_issues/gcc.mdwn
+++ b/open_issues/gcc.mdwn
@@ -112,9 +112,7 @@ Last reviewed up to the [[Git mirror's be3860ba8df48cca3253da4f02fd2d42d856ce80
 
   * `--enable-gnu-unique-object`
 
-  * `--enable-lto`, `--enable-gold`
-
-    [[binutils_gold]]
+  * `--enable-lto`
 
   * `--enable-indirect-function`
 
diff --git a/open_issues/glibc/mremap.mdwn b/open_issues/glibc/mremap.mdwn
index a293eea0..874c7ae0 100644
--- a/open_issues/glibc/mremap.mdwn
+++ b/open_issues/glibc/mremap.mdwn
@@ -10,177 +10,24 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_glibc]]
 
-[[!toc]]
-
+The Hurd does not currently support the `mremap` function.
 
-# binutils gold
+For the `MREMAP_MAYMOVE` case it is easy to work around; see
+`[binutils]/gold/mremap.c`, for example.
 
-## IRC, freenode, #hurd, 2011-01-12
-
-    <teythoon> I've been looking into building gold on hurd and it built fine
-      with one minor tweak
-    <teythoon> and it's working fine according to its test suite
-    <teythoon> the only problem is that the build system is failing to detect
-      the hurdish mremap which lives in libmemusage
-    <teythoon> on linux it is in the libc so the check succeeds
-    <teythoon> any hints on how to fix this properly?
-    <antrik> hm... it's strange that it's a different library on the Hurd
-    <antrik> are the implementations compatible?
-    <teythoon> antrik: it seems so, though the declarations differ slightly
-    <antrik> I guess the best thing is to ask on the appropriate list(s) why
-      they are different...
-    <teythoon> teythoon@ganymede:~/build/gold/binutils-2.21/gold$ grep -A1
-      mremap /usr/include/sys/mman.h 
-    <teythoon> extern void *mremap (void *__addr, size_t __old_len, size_t
-      __new_len, int __flags, ...) __THROW;
-    <teythoon> vs
-    <antrik> of course it would be possible to modify the configure script to
-      check for the Hurd variant too; but first we should establish whether
-      here is actually any reason for being different, or it's just some
-      historical artefact that should be fixed...
-    <teythoon> teythoon@ganymede:~/build/gold/binutils-2.21/gold$ fgrep 'extern
-      void *mremap' mremap.c 
-    <teythoon> extern void *mremap (void *, size_t, size_t, int, ...);
-    <teythoon> the problem is that the test fails to link due to the fact that
-      mremap isn't in the libc on hurd
-    <antrik> yeah, it would be possible for the configure script to check
-      whether it works when the hurdish extra library is added explicitely
-    <antrik> but again, I don't see any good reason for being different here in
-      the first place...
-    <teythoon> so should I create a patch to move mremap?
-    <antrik> if it's not too complicated, that would be nice... it's always
-      easier to discuss when you already have code :-)
-    <antrik> OTOH, asking first might spare you some useless work if it turns
-      out there *is* some reason for being different after all...
-    so where is the right place to discuss this?
-    <antrik> bug-hurd mailing list and/or glibc mailing list. not sure which
-      one is better -- I guess it doesn't hurt to crosspost...
+[[!toc]]
 
-[[mailing_lists/libc-alpha]] is the correct list, and cross-posting to
-[[mailing_lists/bug-hurd]] would be fine, too.
 
-    <teythoon> antrik: some further digging revealed that mremap belongs to
-      /lib/libmemusage.so on both hurd and linux
-    <teythoon> the only difference is that on linux there is a weak reference
-      to that function in /lib/libc-2.11.2.so
-    <teythoon> $ objdump -T /lib/libc-2.11.2.so | fgrep mremap
-    <teythoon> 00000000000cf7e0  w   DF .text  0000000000000028  GLIBC_2.2.5
-      mremap
-    <antrik> ah, it's probably simply a bug that we don't have this weak
-      reference too
-    <antrik> IIRC we had similar bugs before
-    <antrik> teythoon: can you provide a patch for that?
-    <teythoon> antrik: unfortunately I have no idea how that weak ref ended up
-      there
+# IRC, freenode, #hurd, 2011-01-12
 
-    <guillem> teythoon: also the libmemusage.s seems to be just a debugging
-      library to be used by LD_PRELOAD or similar
-    <guillem> which override those memory functions
-    <guillem> the libc should provide actual code for those functions, even if
-      the symbol is declared weak (so overridable)
-    <guillem> teythoon: are you sure that's the actual problem? can you paste
-      somewhere the build logs with the error?
-    <teythoon> guillem: sure
-    <teythoon> http://paste.debian.net/104437/
-    <teythoon> that's the part of config.log that shows the detection (or the
-      failure to detect it) of mremap
-    <teythoon> this results in HAVE_MREMAP not being defined
-    <teythoon> as a consequence it is declared in gold.h and this declaration
-      conflicts with the one from sys/mman.h http://paste.debian.net/104438/
-    <teythoon> on linux the test for mremap succeeds
-    <guillem> teythoon: hmm oh I guess it's just what that, mremap is linux
-      specific so it's not available on the hurd
-    <guillem> teythoon: I just checked glibc and seems to confirm that
-    <braunr> CONFORMING TO This call is Linux-specific, and should not be used
-      in programs intended to be portable.
-    <teythoon> ah okay
-    <teythoon> so I guess we shouldn't ship an header with that declaration...
-    <guillem> teythoon: yeah :/ good luck telling that to drepper :)
-    <guillem> teythoon: I guess he'll suggest that everyone else needs to get
-      our own copy of sys/mman.h
-    <guillem> s/our/their/
-    <teythoon> hm, so how should I proceed?
-    <braunr> what's your goal ?
-    <braunr> detecting mremap ?
-    <teythoon> making binutils/gold compile ootb on hurd
-    <teythoon> I picked it from the open issues page ;)
-    <braunr> well, if there is no mremap, you need a replacement
-    <teythoon> gold has a replacement
-    <braunr> ok
-    <braunr> so your problem is fixing the detection of mremap right ?
-    <teythoon> yes
-    <braunr> ok, that's a build system question then :/
-    <braunr> you need to ask an autotools guy
-    <teythoon> well, actually the build system correctly detects the absence of
-      mremap
-    <braunr> (gold does use the autotools right ?)
-    <teythoon> yes
-    <braunr> oh, i'm lost now (i admit i didn't read the whole issue :/)
-    <teythoon> it is just that the declaration in sys/mman.h conflicts with
-      their own declaration
-    <braunr> ah
-    <braunr> so in the absence of mremap, they use their own builtin function
-    <teythoon> yes
-    <teythoon> and according to the test suite it is working perfectly
-    <teythoon> gold that is
-    <teythoon> the declaration in mman.h has an extra __THROW
-    <guillem> a workaround would be to rename gold's mremap to something else,
-      gold_mremap for example
-    <braunr> that's really the kind of annoying issue
-    <braunr> you either have to change glibc, or gold
-    <guillem> yeah
-    <braunr> you'll face difficulty changing glibc, as guillem told you
-    <guillem> the correct solution though IMO is to fix glibc
-    <braunr> but this may be true for gold too
-    <braunr> guillem: i agree
     <antrik> maybe it would be easiest actually to implement mremap()?...
-    <braunr> but as this is something quite linux specific, it makes sense to
-      use another internal name, and wrap that to the linux mremap if it's
-      detected
     <braunr> antrik: i'm nto sure
-    <antrik> braunr: I don't think using such workarounds is a good
-      idea. clearly there would be no issue if the header file wouldn't be
-      incorrect on Hurd
-    <braunr> antrik: that's why i said i agree with guillem when he says "the
-      correct solution though IMO is to fix glibc"
-    <teythoon> what exactly is the problem with getting a patch into glibc?
-    <braunr> the people involved
-    <guillem> teythoon: and touching a generic header file
-    <braunr> but feel free to try, you could be lucky
-    <teythoon> but glibc is not an linux specific piece of software, right?
-    <braunr> teythoon: no, it's not
-    <guillem> erm...
-    <braunr> teythoon: but in practice, it is
-    <guillem> supposedly not :)
-    <antrik> braunr: BTW, by "easiest" I don't mean coding alone, but
-      coding+pushing upstream :-)
-    <guillem> so the problem is, misc/sys/mman.h should be a generic header and
-      as such not include linux specific parts, which are not present on hurd,
-      kfreebsd, etc etc
-    <braunr> antrik: yes, that's why guillem and i suggested the workaround
-      thing in gold
-    <antrik> that also requires pushing upstream. and quite frankly, if I were
-      the gold maintainer, I wouldn't accept it.
-    <guillem> but the easiest (and wrong) solution in glibc to avoid maintainer
-      conflict will probably be copying that file under hurd's glibc tree and
-      install that instead
     <braunr> antrik: implementing mremap could be relatively easy to do
       actually
     <braunr> antrik: IIRC, vm_map() supports overlapping
-    <antrik> well, actually the easiest solution would be to create a patch
-      that never goes upstream but is included in Debian, like many
-      others... but that's obviously not a good long-term plan
     <antrik> braunr: yes, I think so too
     <antrik> braunr: haven't checked, but I have a vague recollection that the
       fundamentals are pretty much there
-    <antrik> teythoon: so, apart from an ugly workaround in gold, there are
-      essentially three options: 1. implement mremap; 2. make parts of mman.h
-      conditional; 3. use our own copy of mman.h
-    <antrik> 1. would be ideal, but might be non-trivial; 2. would might be
-      tricky to get right, and even more tricky to get upstream; 3. would be
-      simple, but a maintenance burden in the long term
-    <teythoon> looking at golds replacement code (mmap & memcpy) 1 sounds like
-      the best option performance wise
 
 [[!taglink open_issue_glibc]]: check if it is possible to implement `mremap`.
 [[I|tschwinge]] remember some discussion about this, but have not yet worked on
diff --git a/toolchain/logs b/toolchain/logs
index 857158d0..b2218016 160000
--- a/toolchain/logs
+++ b/toolchain/logs
@@ -1 +1 @@
-Subproject commit 857158d0abdbd9c3be942dda05b33a97115cff54
+Subproject commit b2218016e588eed4e81eeb85b35f58bcd784da48
-- 
cgit v1.3.1


From fc4d1650f3e35a1cff0111ae3808c61d44346f1f Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <thomas@codesourcery.com>
Date: Thu, 20 Dec 2012 22:20:05 +0100
Subject: glibc/mmap: Extend.

---
 glibc/mmap.mdwn                                | 402 +++++++++++++++++++++----
 hurd/interface/io_map.mdwn                     |  11 +
 hurd/porting/guidelines.mdwn                   |   1 +
 microkernel/mach/external_pager_mechanism.mdwn |  14 +-
 microkernel/mach/interface/vm_map.mdwn         |  16 +
 open_issues/git_nfs_mmap.mdwn                  |   4 +-
 open_issues/glibc.mdwn                         |  20 +-
 open_issues/glibc/mremap.mdwn                  |   2 +
 user/kam.mdwn                                  |   8 +-
 9 files changed, 391 insertions(+), 87 deletions(-)
 create mode 100644 hurd/interface/io_map.mdwn
 create mode 100644 microkernel/mach/interface/vm_map.mdwn

(limited to 'open_issues/glibc')

diff --git a/glibc/mmap.mdwn b/glibc/mmap.mdwn
index 09b0b65d..cddd0584 100644
--- a/glibc/mmap.mdwn
+++ b/glibc/mmap.mdwn
@@ -8,91 +8,379 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
 is included in the section entitled [[GNU Free Documentation
 License|/fdl]]."]]"""]]
 
-There are two implementations of `mmap` for GNU Hurd:
-`sysdeps/mach/hurd/mmap.c` (main implementation) and
-`sysdeps/mach/hurd/dl-sysdep.c` (*Minimal mmap implementation sufficient for
-initial loading of shared libraries.*).
+The `mmap` call is generally supported on GNU Hurd, as indicated by
+`_POSIX_MAPPED_FILES` (`sysconf (_SC_MAPPED_FILES)`).
 
-  * `MAP_COPY`
 
-    What exactly is that?  `elf/dl-load.c` has some explanation.
-    <http://lkml.indiana.edu/hypermail/linux/kernel/0110.1/1506.html>
+# Flags
 
-    It is only handled in `dl-sysdep.c`, when `flags & (MAP_COPY|MAP_PRIVATE)`
-    is used for `vm_map`'s `copy` parameter, and `mmap.c` uses `! (flags &
-    MAP_SHARED)` instead, which seems inconsistent?
+*Flags contain mapping type, sharing type and options.*
 
+  * *Mapping type (must choose one and only one of these).*
 
-# `io_map` Failure
+      * `MAP_FILE` (*Mapped from a file or device.*)
 
-This is the [[libnetfs: `io_map`|open_issues/libnetfs_io_map]] issue.
+      * `MAP_ANON`/`MAP_ANONYMOUS` (*Allocated from anonymous virtual memory.*)
 
-[[!tag open_issue_glibc]]
+    Even though it is not defined to zero (it is for the Linux kernel; why not
+    for us?), `MAP_FILE` is the default and can be omitted.
 
-Review of `mmap` usage in generic bits of glibc, based on
-a1bcbd4035ac2483dc10da150d4db46f3e1744f8 (2012-03-11), listing these cases
-where failure (due to `io_map` failing; that is, invocations where a `fd` is
-passed) is not properly handled.
+  * *Sharing types (must choose one and only one of these).*
 
-`catgets/open_catalog.c`, `iconv/gconv_cache.c`, `intl/loadmsgcat.c`,
-`locale/loadlocale.c` have fallback code for the `MAP_FAILED` case.
+      * `MAP_SHARED` (*Share changes.*)
 
-[[tschwinge]]'s current plan is to make the following cases do the same (if
-that is possible); probably by introducing a generic `mmap_or_read` function,
-that first tries `mmap` (and that will succeed on Linux-based systems and also
-on Hurd-based, if it's backed by [[hurd/libdiskfs]]), and if that fails tries
-`mmap` on anonymous memory and then fills it by `read`ing the required data.
-This is also what the [[hurd/exec]] server is doing (and is the reason that the
-`./true` invocation on [[libnetfs: `io_map`|open_issues/libnetfs_io_map]]
-works, to my understanding): see `exec.c:prepare`, if `io_map` fails,
-`e->filemap == MACH_PORT_NULL`; then `exec.c:map` (as invoked from
-`exec.c:load_section`, `exec.c:check_elf`, `exec.c:do_exec`, or
-`hashexec.c:check_hashbang`) will use `io_read` instead.
+      * `MAP_PRIVATE` (*Changes private; copy pages on write.*)
 
-Doing so potentially means reading in a lot of unused data -- but we probably
-can't do any better?
+      * `MAP_COPY` (*Virtual copy of region at mapping time.*)
 
-In parallel (or even alternatively?), it should be researched how Linux (or any
-other kernel) implements `mmap` on NFS and similar file systems, and then
-implement the same in [[hurd/libnetfs]] and/or [[hurd/translator/nfs]], etc.
+    For us, `MAP_PRIVATE` is the default (is defined to zero), for the Linux
+    kernel, one of `MAP_SHARED` or `MAP_PRIVATE` has to be specified
+    explicitly.
+
+    The Linux kernel does not support `MAP_COPY`, and as per the comment in
+    `elf/dl-load.c`, `MAP_PRIVATE | MAP_DENYWRITE` is Linux' replacement for
+    `MAP_COPY`.  However, `MAP_DENYWRITE` is defunct (`mmap` manpage).
+
+    In contrast to `MAP_COPY`, for `MAP_PRIVATE` *it is unspecified whether
+    changes made to the file after the `mmap` call are visible in the mapped
+    region* (`mmap` manpage).
+
+    `MAP_COPY`:
+
+        What exactly is that?  `elf/dl-load.c` has some explanation.
+        <http://lkml.indiana.edu/hypermail/linux/kernel/0110.1/1506.html>
+
+        It is only handled in `dl-sysdep.c`, when `flags &
+        (MAP_COPY|MAP_PRIVATE)` is used for
+        [[`vm_map`|microkernel/mach/interface/vm_map]]'s `copy` parameter, and
+        `mmap.c` uses `! (flags & MAP_SHARED)` instead, which seems
+        inconsistent?
+
+        Usage in glibc:
+
+          * `catgets/open_catalog.c:__open_catalog`,
+            `locale/loadlocale.c:_nl_load_locale`: *Linux seems to lack read-only
+            copy-on-write.*
+
+  * `MAP_TYPE` (*Mask for type field.*/*Mask for type of mapping.*)
+
+    [[!tag open_issue_glibc]]In `bits/mman.h` this is described and defined to
+    be a mask for the *mapping* type, in the `bits/mman.h` files corresponding
+    to Linux kernel it is described an defined to be a mask for the *sharing*
+    type.
+
+  * *Other flags.*
+
+      * `MAP_FIXED` (*Map address must be exactly as requested.*)
+
+        If the memory region is already in use, an unmap is attempted before
+        (re-)mapping it.
+
+        [[!tag open_issue_glibc]]The following text should be improved:
+
+        `[glibc]/llio.texi` says:
+        
+            @var{address} gives a preferred starting address for the mapping.
+            @code{NULL} expresses no preference. Any previous mapping at that
+            address is automatically removed. [...]
+
+        The comments in `misc/sys/mman.h`, `misc/mmap.c`, `misc/mmap64.c`,
+        `ports/sysdeps/unix/sysv/linux/hppa/mmap.c`, and
+        `sysdeps/mach/hurd/mmap.c` have a better wording:
+
+            A successful `mmap' call
+            deallocates any previous mapping for the affected region.
+
+        This is correct insofar that for `MAP_FIXED` indeed it is first
+        unmapped if already in use, and for the regular cases, an address will
+        be chosen that has no previous mapping.
+
+      * `MAP_NOEXTEND` (*For `MAP_FILE`, don't change file size.*)
+
+        Referenced in `[hurd]/TODO` as unimplemented.
+
+      * `MAP_HASSEMPHORE` (*Region may contain semaphores.*)
+
+      * `MAP_INHERIT` (*Region is retained after exec.*)
+
+  * Linux-specific flags
+
+      * `MAP_GROWSDOWN` (*Stack-like segment.*), `MAP_GROWSUP` (*Register
+        stack-like segment.*)
+
+        See `mmap` manpage.
+
+      * `MAP_DENYWRITE` (*`ETXTBSY`*)
+
+        As per the comment in `elf/dl-load.c`, `MAP_PRIVATE | MAP_DENYWRITE` is
+        Linux' replacement for `MAP_COPY`.  However, `MAP_DENYWRITE` is defunct
+        (`mmap` manpage).
+
+      * `MAP_EXECUTABLE` (*Mark it as an executable.*)
+
+      * `MAP_LOCKED` (*Lock the mapping.*)
+
+        ... à la `mlock`.  Not implemented for us, but probably
+        could[[open_issue_glibc]].
+
+      * `MAP_NORESERVE` (*Don't check for reservations.*)
+
+        See `mmap` manpage.
+
+        From [[hurd/porting/guidelines]]: *Not POSIX, but we could implement
+        it.*
+
+      * `MAP_POPULATE` (*Populate (prefault) pagetables.*)
+
+        From the `mmap` manpage:
+
+            Populate (prefault) page tables for a mapping.  For a file mapping,
+            this causes read-ahead on the file.  Later accesses to the mapping
+            will not be blocked by page faults.  MAP_POPULATE is only supported
+            for private mappings since Linux 2.6.23.
+
+        Unknown Linux kernel version, `mm/mmap.c`:
+
+                if (vm_flags & VM_LOCKED) {
+                        if (!mlock_vma_pages_range(vma, addr, addr + len))
+                                mm->locked_vm += (len >> PAGE_SHIFT);
+                } else if ((flags & MAP_POPULATE) && !(flags & MAP_NONBLOCK))
+                        make_pages_present(addr, addr + len);
+                return addr;
+
+        Is only advisory, so can worked around with `#define MAP_POPULATE 0`,
+        8069478040336a7de3461be275432493cc7e4c91.
+
+      * `MAP_NONBLOCK` (*Do not block on IO.*)
+
+        From the `mmap` manpage:
+
+            Only meaningful in conjunction with MAP_POPULATE.  Don't perform
+            read-ahead: only create page tables entries for pages that are
+            already present in RAM.  Since Linux 2.6.23, this flag causes
+            MAP_POPULATE to do nothing.  One day the combination of
+            MAP_POPULATE and MAP_NONBLOCK may be reimplemented.
+
+      * `MAP_STACK` (*Allocation is for a stack.*)
 
-Here, also probably the whole mapping region [has to be
-read](http://lists.gnu.org/archive/html/bug-hurd/2001-10/msg00306.html) at
-`mmap` time.
+        See `mmap` manpage.
 
-List of files without fallback code for the *`MAP_FAILED` due to `io_map`
-failed* case:
+      * `MAP_HUGETLB` (*Create huge page mapping.*)
 
-  * `elf/cache.c`
+        See `mmap` manpage.
 
-  * `elf/dl-load.c`
+      * `MAP_32BIT` (*Only give out 32-bit addresses.*)
 
-  * `elf/dl-misc.c`
+        See `mmap` manpage.
 
-  * `elf/dl-profile.c`
 
-  * `elf/readlib.c`
+# Implementation
 
-  * `elf/sprof.c`
+Essentially, `mmap` is implemented by means of
+[[`io_map`|hurd/interface/io_map]] (not for `MAP_ANON`) followed by
+[[`vm_map`|microkernel/mach/interface/vm_map]].
 
-  * `locale/loadarchive.c`
+There are two implementations: `sysdeps/mach/hurd/mmap.c` (main implementation)
+and `sysdeps/mach/hurd/dl-sysdep.c` (*Minimal mmap implementation sufficient
+for initial loading of shared libraries.*).
 
-  * `locale/programs/locale.c`
 
-  * `locale/programs/locarchive.c`
+## `mmap ("/dev/zero")`
 
-  * `nscd/connections.c`
+[[!tag open_issue_glibc open_issue_hurd]]Do we implement that (equivalently to
+`MAP_ANON`)?
 
-  * `nscd/nscd_helper.c`
 
-  * `nss/makedb.c`
+## Mapping Size
 
-  * `nss/nss_db/db-open.c`
+From the `mmap` manpage:
 
-  * Omitted:
+    A file is mapped in multiples of the page size.  For a file that is not a
+    multiple of the page size, the remaining memory is zeroed when mapped, and
+    writes to that region are not written out to the file.  The effect of
+    changing the size of the underlying file of a mapping on the pages that
+    correspond to added or removed regions of the file is unspecified.
 
-      * `nptl/`
+[[!tag open_issue_glibc]]Do we implement that?
 
-      * `sysdeps/unix/sparc/`
 
-      * `sysdepts/unix/sysv/linux/`
+## Use of a Mapped Region
+
+From the `mmap` manpage:
+
+    Use of a mapped region can result in these signals:
+    
+    SIGSEGV Attempted write into a region mapped as read-only.
+    
+    SIGBUS  Attempted access to a portion of the buffer that does not
+            correspond to the file (for example, beyond the end of the file,
+            including the case where another process has truncated the file).
+
+[[!tag open_issue_glibc]]Do we implement that?
+
+
+# Usage in glibc itself
+
+Review of `mmap` usage in generic bits of glibc (omitted: `nptl/`,
+`sysdeps/unix/sparc/`, `sysdepts/unix/sysv/linux/`), based on
+a1bcbd4035ac2483dc10da150d4db46f3e1744f8 (2012-03-11).  `MAP_FILE` is the
+interesting case; `MAP_ANON` is generally fine.  Some of the `mmap` usages in
+glibc have fallback code for the `MAP_FAILED` case, some do not.
+
+    catgets/open_catalog.c:    (struct catalog_obj *) __mmap (NULL, st.st_size, PROT_READ,
+    catgets/open_catalog.c-                                  MAP_FILE|MAP_COPY, fd, 0);
+
+Has fallback for `MAP_FAILED`.
+
+    elf/cache.c:    = mmap (NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
+    elf/cache.c:    = mmap (NULL, aux_cache_size, PROT_READ, MAP_PRIVATE, fd, 0);
+
+No fallback for `MAP_FAILED`.
+
+    elf/dl-load.c:        l->l_map_start = (ElfW(Addr)) __mmap ((void *) mappref, maplength,
+    elf/dl-load.c-                                              c->prot,
+    elf/dl-load.c-                                              MAP_COPY|MAP_FILE,
+    elf/dl-load.c-                                              fd, c->mapoff);
+    elf/dl-load.c:            && (__mmap ((void *) (l->l_addr + c->mapstart),
+    elf/dl-load.c-                        c->mapend - c->mapstart, c->prot,
+    elf/dl-load.c-                        MAP_FIXED|MAP_COPY|MAP_FILE,
+    elf/dl-load.c-                        fd, c->mapoff)
+
+No fallback for `MAP_FAILED`.
+
+    elf/dl-misc.c:            result = __mmap (NULL, *sizep, prot,
+    elf/dl-misc.c-#ifdef MAP_COPY
+    elf/dl-misc.c-                             MAP_COPY
+    elf/dl-misc.c-#else
+    elf/dl-misc.c-                             MAP_PRIVATE
+    elf/dl-misc.c-#endif
+    elf/dl-misc.c-#ifdef MAP_FILE
+    elf/dl-misc.c-                             | MAP_FILE
+    elf/dl-misc.c-#endif
+    elf/dl-misc.c-                             , fd, 0);
+
+No fallback for `MAP_FAILED`.
+
+    elf/dl-profile.c:  addr = (struct gmon_hdr *) __mmap (NULL, expected_size, PROT_READ|PROT_WRITE,
+    elf/dl-profile.c-                                  MAP_SHARED|MAP_FILE, fd, 0);
+
+No fallback for `MAP_FAILED`.
+
+    elf/readlib.c:  file_contents = mmap (0, statbuf.st_size, PROT_READ, MAP_SHARED,
+    elf/readlib.c-                        fileno (file), 0);
+
+No fallback for `MAP_FAILED`.
+
+    elf/sprof.c:      result->symbol_map = mmap (NULL, max_offset - min_offset,
+    elf/sprof.c-                           PROT_READ, MAP_SHARED|MAP_FILE, symfd,
+    elf/sprof.c-                           min_offset);
+    elf/sprof.c:  addr = mmap (NULL, st.st_size, PROT_READ, MAP_SHARED|MAP_FILE, fd, 0);
+
+No fallback for `MAP_FAILED`.
+
+    iconv/gconv_cache.c:  gconv_cache = __mmap (NULL, cache_size, PROT_READ, MAP_SHARED, fd, 0);
+    iconv/iconv_charmap.c:            && ((addr = mmap (NULL, st.st_size, PROT_READ, MAP_PRIVATE,
+    iconv/iconv_charmap.c-                              fd, 0)) != MAP_FAILED))
+    iconv/iconv_prog.c:           && ((addr = mmap (NULL, st.st_size, PROT_READ, MAP_PRIVATE,
+    iconv/iconv_prog.c-                             fd, 0)) != MAP_FAILED))
+
+Have fallback for `MAP_FAILED`.
+
+    intl/loadmsgcat.c:  data = (struct mo_file_header *) mmap (NULL, size, PROT_READ,
+    intl/loadmsgcat.c-                                     MAP_PRIVATE, fd, 0);
+
+Has fallback for `MAP_FAILED`.
+
+    libio/fileops.c:        p = __mmap (NULL, st.st_size, PROT_READ, MAP_SHARED,
+    libio/fileops.c-                    fp->_fileno, 0);
+    libio/fileops.c:      p = __mmap (NULL, st.st_size, PROT_READ, MAP_SHARED, fp->_fileno, 0);
+
+Has fallback for `MAP_FAILED`.
+
+    locale/loadarchive.c:      result = __mmap64 (NULL, mapsize, PROT_READ, MAP_FILE|MAP_COPY, fd, 0);
+    locale/loadarchive.c:   result = __mmap64 (NULL, mapsize, PROT_READ, MAP_FILE|MAP_COPY,
+    locale/loadarchive.c-                      fd, 0);
+    locale/loadarchive.c:   addr = __mmap64 (NULL, to - from, PROT_READ, MAP_FILE|MAP_COPY,
+    locale/loadarchive.c-                    fd, from);
+
+Some have fallback for `MAP_FAILED`.
+
+    locale/programs/locale.c:               void *mapped = mmap64 (NULL, st.st_size, PROT_READ,
+    locale/programs/locale.c-                                      MAP_SHARED, fd, 0);
+    locale/programs/locale.c:                   && ((mapped = mmap64 (NULL, st.st_size, PROT_READ,
+    locale/programs/locale.c-                                         MAP_SHARED, fd, 0))
+    locale/programs/locale.c:  addr = mmap64 (NULL, len, PROT_READ, MAP_SHARED, fd, 0);
+    locale/programs/locarchive.c:      void *p = mmap64 (NULL, RESERVE_MMAP_SIZE, PROT_NONE, MAP_SHARED, fd, 0);
+    locale/programs/locarchive.c:  p = mmap64 (p, total, PROT_READ | PROT_WRITE, MAP_SHARED | xflags, fd, 0);
+    locale/programs/locarchive.c:  void *p = mmap64 (ah->addr + start, st.st_size - start,
+    locale/programs/locarchive.c-             PROT_READ | PROT_WRITE, MAP_SHARED | MAP_FIXED,
+    locale/programs/locarchive.c-             ah->fd, start);
+    locale/programs/locarchive.c:    ah->addr = mmap64 (ah->addr, st.st_size, PROT_READ | PROT_WRITE,
+    locale/programs/locarchive.c-                MAP_SHARED | MAP_FIXED, ah->fd, 0);
+    locale/programs/locarchive.c:      ah->addr = mmap64 (NULL, st.st_size, PROT_READ | PROT_WRITE,
+    locale/programs/locarchive.c-                  MAP_SHARED, ah->fd, 0);
+    locale/programs/locarchive.c:  p = mmap64 (p, total, PROT_READ | PROT_WRITE, MAP_SHARED | xflags, fd, 0);
+    locale/programs/locarchive.c:  ah->addr = mmap64 (p, st.st_size, PROT_READ | (readonly ? 0 : PROT_WRITE),
+    locale/programs/locarchive.c-              MAP_SHARED | xflags, fd, 0);
+    locale/programs/locarchive.c:     data[cnt].addr = mmap64 (NULL, st.st_size, PROT_READ, MAP_SHARED,
+    locale/programs/locarchive.c-                              fd, 0);
+
+No fallback for `MAP_FAILED`.
+
+    nscd/connections.c:           else if ((mem = mmap (NULL, dbs[cnt].max_db_size,
+    nscd/connections.c-                                 PROT_READ | PROT_WRITE,
+    nscd/connections.c-                                 MAP_SHARED, fd, 0))
+    nscd/connections.c:               || (mem = mmap (NULL, dbs[cnt].max_db_size,
+    nscd/connections.c-                               PROT_READ | PROT_WRITE,
+    nscd/connections.c-                               MAP_SHARED, fd, 0)) == MAP_FAILED)
+    nscd/nscd_helper.c:  void *mapping = __mmap (NULL, mapsize, PROT_READ, MAP_SHARED, mapfd, 0);
+
+No fallback for `MAP_FAILED`.
+
+    nss/makedb.c:  const struct nss_db_header *header = mmap (NULL, st.st_size, PROT_READ,
+    nss/makedb.c-                                      MAP_PRIVATE|MAP_POPULATE, fd, 0);
+    nss/nss_db/db-open.c:   mapping->header = mmap (NULL, header.allocate, PROT_READ,
+    nss/nss_db/db-open.c-                           MAP_PRIVATE, fd, 0);
+
+No fallback for `MAP_FAILED`.
+
+    posix/tst-mmap.c:  ptr = mmap (NULL, 1000, PROT_READ, MAP_SHARED, fd, ps);
+    posix/tst-mmap.c:  ptr = mmap64 (NULL, 1000, PROT_READ, MAP_SHARED, fd, ps);
+    rt/tst-mqueue3.c:  void *mem = mmap (NULL, ps, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
+    rt/tst-mqueue5.c:  void *mem = mmap (NULL, ps, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
+    rt/tst-shm.c:  mem = mmap (NULL, 4000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
+    stdio-common/tst-fmemopen.c:  if ((mmap_data = (char *) mmap (NULL, fs.st_size, PROT_READ,
+    stdio-common/tst-fmemopen.c-                            MAP_SHARED, fd, 0)) == MAP_FAILED)
+
+No fallback for `MAP_FAILED`.
+
+
+## `io_map` Failure
+
+This is the [[libnetfs: `io_map`|open_issues/libnetfs_io_map]] issue.
+
+[[!tag open_issue_glibc open_issue_hurd]]
+[[tschwinge]]'s current plan is to make the following cases do the same (if
+that is possible); probably by introducing a generic `mmap_or_read` function,
+that first tries `mmap` (and that will succeed on Linux-based systems and also
+on Hurd-based, if it's backed by [[hurd/libdiskfs]]), and if that fails tries
+`mmap` on anonymous memory and then fills it by `read`ing the required data.
+This is also what the [[hurd/exec]] server is doing (and is the reason that the
+`./true` invocation on [[libnetfs: `io_map`|open_issues/libnetfs_io_map]]
+works, to my understanding): see `exec.c:prepare`, if `io_map` fails,
+`e->filemap == MACH_PORT_NULL`; then `exec.c:map` (as invoked from
+`exec.c:load_section`, `exec.c:check_elf`, `exec.c:do_exec`, or
+`hashexec.c:check_hashbang`) will use `io_read` instead.
+
+Doing so potentially means reading in a lot of unused data -- but we probably
+can't do any better?
+
+In parallel (or even alternatively?), it should be researched how Linux (or any
+other kernel) implements `mmap` on NFS and similar file systems, and then
+implement the same in [[hurd/libnetfs]] and/or [[hurd/translator/nfs]], etc.
+
+Here, also probably the whole mapping region [[!message-id desc="has to be
+read" "871yjkl50c.fsf@becket.becket.net"]] ([bug-hurd list
+archive](http://lists.gnu.org/archive/html/bug-hurd/2001-10/msg00306.html)) at
+`mmap` time.  Then, only `MAP_PRIVATE` (or rather: `MAP_COPY`) is possible, but
+not `MAP_SHARED`.
diff --git a/hurd/interface/io_map.mdwn b/hurd/interface/io_map.mdwn
new file mode 100644
index 00000000..11a59a51
--- /dev/null
+++ b/hurd/interface/io_map.mdwn
@@ -0,0 +1,11 @@
+[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+Used in [[glibc]] for implementing [[glibc/mmap]].
diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn
index 2618cd90..aabf0345 100644
--- a/hurd/porting/guidelines.mdwn
+++ b/hurd/porting/guidelines.mdwn
@@ -275,6 +275,7 @@ Oh, we should probably provide it.
 ## <a name="MAP_NORESERVE"> `MAP_NORESERVE` </a>
 
 Not POSIX, but we could implement it.
+See [[glibc/mmap]].
 
 ## <a name="O_DIRECT"> `O_DIRECT` </a>
 
diff --git a/microkernel/mach/external_pager_mechanism.mdwn b/microkernel/mach/external_pager_mechanism.mdwn
index 05a6cc56..54492b71 100644
--- a/microkernel/mach/external_pager_mechanism.mdwn
+++ b/microkernel/mach/external_pager_mechanism.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2002, 2007, 2008, 2010, 2011 Free Software
+[[!meta copyright="Copyright © 2002, 2007, 2008, 2010, 2011, 2012 Free Software
 Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -23,8 +23,8 @@ latter.
 In Mach, a [[task]]'s [[virtual_address_space]] consists of references to
 [[memory_object]]s.
 
-To associate a memory object with a portion of a task's
-address space, `vm_map` is invoked on a capability designating
+To associate a memory object with a portion of a task's address space,
+[[`vm_map`|interface/vm_map]] is invoked on a capability designating
 the task and passing a reference to the memory object
 and the offset at which to install it.  (The first time
 a task maps an object, Mach sends an initialization message
@@ -69,8 +69,8 @@ it to the port set that it is listening on and returns a capability (a port
 send right) to the client.
 
 (C) The client attempts to map the object into its address space using
-the `vm_map` RPC.  It passes a reference to the port that the server gave
-it to the vm server (typically Mach).
+the [[`vm_map`|interface/vm_map]] RPC.  It passes a reference to the port that
+the server gave it to the vm server (typically Mach).
 
 (D) Since Mach has never seen the object before, it queues a
 `memory_object_init` on the given port along with a send right (the
@@ -84,8 +84,8 @@ structures to manage the mapping and then invokes the
 `memory_object_ready` method on the control object.
 
 (F) The kernel sees that the manager is ready, sets up the appropriate
-mappings in the client's address space and then replies to the `vm_map` RPC indicating
-success.
+mappings in the client's address space and then replies to the
+[[`vm_map`|interface/vm_map]] RPC indicating success.
 
 There is nothing stopping others from playing *the kernel*.  This is
 not a security problem: clients must [[trust]] the server from whom they
diff --git a/microkernel/mach/interface/vm_map.mdwn b/microkernel/mach/interface/vm_map.mdwn
new file mode 100644
index 00000000..7232209b
--- /dev/null
+++ b/microkernel/mach/interface/vm_map.mdwn
@@ -0,0 +1,16 @@
+[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+Used in [[glibc]] for implementing [[glibc/mmap]], brk and sbrk, and *attempt
+to map page zero redzoned* (`[glibc]/hurd/hurdstartup.c:_hurd_startup`).
+
+[[!tag open_issue_glibc open_issue_gnumach]]It has an awkward mention in
+`[glibc]/sysdeps/mach/hurd/dl-sysdep.c:fmh`: *XXX loser kludge for vm\_map
+kernel bug*.
diff --git a/open_issues/git_nfs_mmap.mdwn b/open_issues/git_nfs_mmap.mdwn
index 21067022..e6726dfa 100644
--- a/open_issues/git_nfs_mmap.mdwn
+++ b/open_issues/git_nfs_mmap.mdwn
@@ -50,4 +50,6 @@ fails, and it isn't prepared to cope with that:
 This is the [[libnetfs: `io_map`|open_issues/libnetfs_io_map]] issue.
 
 There is a `NO_MMAP` conditional in Git's source code, but it is a compile-time
-conditional.
+conditional.  The fallback code in `compat/mmap.c:git_mmap` only supports
+`MAP_PRIVATE`, and simply `pread`s in the requested portion of a file.  This
+could be made a runtime fallback, too.
diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn
index 9212c402..a9c12e5c 100644
--- a/open_issues/glibc.mdwn
+++ b/open_issues/glibc.mdwn
@@ -189,7 +189,8 @@ Last reviewed up to the [[Git mirror's d3bd58cf0a027016544949ffd27300ac5fb01bb8
     `RLIMIT_RTTIME`, `SEEK_DATA` (`unistd.h`), `SEEK_HOLE` (`unistd.h`)
     `clock_adjtime`, `fallocate`, `fallocate64`, `name_to_handle_at`,
     `open_by_handle_at`, `process_vm_readv`, `process_vm_writev`, `sendmmsg`,
-    `setns`, `sync_file_range`
+    `setns`, `sync_file_range`, [[`mremap`|mremap]] and [[several
+    `MAP_*`|glibc/mmap]]
 
       * `chflags`
 
@@ -269,8 +270,6 @@ Last reviewed up to the [[Git mirror's d3bd58cf0a027016544949ffd27300ac5fb01bb8
               initialization
             <tschwinge> OK, that at least matches my understanding.
 
-      * [[`mremap`|mremap]]
-
       * `syncfs`
 
         We should be easily able to implement that one.
@@ -286,21 +285,6 @@ Last reviewed up to the [[Git mirror's d3bd58cf0a027016544949ffd27300ac5fb01bb8
         Do we support `AT_FDCWD` et al.?
         (80b4e5f3ef231702b24d44c33e8dceb70abb3a06.)
 
-      * `MAP_POPULATE` (`mmap`, `sys/mman.h`) -- *Populate (prefault)
-        pagetables.*
-
-        Some Linux kernel version, `mm/mmap.c`:
-
-                if (vm_flags & VM_LOCKED) {
-                        if (!mlock_vma_pages_range(vma, addr, addr + len))
-                                mm->locked_vm += (len >> PAGE_SHIFT);
-                } else if ((flags & MAP_POPULATE) && !(flags & MAP_NONBLOCK))
-                        make_pages_present(addr, addr + len);
-                return addr;
-
-        Is only advisory, so can worked around with `#define MAP_POPULATE 0`,
-        8069478040336a7de3461be275432493cc7e4c91.
-
       * `t/opendirat`: `opendirat` (`scandirat`, `scandirat64`)
 
         Need changes equivalent to c55fbd1ea768f9fdef34a01377702c0d72cbc213 +
diff --git a/open_issues/glibc/mremap.mdwn b/open_issues/glibc/mremap.mdwn
index 874c7ae0..c17506d7 100644
--- a/open_issues/glibc/mremap.mdwn
+++ b/open_issues/glibc/mremap.mdwn
@@ -15,6 +15,8 @@ The Hurd does not currently support the `mremap` function.
 For the `MREMAP_MAYMOVE` case it is easy to work around; see
 `[binutils]/gold/mremap.c`, for example.
 
+Also see the discussion of [[glibc/mmap]].
+
 [[!toc]]
 
 
diff --git a/user/kam.mdwn b/user/kam.mdwn
index 8ee68866..c16908c3 100644
--- a/user/kam.mdwn
+++ b/user/kam.mdwn
@@ -1,12 +1,12 @@
-[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2008, 2012 Free Software Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
 document under the terms of the GNU Free Documentation License, Version 1.2 or
 any later version published by the Free Software Foundation; with no Invariant
 Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled
-[[GNU Free Documentation License|/fdl]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
 
 [[!meta title="Karim Allah Ahmed"]]
 
@@ -67,7 +67,7 @@ Stage 1:
 
 * (./) port OSF Mach's clustered pagein during 'page faults' ( [src]/vm/vm_fault.c )
 * (./) port "cluster_size" attribute of memory objects from OSF Mach.
-* (./) port "behavior" attribute of vm_map entries from OSF Mach.
+* (./) port "behavior" attribute of [[`vm_map`|microkernel/mach/interface/vm_map]] entries from OSF Mach.
 
 ####29th of May - 2nd of June:
 
-- 
cgit v1.3.1