This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug manual/6886] some imperfections in description of mmap()
- From: "adhemerval.zanella at linaro dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 11 Aug 2016 15:10:22 +0000
- Subject: [Bug manual/6886] some imperfections in description of mmap()
- Auto-submitted: auto-generated
- References: <bug-6886-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=6886
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 #1 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
" mmap description does not say what value of parameter length should be :
it gives impression that it can be
anything that is not larger than multiple of pagesize that is next higher
than size of file ;
is this correct ?"
POSIX states that it can be anything and also states the returned segment
shuld adressable for range [pa,pa+len). It is an implementation details if
underlaying granularity would be in page sizes.
" mmap() description does not mention what happens if writing beyond end of
file,
though i seem to remember reading somewhere that it causes a segfault ?"
man mmap:
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).
" mmap() description does not mention what happens if write to address that is
beyond end of filecontent but inside mapped size ; will it segfault ?"
Same as before.
" if a file is mmapped PROT_SHARED, and another process makes file smaller,
will my process segfault when writing beyond new end of file ?
is it possible to guard against this by locking file ?"
man mmap:
"MAP_SHARED 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).)"
"munmap description gives impression that if you do munmap it is not necessary
to use msync, but does not explicitly say so. is this indeed so ?"
Yes and manual now states when you should call msync.
As for BZ#6887 I will close this bug.
--
You are receiving this mail because:
You are on the CC list for the bug.