All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gianni Tedesco <giannit@securewave.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: mmap(MAP_PRIVATE) question
Date: Wed, 03 Sep 2003 15:37:08 +0200	[thread overview]
Message-ID: <1062596228.1356.17.camel@lemsip> (raw)
In-Reply-To: <20030903102804.GA21455@mail.jlokier.co.uk>

On Wed, 2003-09-03 at 12:28, Jamie Lokier wrote:
> The page cache page is mapped into the application just like a shared
> mapping, until the application writes to the mapped region and
> triggers the copy-on-write fault.

that clears it up somewhat :)

> On the other hand you may not.  On some of the architectures which
> Linux supports, the CPU's cache is not sufficiently coherent to
> guarantee that what is written with write(), or by another process,
> will be seen in this application's memory.  Indeed, you might see a
> mixture of some of the written data and some of the data before it was
> written, with no particular guarantee of which bits of data or in what
> order.

Well, the thing I'm interested in is people overwriting parts of shared
libraries (at least those opened with dlopen). In my tests, I am using
mmap/msync to overwrite the library rodata section with
MS_SYNC|MS_INVALIDATE. When I do this the running copy (using
MAP_PRIVATE) appears unmodified, but no ETXTBSY error is given. What you
are saying would seem to indicate that the running program *should* be
modified.

Perhaps MS_INVALIDATE doesn't bother invalidating MAP_PRIVATE mappings?
Or am I missing a trick here? :)

(this is on intel btw).

-- 
Gianni Tedesco <giannit@securewave.com>


      reply	other threads:[~2003-09-03 13:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-03  9:34 mmap(MAP_PRIVATE) question Gianni Tedesco
2003-09-03 10:28 ` Jamie Lokier
2003-09-03 13:37   ` Gianni Tedesco [this message]

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=1062596228.1356.17.camel@lemsip \
    --to=giannit@securewave.com \
    --cc=jamie@shareable.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.