[RFC] vmtruncate releases pages of MAP_PRIVATE vma

[RFC] vmtruncate releases pages of MAP_PRIVATE vma

[Alex Tomas]

Good day!

I've just encountered that vmtruncate() releases all pages of
selected VMA. It does even if VMA is MAP_PRIVATE. Is this right
behaviour?

I think vmtruncate() should preserve that pages. 

with best regards, Alex

Re: [RFC] vmtruncate releases pages of MAP_PRIVATE vma

[Andrew Morton]

Alex Tomas wrote:
> 
> Good day!
> 
> I've just encountered that vmtruncate() releases all pages of
> selected VMA. It does even if VMA is MAP_PRIVATE. Is this right
> behaviour?

     If the size of the mapped file changes after the call to mmap()
     as a result of some other operation on the mapped file, the
     effect of references to portions of the mapped region that
     correspond to added or removed portions of the file is
     unspecified.

> I think vmtruncate() should preserve that pages.

That would make sense.  But we'd have to go and create zillions
of copies of pages inside truncate, and given that the behaviour
is unspecified, it is questionable whether anyone should be
relying on the behaviour anyway..

Re: [RFC] vmtruncate releases pages of MAP_PRIVATE vma

[Oleg Drokin]

Hello!

On Tue, Jan 21, 2003 at 11:51:01AM -0800, Andrew Morton wrote:

> > I think vmtruncate() should preserve that pages.
> That would make sense.  But we'd have to go and create zillions
> of copies of pages inside truncate, and given that the behaviour
> is unspecified, it is questionable whether anyone should be
> relying on the behaviour anyway..

It is way too easy to truncate some library and all executables (that are loaded
right now) will go nuts (Just did echo >/lib/libncurses.so.5.2 and expected
everything will get SIGBUS, but all the bashes and mutt went crazy consuming
memory until oom-killer killed them. Kind of surprising behaviour, I'd say.
Test was done on 2.4.19).
Also *BSD systems seems to return -ETXTBSY not only when you try to write-open 
running executables, but also all of shared libs used (and this is probably
even more logical ).

Bye,
    Oleg