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

[Stas Sergeev <stsp@aknet.ru>]

Hi.

Hugh Dickins wrote:
>> It is full of surprises, it will map a zero-page to you,
>> it will give you a SIGBUS, it will do everything
> 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.
OK, the last time I was messing around the
mremap, it was mapping the anonymous pages
to me when I was trying to expand the /dev/mem
mapping (missing nopage handler apparently,
having the failure could be much better in that
case I think).

> 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.
Yes, as for SIGBUS - now I see why it works that
way (not necessary accept its correctness, but
what you said, sounds perfectly valid to me, so
the complete retirement on my side:)

> 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.
... and/or expand the anonymous private mapping without
the truncation (nothing to truncate). So yes, after all,
it was specific to the anon-shm, which is a special case.
And introducing the per-vma mremap handlers to fix only
this special case (by doing the truncation immediately)
is an overkill and is not required by anyone except myself.
And this:
---
In most 
cases (at least for the malloc case) this will be a anonymous mapping, 
but it's by no means an error to extend any mapping you have created.
---
may just mean that it is never an error, but you have
to deal with the consequences yourself if you expanded
only the mapping and not the object (except for the
case of anon-shm, where you can't deal with the
consequences anyhow since you can't expand the object).
Have I got everything properly this time, or failed the
homework agan? :)