public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* mmap(MAP_PRIVATE) question
@ 2003-09-03  9:34 Gianni Tedesco
  2003-09-03 10:28 ` Jamie Lokier
  0 siblings, 1 reply; 3+ messages in thread
From: Gianni Tedesco @ 2003-09-03  9:34 UTC (permalink / raw)
  To: linux-kernel

Hi all,

>From the mmap(2) manpage it says:

MAP_PRIVATE
Create a private copy-on-write mapping.  Stores to the region do not
affect the  original  file.   It  is  unspecified whether changes made
to the file after the mmap call are visible in the mapped region.

What is linux behaivour in this area? I am guessing if the page is
modified between the call to mmap() and fault-in then the modified copy
is seen by the application? But what about modifications after the page
is already in page-cache?

Thanks.

-- 
Gianni Tedesco <giannit@securewave.com>


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: mmap(MAP_PRIVATE) question
  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
  0 siblings, 1 reply; 3+ messages in thread
From: Jamie Lokier @ 2003-09-03 10:28 UTC (permalink / raw)
  To: Gianni Tedesco; +Cc: linux-kernel

Gianni Tedesco wrote:
> Hi all,
> 
> >From the mmap(2) manpage it says:
> 
> MAP_PRIVATE
> Create a private copy-on-write mapping.  Stores to the region do not
> affect the  original  file.   It  is  unspecified whether changes made
> to the file after the mmap call are visible in the mapped region.
> 
> What is linux behaivour in this area? I am guessing if the page is
> modified between the call to mmap() and fault-in then the modified copy
> is seen by the application? But what about modifications after the page
> is already in page-cache?

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.

This means that if you write() to the page prior to the copy-on-write
fault, you may see the changes in application memory straight away.
If some other process writes to the page through a writable mapping,
you may see the changes.

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.

-- Jamie

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: mmap(MAP_PRIVATE) question
  2003-09-03 10:28 ` Jamie Lokier
@ 2003-09-03 13:37   ` Gianni Tedesco
  0 siblings, 0 replies; 3+ messages in thread
From: Gianni Tedesco @ 2003-09-03 13:37 UTC (permalink / raw)
  To: Jamie Lokier; +Cc: linux-kernel

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>


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2003-09-03 13:40 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox