Re: [patch][rfc] expandable anonymous shared mappings

[Hugh Dickins]

On Tue, 29 Jun 2004, Stas Sergeev wrote:
> Now I understand, however, the problems I had with
> mremap(), have nothing special to do with the anon-shm,
> it just seems to be the usual thing with that syscall.
> It is full of surprises, it will map a zero-page to you,
> it will give you a SIGBUS, it will do everything
> but not what you really want from it:) I always
> wanted to have the more reliable mremap(). Not the
> one that can expand everything in the world, but
> the one that returns the value you can rely upon,
> as all the other syscalls do.

>From this attack on poor little mremap(), I think perhaps there's
something else you didn't realize, that I'd assumed you did realize.

If you have a file of size, say, 2 pages; and you mmap 3 pages of
it (from offset 0 for simplicity); then you try to access the third
page of your mapping... you get SIGBUS.  That's so whether it's a
shared or a private mapping.  It's even so if it's a private mapping,
you write your own data into the second page, you truncate the file
to 1 page, you try to access your own data in the second page again.
That's how mmap is specified to behave, not just on Linux.

So mremap() is entirely consistent to allow you to extend a mapping
beyond the end of the object, such that you'll get SIGBUS if you
try to access the end of your mapping.

The deficiency with shared anonymous is that there's no way to expand
or shrink the underlying object to match the mapping, whereas you can
ftruncate a real file.

Hugh

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