public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "nmiell at comcast dot net" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sources.redhat.com
Subject: [Bug libc/3458] New: posix_madvise(addr, len, POSIX_MADV_DONTNEED) discards data
Date: Sat, 04 Nov 2006 10:29:00 -0000	[thread overview]
Message-ID: <20061104102854.3458.nmiell@comcast.net> (raw)

POSIX describes the POSIX_MADV_DONTNEED parameter to posix_madvise as follows:

POSIX_MADV_DONTNEED
   Specifies that the application expects that it will not access the specified
range in the near future.

Linux describes and implements the MADV_DONTNEED parameter to madvise as follows:

MADV_DONTNEED
   Do not expect access in the near future.  (For the time being, the
application is finished with the given range, so the kernel can free resources
associated with it.) Subsequent accesses of pages in this range will succeed,
but will result either in re-loading of the memory contents from the underlying
mapped file (see mmap()) or zero-fill-on-demand pages for mappings without an
underlying file.

glibc transparently forwards calls to posix_madvise to madvise, which means that
POSIX conformant applications which use posix_madvise(addr, len,
POSIX_MADV_DONTNEED) will corrupt data.

Suggested fix: Implement posix_madvise as a small wrapper around madvise which
silently discards all calls using POSIX_MADV_DONTNEED, fails for values other
than POSIX_MADV_*, and forwards the remainder.

-- 
           Summary: posix_madvise(addr, len, POSIX_MADV_DONTNEED) discards
                    data
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: nmiell at comcast dot net
                CC: glibc-bugs at sources dot redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=3458

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


             reply	other threads:[~2006-11-04 10:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-04 10:29 nmiell at comcast dot net [this message]
2006-11-05  5:45 ` [Bug libc/3458] " nmiell at comcast dot net
2007-02-17  9:07 ` drepper at redhat dot com
2007-02-17 20:35 ` nmiell at comcast dot net
2007-02-18 13:56 ` aj at suse dot de
2007-02-21 19:04 ` drepper at redhat dot com
2007-03-01 18:13 ` samuel dot thibault at ens-lyon dot org
2007-03-01 18:15 ` samuel dot thibault at ens-lyon dot org
2007-07-12 14:57 ` cvs-commit at gcc dot gnu dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061104102854.3458.nmiell@comcast.net \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).