Shared mapping

Shared mapping

[riya khanna]

Hi,

Is there a way, w.r.t memory contents, to make a process B see what
process A sees through shared memory mappings?

Suppose Process A has mapped a device file (say F) at address
0xaaaaaaaa in its address space. Is it possible for process B to see
the same device file F contents as process A via shared memory
mappings? If mapped in process B's address space, would process B
continue to to see the old contents if process A were to map a new
device file (say N) at the same address 0xaaaaaaaa in its address
space or do they have independent mappings?

So basically I'm trying to understand if there could be virtual to
virtual mappings (e.g. process B mapping process A's memory, so that B
sees whatever A sees)?

Thanks for your help!

-Riya

Shared mapping

[Pranay Srivastava]

Hi Riya,


On Mon, Jan 12, 2015 at 2:08 AM, riya khanna <riyakhanna1983@gmail.com> wrote:
> Hi,
>
> Is there a way, w.r.t memory contents, to make a process B see what
> process A sees through shared memory mappings?
>
> Suppose Process A has mapped a device file (say F) at address
> 0xaaaaaaaa in its address space. Is it possible for process B to see
> the same device file F contents as process A via shared memory
> mappings? If mapped in process B's address space, would process B
> continue to to see the old contents if process A were to map a new
> device file (say N) at the same address 0xaaaaaaaa in its address
> space or do they have independent mappings?

It depends on the driver mapping that specific memory address. If it
so chooses that every process trying to map that address needs to have
an independent page then it'll do that. But normally if the driver
allows mmapping device then it'll be a separate copy.

>
> So basically I'm trying to understand if there could be virtual to
> virtual mappings (e.g. process B mapping process A's memory, so that B
> sees whatever A sees)?

This means you are getting two separate pages when you mmap the device?

Normally your driver won't give you same page since once a page is
mapped simple writes(like assignments etc) won't trigger any fault
which might give the driver a chance to do proper locking semantics
when both processes are writing at same time using just an assignment.

What you can do is create a shared mapping between the two processes A
and B then fill that mapping from whoever wins the race to update this
shared mapping between them. You can add some information if the
information needs to be updated again in this shared region between A
and B.

Can you tell more about your problem?
>
> Thanks for your help!
>
> -Riya
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies



-- 
        ---P.K.S

Shared mapping

[riya khanna]

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.

On Monday, January 12, 2015, Pranay Srivastava <pranjas@gmail.com> wrote:

> Hi Riya,
>
>
> On Mon, Jan 12, 2015 at 2:08 AM, riya khanna <riyakhanna1983@gmail.com
> <javascript:;>> wrote:
> > Hi,
> >
> > Is there a way, w.r.t memory contents, to make a process B see what
> > process A sees through shared memory mappings?
> >
> > Suppose Process A has mapped a device file (say F) at address
> > 0xaaaaaaaa in its address space. Is it possible for process B to see
> > the same device file F contents as process A via shared memory
> > mappings? If mapped in process B's address space, would process B
> > continue to to see the old contents if process A were to map a new
> > device file (say N) at the same address 0xaaaaaaaa in its address
> > space or do they have independent mappings?
>
> It depends on the driver mapping that specific memory address. If it
> so chooses that every process trying to map that address needs to have
> an independent page then it'll do that. But normally if the driver
> allows mmapping device then it'll be a separate copy.
>
> >
> > So basically I'm trying to understand if there could be virtual to
> > virtual mappings (e.g. process B mapping process A's memory, so that B
> > sees whatever A sees)?
>
> This means you are getting two separate pages when you mmap the device?
>
> Normally your driver won't give you same page since once a page is
> mapped simple writes(like assignments etc) won't trigger any fault
> which might give the driver a chance to do proper locking semantics
> when both processes are writing at same time using just an assignment.
>
> What you can do is create a shared mapping between the two processes A
> and B then fill that mapping from whoever wins the race to update this
> shared mapping between them. You can add some information if the
> information needs to be updated again in this shared region between A
> and B.
>
> Can you tell more about your problem?
> >
> > Thanks for your help!
> >
> > -Riya
> >
> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies at kernelnewbies.org <javascript:;>
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
>
> --
>         ---P.K.S
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150112/daf717de/attachment-0001.html 

Shared mapping

[Valdis.Kletnieks at vt.edu]

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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150112/b58ed879/attachment.bin 

Shared mapping

[riya khanna]

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?


On Mon, Jan 12, 2015 at 10:50 AM,  <Valdis.Kletnieks@vt.edu> 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).

Shared mapping

[Valdis.Kletnieks at vt.edu]

On Mon, 12 Jan 2015 11:01:06 -0600, riya khanna said:
> 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]

Well, don't do that then.  Or have A notify B via some sort of IPC
that it's done it so B can update its mappings.

I'm not seeing a need for kernel support for poorly designed userspace code.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150112/3f342c13/attachment.bin 

Shared mapping

[Pranay Srivastava]

Hi Riya,

On Mon, Jan 12, 2015 at 10:01 AM, riya khanna <riyakhanna1983@gmail.com> 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@vt.edu> 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).



-- 
        ---P.K.S