>
> Kanoj Sarcar wrote:
> > > A program which opens /proc/pid/maps of some other process, and opens
> > > the shared mapped file named in there, will open /dev/zero. And that's
> > > broken: it doesn't show the correct data. For a MAP_PRIVATE mapping,
> > > you get what you expect. But for a MAP_SHARED mapping, it should work
> > > or the open should fail.
> >
> > For a MAP_PRIVATE mapping, if a process mmaps /dev/zero, changes a few
> > pages, then another process comes in and opens /dev/zero, how does this
> > second process see the changes made by the first?
>
> I'm talking about opening a MAP_SHARED mapping, not a private one.
I was responding to your comment quoted above "For a MAP_PRIVATE mapping,
you get what you expect".
>
> > > > And they have to show up as deleted since this memory object is only
> > > > accesible to the process and its relatives. FD passing et.al. do not
> > > > help for /dev/zero since mmaping the file again gives you a new
> > > > mapping.
> > >
> > > ?? I was under the impression that the whole point of MAP_SHARED on
> > > /dev/zero is that you can pass the fd around and multiple mappings
> > > return the same pages.
> >
> > Nope. The whole point is cooperative inter process sharing. Being able to
> > do what you suggest would be nice only if it is not too hard to implement.
>
> So you can only use shared /dev/zero mappings to share across fork()?
At least that was the idea when I coded; a lot of vendors do things like
/dev/zero MAP_SHARED, and MAP_ANON|MAP_SHARED on other os'es. First step: get
Linux to provide a similar feature.
>
> Darn. And I thought it was an automagic equivalent to shm_open().
>
Note, just because MAP_ANON|MAP_SHARED and /dev/zero MAP_SHARED share the
same code with shmfs (purely for convenience), does not mean they have to
look or behave the same way in all situations.
If you could describe what you were trying to achieve with your initial
suggestion, we can see if there's some way we can still do that, or if
there is an alternate way to do it. FWIW, on some os'es, there are exotic
calls that a process A can make to "attach" onto a specific address range
of process B. Of course, debuggers already do this in a somewhat slower
way.
Kanoj
> -- Jamie
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:21 EST