On Fri, 27 Jul 2012, Hillf Danton wrote: > > If swap entry is cleared, we can see the reason that copying pte is > interrupted. If due to page table lock held long enough, no need to > increase swap count.
I can't see a bug to be fixed here. How would it break out of the loop above without freshly setting entry (given that mmap_sem is held with down_write, so the entries cannot be munmap'ped by another thread)? How would it matter if it could (given that add_swap_count_continuation already allows for races; and if there were a problem, the call just made could be equally at fault)? Nor do I understand your description. But I can see that the lack of reinitialization of entry.val here does raise doubt and confusion. A better tidyup would be to remove the initialization of swp_entry_t entry from its onstack declaration, and do it at the again label instead. If you send a patch to do that instead, I could probably ack it - but expect I shall want to change your description. Hugh > > Signed-off-by: Hillf Danton <dhi...@gmail.com> > --- > > --- a/mm/memory.c Fri Jul 27 21:33:32 2012 > +++ b/mm/memory.c Fri Jul 27 21:35:24 2012 > @@ -971,6 +971,7 @@ again: > if (add_swap_count_continuation(entry, GFP_KERNEL) < 0) > return -ENOMEM; > progress = 0; > + entry.val = 0; > } > if (addr != end) > goto again; > -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
