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