Messages in this thread Patch in this message |  | | Date | Thu, 15 May 2003 01:32:45 -0700 | From | Andrew Morton <> | Subject | Re: Race between vmtruncate and mapped areas? |
| |
Andrea Arcangeli <andrea@suse.de> wrote: > > what do you think of this untested fix? > > I wonder if vm_file is valid for all nopage operations, I think it > should, and the i_mapping as well should always exist, but in the worst > case it shouldn't be too difficult to take care of special cases > (just checking if the new_page is reserved and if the vma is VM_SPECIAL) > would eliminate most issues, shall there be any.
yes, I think this is a good solution.
In 2.5 (at least) we can push all the sequence number work into filemap_nopage(), and add a new vm_ops->revalidate() thing, so do_no_page() doesn't need to know about inodes and such.
So the mm/memory.c part would look something like:
diff -puN mm/memory.c~a mm/memory.c --- 25/mm/memory.c~a 2003-05-15 01:29:21.000000000 -0700 +++ 25-akpm/mm/memory.c 2003-05-15 01:32:02.000000000 -0700 @@ -1399,7 +1399,7 @@ do_no_page(struct mm_struct *mm, struct pmd, write_access, address); pte_unmap(page_table); spin_unlock(&mm->page_table_lock); - +retry: new_page = vma->vm_ops->nopage(vma, address & PAGE_MASK, 0); /* no page was available -- either SIGBUS or OOM */ @@ -1408,9 +1408,11 @@ do_no_page(struct mm_struct *mm, struct if (new_page == NOPAGE_OOM) return VM_FAULT_OOM; - pte_chain = pte_chain_alloc(GFP_KERNEL); - if (!pte_chain) - goto oom; + if (!pte_chain) { + pte_chain = pte_chain_alloc(GFP_KERNEL); + if (!pte_chain) + goto oom; + } /* * Should we do an early C-O-W break? @@ -1428,6 +1430,17 @@ do_no_page(struct mm_struct *mm, struct } spin_lock(&mm->page_table_lock); + + /* + * comment goes here + */ + if (vma->vm_ops && vma->vm_ops->revalidate && + vma->vm_ops->revalidate(vma, address) { + spin_unlock(&mm->page_table_lock); + put_page(new_page); + goto retry; + } + page_table = pte_offset_map(pmd, address); /* _
- 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/
|  |