vmtruncate releases pages of MAP_PRIVATE vma
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
Quoted 6 lines · Alex Tomas
Good day!
I've just encountered that
vmtruncate()releases all pages of selected VMA. It does even if VMA isMAP_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.
Quoted 1 line
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..
Hello!
Quoted 5 lines · Andrew Morton
Quoted 1 line
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