Re: [RFC] invalidate_mmap_range() misses remap_file_pages()-affected targets
From: William Lee Irwin III
Date: Sun Oct 12 2003 - 16:21:22 EST
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.
(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].)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/