>
> Christoph Rohland wrote:
> > > I think in both cases, for MAP_SHARED, it should show a shmfs file
> > > name if possible (i.e. if it's mounted).
> >
> > That's probably true.
> >
> > > From /proc/pid/maps, it's possible to open the shared mapped file whose
> > > name is listed and see what the process sees. But that breaks for
> > > /dev/zero as a very special case. Using the shmfs name would remove
> > > that special case.
> >
> > Since they always show up as deleted the current solution is still
> > correct in your scenario.
>
> By current solution, you mean the one which shows /dev/zero in
> /proc/pid/maps?
>
> 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?
>
> > 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.
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