Messages in this thread | | | Date | Sat, 13 Mar 2004 18:27:42 -0800 | From | William Lee Irwin III <> | Subject | Re: anon_vma RFC2 |
| |
On Sat, 13 Mar 2004, William Lee Irwin III wrote: >> [hugetlb at same address]
On Sat, Mar 13, 2004 at 08:41:42PM -0500, Rik van Riel wrote: > Well, we can find this merely by looking at the page tables > themselves, so that shouldn't be a problem.
Pagetables of a kind the core understands may not be present there. On ia32 one could in theory have a pmd_huge() check, which would in turn not suffice for ia64 and sparc64 hugetlb. These were only examples. Other unusual forms of mappings, e.g. VM_RESERVED and VM_IO, may also be bad ideas to trip over by accident.
On Sat, 13 Mar 2004, William Lee Irwin III wrote: >> Searching the COW sharing group isn't how everything works, but in those >> cases where additionally you can find mm's that don't map the page at >> that virtual address and may have different vmas cover it, this can >> arise.
On Sat, Mar 13, 2004 at 08:41:42PM -0500, Rik van Riel wrote: > This could only happen when you truncate a file that's > been mapped by various nonlinear VMAs, so truncate can't > get rid of the pages... > I suspect there are two ways to fix that: > 1) on truncate, scan ALL the ptes inside nonlinear VMAs > and remove the pages > 2) don't allow truncate on a file that's mapped with > nonlinear VMAs > Either would work.
I'm not sure how that came in. The issue I had in mind was strictly a matter of tripping over things one can't make sense of from pagetables alone in try_to_unmap().
COW-shared anonymous pages not unmappable via anonymous COW sharing groups arising from truncate() vs. remap_file_pages() interactions and failures to check for nonlinearly-mapped pages in pagetable walkers are an issue in general of course, but they just aren't this issue.
-- wli - 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/
| |