ebiederm@xmission.com (Eric W. Biederman) wrote:

quoted

Expanding ftruncate would be nice, but the current way of performing
the page instantiation at mmap() time seems sufficient.

Having an expanding/shrinking ftruncate will trivially allow posix shared
memory semantics.   

I am trying to digest the idea of a mmap that grows a file.  There isn't
anything else that works that way is there?

Not that I can think of.

It looks like you are removing the limit checking from hugetlbfs, by
removing the expansion code from ftruncate.

There was no expansion code.

The code I took out was vestigial.  We can put it all back if we decide to
add a new expand-with-ftruncate feature to hugetlbfs.

 And given the fact that
nothing else grows in mmap, I suspect the code will be much easier to
write and maintain if the growth is constrained to happen in ftruncate.

That would require a fault handler.  We don't have one of those for hugetlbs.
 Probably not hard to add one though.

I may be missing something but it looks like there is not code present
to prevent multiple page allocations at the same time conflicting
when i_size is grown. 

All the mmap code runs under down_write(current->mm->mmap_sem);
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/