Re: [RFC] invalidate_mmap_range() misses remap_file_pages()-affected targets

[William Lee Irwin III <wli@holomorphy.com>]

On Sun, 12 Oct 2003, William Lee Irwin III wrote:
>> invalidate_mmap_range(), and hence vmtruncate(), can miss its targets
>> due to remap_file_pages()

On Sun, Oct 12, 2003 at 04:28:09PM -0400, Rik van Riel wrote:
> Please don't.   Remap_file_pages() not 100% working the way
> a normal mmap() works should be a case of "doctor, it hurts".
> Making the VM more complex just to support the (allegedly
> low overhead) hack of remap_file_pages() doesn't seem like
> a worthwhile tradeoff to me.
> In fact, I wouldn't mind if remap_file_pages() was simplified ;)

I'm far less concerned about userspace shooting itself in the foot
than I am the kernel.

At some point a decision was made to at least try to prevent orphaned
pages arising from vmtruncate() vs. ->nopage(), with some userspace
semantic motive I'm not concerned about, and to mitigate or possibly
eliminate the need to handle the orphaned pages in-kernel, which is my
concern. This tries to finish getting rid of Morton pages.

The only complexity to be concerned about here is algorithmic; a hotly
contended lock is taken in the VM_NONLINEAR setting, and the pagetable
scan to find pages at vm_pgoff-unaligned ptes is an exhaustive search.
The algorithm itself is a trivial derivative of zap_page_range() that
just checks page->index before unmapping pages and is no cause for
concern with respect to complexity of implementation.

I appreciate the desire for simplicity in general, but walking
pagetables when needed isn't complex, especially with such a large
cut and paste component. The proper interpretation of this is as an
attempt to complete the simplification of eliminating Morton pages.


-- wli

(Prior to the attempt that was merged, there was a tradeoff between
best effort search for the ptes and just deliberately letting Morton
pages happen. Since it was merged, it's become a core kernel semantic
question: i.e. is the vmtruncate() atomicity solely for the benefit of
"naive userspace", or is it a new kernel invariant? I tend to favor
consistency, but it's ultimately arbitrary, hence [RFC].)