On Wed, 24 May 2006, Hugh Dickins wrote:
> Such an orphan may be left behind if an earlier migration raced with fork:
> copy_one_pte can duplicate a migration entry from parent to child, after
> remove_anon_migration_ptes has checked the child vma, but before it has
> removed it from the parent vma. (If the process were later to fault on
> this orphaned entry, it would hit the same BUG from migration_entry_wait.)
Right the pte lock does not help us there. sigh.
> This could be fixed by locking anon_vma in copy_one_pte, but we'd rather
> not. There's no such problem with file pages, because vma_prio_tree_add
> adds child vma after parent vma, and the page table locking at each end
> is enough to serialize. Follow that example with anon_vma: add new vmas
> to the tail instead of the head.
Thats is very subtle. I hope there are no other areas where the child vma
has to be processed before the parent vma? An alternativbe would be to
make remove_anon_migration_ptes walk the list in reverse and add a big
comment.
Thank you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
