[Bug manual/6887] mmap documentation bugs, perhaps also 2 functional bugs

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=6887

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg
         Resolution|---                         |INVALID

--- Comment #3 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
I would suggest to next time when open bugs against kernel interfaces to
specify which architecture and kernel version the issues were observed. The
mmap interface has some arch-specific implementation and behaviours (for
instance MAP_32BIT on x86).

About the questionings:

* opening file rw and mmapping it w
  causes segfault at first write to a mapped memory location.
  (functional bug, therefore documentation bug until it is fixed).

  I did not observed in my testing system (x86_64 4.4.0-31-generic) and if it
is happening it is clearly a kernel issue.

* opening file w and mmapping it w causes mmap error 'permission denied',
  which is not mentioned in documentation
  (rather it is said that i may GET more permissions than i asked for).

  Again this is clearly a kernel issue if it is really happening.

* trying to read from an empty file generates a 'bus error',
  terminating process,
  which is not mentioned in documentation.

  This is a implementation detail which is covered by POSIX:

  "An implementation may generate SIGBUS signals when a reference would cause
an error in the mapped object, such as out-of-space condition." 

  And it is currently covered by manual as:

"ERRORS

  [...]

  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)."

* when mmapping an empty file, mmap() returns a valid address,
  but reading from this address causes a segfault.
  (functional bug, therefore documentation bug until fixed).

  This is the same issue as before.

* compiler didn't find O_READ ,
  though fcntl.h was #included,
  and both __USE_GNU and _GNU_SOURCE were #defined.
  (working around by using O_RDONLY is trivial, but it is a documentation bug)

  O_READ is GNU-specific identifier only used on GNU/Hurd.  GLIBC on Linux only
defines the POSIX name O_RDONLY.

* description of mremap says that it returns -1 on error,
  but this is not possible since it's returntype is void* .

  The manual states "On error, the value MAP_FAILED (that is, (void *) -1)".

* description of MS_ASYNC says
  "This tells `msync' to begin synchronization, but not to wait for it to
complete."
   which should be
   "This tells `msync' to begin synchronization, but to not wait for it to
complete."
   because it is confusing.
   (never mind whether it is official english ; it is braindamage.)

  The text has changed and it does not contain this wording any more.

* description of MAP_SHARED says
  "This specifies that writes to region will be written back to file."
   but it is valid (or at least it works) to use MAP_SHARED with MAP_ANON,
   in which case there is no file to write back to.
   Perhaps in this case MAP_SHARED controls whether other processes see changed
content ?

   It currenty states that "Share  this mapping.  Updates to the mapping are
visible to other processes that map this file, and are carried through to the
underlying file.  (To precisely control when updates are carried through to the
underlying file requires the use of msync(2).)"

So mostly of the mentioned issues are currently documented and some are just
user errors. I will close this bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.