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 <dhillf@xxxxxxxxx> > --- > > --- 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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>