Subject: Re: [PATCH] fix remap of shared read only mappings
From: James Bottomley <James.Bottomley@steeleye.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: Linus Torvalds <torvalds@osdl.org>,
       Linux Kernel <linux-kernel@vger.kernel.org>
In-Reply-To: <20030904214810.GG31590@mail.jlokier.co.uk>
References: <1062686960.1829.11.camel@mulgrave> 
	<20030904214810.GG31590@mail.jlokier.co.uk>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 04 Sep 2003 18:33:48 -0400
Message-Id: <1062714829.2161.384.camel@mulgrave>
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1209
Lines: 32

On Thu, 2003-09-04 at 17:48, Jamie Lokier wrote:
> One last thought: this is what PROT_SEM is for.  Linux doesn't use
> this in any useful way.  But, technically, mmap with MAP_SHARED ad
> PROT_SEM should enable cache coherence, and that might include
> aligning the address.  Without PROT_SEM an application should not rely
> on cache coherence.

I'm not familiar with the PROT_SEM flag.  I don't believe it to be
defined in POSIX.

However, POSIX does imply levels of cache coherence for both MAP_SHARED
and MAP_PRIVATE:

With MAP_SHARED, any change to the underlying object after the mapping
must become visible to the mapper (although the change may be delayed by
local caching of the changer's implementation until it is explicitly
flushed).

With MAP_PRIVATE it is undefined what happens if the underlying object
is changed after mapping.

So regardless of PROT_SEM we have no choice but to worry about cache
coherence issues on MAP_SHARED mappings.

James


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/