* [RFC] vmtruncate releases pages of MAP_PRIVATE vma
@ 2003-01-21 19:26 Alex Tomas
2003-01-21 19:51 ` Andrew Morton
0 siblings, 1 reply; 3+ messages in thread
From: Alex Tomas @ 2003-01-21 19:26 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC] vmtruncate releases pages of MAP_PRIVATE vma
2003-01-21 19:26 [RFC] vmtruncate releases pages of MAP_PRIVATE vma Alex Tomas
@ 2003-01-21 19:51 ` Andrew Morton
2003-01-22 7:32 ` Oleg Drokin
0 siblings, 1 reply; 3+ messages in thread
From: Andrew Morton @ 2003-01-21 19:51 UTC (permalink / raw)
To: Alex Tomas; +Cc: linux-kernel
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..
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [RFC] vmtruncate releases pages of MAP_PRIVATE vma
2003-01-21 19:51 ` Andrew Morton
@ 2003-01-22 7:32 ` Oleg Drokin
0 siblings, 0 replies; 3+ messages in thread
From: Oleg Drokin @ 2003-01-22 7:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: Alex Tomas, linux-kernel
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-01-22 7:23 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-01-21 19:26 [RFC] vmtruncate releases pages of MAP_PRIVATE vma Alex Tomas
2003-01-21 19:51 ` Andrew Morton
2003-01-22 7:32 ` Oleg Drokin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox