Re: writepage return value check in vmscan.c

[chrisl@vmware.com]

On Thu, Oct 24, 2002 at 01:31:06PM +0200, Andrea Arcangeli wrote:
> On Thu, Oct 24, 2002 at 01:36:43AM -0700, Andrew Morton wrote:
> 
> you need to preallocate the file, then to mmap it. If you do, the kernel
> won't throw the data away. So the fix for vmware is to preallocate the
> file and later to mmap it. This way you will be notified by -ENOSPC if
> you run out of disk/shmfs space.  Other than this I'm not so against the
> MAP_SHARED like Andrew, the reason the API is not so clean is that we
> cannot have an API at all inside a page fault to notify userspace that
> the ram modifications cannot be written to disk. the page fault must be
> transparent, there's no retvalue, so if you run out of disk space during
> the page fault, the page fault cannot easily tell userspace. As said the
> fix is very easy and consists in preallocating the space on disk (I
> understand that on shmfs it may not be extremely desiderable since you
> may prefer to defer allocation lazily to when you will need the memory
> but assuming your allocations are worthwhile it won't make difference
> after a few minutes/hours of usage and this way you will trap the -ENOSPC).

But preallocate the vmware ram file on disk is too expensive. It will slow
down the guest OS boot up a lot. Many user measure how fast vmware is by
counting how many seconds it takes to boot a windows guest for example.
For those virtual machine which have 2G or ram, how long does it take
to write a file with 2G of data?

> 
> As for the task being able to reference a deleted file in memory, that's
> true for many other scenarios (the user could leak space by keeping the
> fd open and unlinking the file and at the same time to alloc lots of ram
> with malloc, the result would be similar), and that's why root will have
> to kill these malicious tasks in order to reclaim ram and disk space.

vmware is definitely one of those malicious task ;-)

Chris