Re: writepage return value check in vmscan.c

[Andrew Morton <akpm@digeo.com>]

chrisl@vmware.com wrote:
> 
> Hi Andrew,
> 
> It might be a silly question.

It's an excellent question.

> ...
> I try to find out what happen if user memory map a sparse file then
> kernel try to write it back to disk and hit a no disk space error.
> To my surprise, it seems to me that both 2.4 and 2.5 kernel do not
> check the return value of "writepage". If there is an error like ENOSPC
> it will just drop it on the ground? Do I miss something obvious?

Yup.  If the kernel cannot write back your MAP_SHARED page due to
ENOSPC it throws your data away.

The alternative would be to allow you to pin an arbitrary amount of
unpageable memory.

A few fixes have been discussed.  One way would be to allocate
the space for the page when it is first faulted into reality and
deliver SIGBUS if backing store for it could not be allocated.
 
> BTW, I am amazed that there is so many way user can abuse the mmap system
> call. e.g. open a file, ftruncate to a bigger size, unlink that file while
> keep the file descriptor, mmap to some memory using that descriptor,
> close that descriptor, you can still use that mmaped memory.

Ayup.  MAP_SHARED is a crock.  If you want to write to a file, use write().

View MAP_SHARED as a tool by which separate processes can attach
to some shared memory which is identified by the filesystem namespace.
It's not a very good way of performing I/O.

That's not to say that you deserve to have the kernel silently throw
your data away as punishment for having used it though.  Thanks for the
prod.  We should do something about that.