Messages in this thread | | | Date | Fri, 4 Apr 2003 15:34:48 +0100 (BST) | From | Hugh Dickins <> | Subject | objrmap and vmtruncate |
| |
I see you're going for locking the page around page_convert_anon, to guard page->mapping against truncation. Nice thought, but the words "tip" and "iceberg" spring to mind.
Truncating a sys_remap_file_pages file? You're the first to begin to consider such an absurd possibility: vmtruncate_list still believes vm_pgoff tells it what needs to be done.
I propose that we don't change vmtruncate_list, zap_page_range, ... at all for this: let it unmap inappropriate pages, even from a VM_LOCKED vma, that's just a price userspace pays for the privilege of truncating a sys_remap_file_pages file.
But truncate_inode_pages should check page_mapped, and if so try_to_unmap with a force flag to attack even VM_LOCKED vmas. Sadly, if page_table_lock is held, it won't be able to unmap: leave those for shrink_list? But that won't find them once page->mapping gone: page_convert_anon from here too? What about invalidate_inode_pages2?
This will also cover some of the racy pages, which another cpu found in the cache before vmtruncate started, but inserted into page table after vmtruncate_list passed that way; but it won't cover those racy pages which were found before, but are not yet put into the page table (e.g. those where your page_convert_anon bailed because page->mapping is now NULL). Worth adding checks for? but I don't think we have absolute locking against this.
Various places in rmap.c where !page->mapping is considered a BUG(), but you've now drawn attention to the fact it may get vmtruncated at any moment. Easy to remove those BUG()s.
Consider page_add_rmap of page with NULL (or swapper_space) mapping as Anon? In which case move all the SetPageAnon stuff inside rmap.c, and do ClearPageAnon inside there too?
Or, stop resetting page->mapping to NULL when we remove from page cache? So objrmap can still find the pages even though find_get_page etc. cannot.
Sorry, off to replace my "?" key, it's worn out.
Hugh
- 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/
| |