Shared mapping

Pranay Srivastava pranjas at
Tue Jan 13 02:37:55 EST 2015

Hi Riya,

On Mon, Jan 12, 2015 at 10:01 AM, riya khanna <riyakhanna1983 at> wrote:
> With shared memory mappings, once A and B both map the same memory
> address/file they see the same contents
> A [0xaaaaaaaa] - maps - to -> [0xAAAAAAAA]
> B [0xbbbbbbbb] - maps - to -> [0xAAAAAAAA]
> However, if A changes (update) the mappings to point to a different
> memory area/file offset, B sees different contents
> A [0xaaaaaaaa] - maps - to -> [0xBBBBBBBB]
> Is there a way to force update the mappings of B, so that B too sees
> contents at 0xBBBBBBBB?
> Could this be done, by deleting the shmem backing and making the fault
> handler update the mappings?

No you can't do that. This is an easily solvable problem with
user-space code. What you are saying is that if the page is dirty for
process A you want process B to automatically update it's copy. This
just won't happen and certainly not the way you want it to happen.

You need to design this properly. Better yet take some transaction id
over the device which_device_should_tell you either by doing some
ioctl or other way. Have some wrappers like
sync_mapped_memory(device_fd) etc that will first sync the process's
copy before doing anything.

What you are saying of happening automatically would mean that a write
at one place would trigger a fault in another process's address space
but that's not how it would work and it's not good design. care to
tell more about the problem? maybe I can help

> On Mon, Jan 12, 2015 at 10:50 AM,  <Valdis.Kletnieks at> wrote:
>> On Mon, 12 Jan 2015 07:34:41 -0600, riya khanna said:
>>> Suppose A and B have mapped the same physical memory or shmem file. I want
>>> a way to make process A forcefuly revoke/remap the existing shared memory
>>> mappings in process B, so that B sees whatever A does.
>> Umm..B should be seeing what A does *already*.  That's the whole *point* of
>> shared mmap spaces.
>> And what problem are you trying to solve by doing this, anyhow?  There's
>> probably a better approach (for starters, have A set up the mappings, then
>> fork B which gets the mappings all set up from the start).


More information about the Kernelnewbies mailing list