diff for duplicates of <20111104205440.GP18879@redhat.com> diff --git a/a/1.txt b/N1/1.txt index ab4b9d8..37b1113 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -3,17 +3,17 @@ On Fri, Nov 04, 2011 at 12:16:03PM -0700, Hugh Dickins wrote: > > On Fri, Nov 4, 2011 at 3:31 PM, Hugh Dickins <hughd@google.com> wrote: > > > On Mon, 31 Oct 2011, Andrea Arcangeli wrote: > > >> @@ -2339,7 +2339,15 @@ struct vm_area_struct *copy_vma(struct vm_area_struct **vmap, -> > >> */ -> > >> if (vma_start >= new_vma->vm_start && -> > >> vma_start < new_vma->vm_end) -> > >> + /* -> > >> + * No need to call anon_vma_order_tail() in -> > >> + * this case because the same PT lock will -> > >> + * serialize the rmap_walk against both src -> > >> + * and dst vmas. -> > >> + */ +> > >> */ +> > >> if (vma_start >= new_vma->vm_start && +> > >> vma_start < new_vma->vm_end) +> > >> + /* +> > >> + * No need to call anon_vma_order_tail() in +> > >> + * this case because the same PT lock will +> > >> + * serialize the rmap_walk against both src +> > >> + * and dst vmas. +> > >> + */ > > > -> > > Really? Please convince me: I just do not see what ensures that +> > > Really? Please convince me: I just do not see what ensures that > > > the same pt lock covers both src and dst areas in this case. > > > > At the first glance that rmap_walk does travel this merged VMA @@ -71,3 +71,10 @@ the pte from vma2 to vma1, and then rmap_walk checks vma2. But again vma_merge won't be allowed to complete in the middle of rmap_walk, and so it cannot trigger and we can safely drop the patch. It wasn't immediate to think at the locks taken within vma_adjust sorry. + +-- +To unsubscribe, send a message with 'unsubscribe linux-mm' in +the body to majordomo@kvack.org. For more info on Linux MM, +see: http://www.linux-mm.org/ . +Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ +Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> diff --git a/a/content_digest b/N1/content_digest index c22120c..67e6f32 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -22,17 +22,17 @@ "> > On Fri, Nov 4, 2011 at 3:31 PM, Hugh Dickins <hughd@google.com> wrote:\n" "> > > On Mon, 31 Oct 2011, Andrea Arcangeli wrote:\n" "> > >> @@ -2339,7 +2339,15 @@ struct vm_area_struct *copy_vma(struct vm_area_struct **vmap,\n" - "> > >> \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240*/\n" - "> > >> \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 if (vma_start >= new_vma->vm_start &&\n" - "> > >> \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 vma_start < new_vma->vm_end)\n" - "> > >> + \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 /*\n" - "> > >> + \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240* No need to call anon_vma_order_tail() in\n" - "> > >> + \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240* this case because the same PT lock will\n" - "> > >> + \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240* serialize the rmap_walk against both src\n" - "> > >> + \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240* and dst vmas.\n" - "> > >> + \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240*/\n" + "> > >> */\n" + "> > >> if (vma_start >= new_vma->vm_start &&\n" + "> > >> vma_start < new_vma->vm_end)\n" + "> > >> + /*\n" + "> > >> + * No need to call anon_vma_order_tail() in\n" + "> > >> + * this case because the same PT lock will\n" + "> > >> + * serialize the rmap_walk against both src\n" + "> > >> + * and dst vmas.\n" + "> > >> + */\n" "> > >\n" - "> > > Really? \302\240Please convince me: I just do not see what ensures that\n" + "> > > Really? Please convince me: I just do not see what ensures that\n" "> > > the same pt lock covers both src and dst areas in this case.\n" "> > \n" "> > At the first glance that rmap_walk does travel this merged VMA\n" @@ -89,6 +89,13 @@ "the pte from vma2 to vma1, and then rmap_walk checks vma2. But again\n" "vma_merge won't be allowed to complete in the middle of rmap_walk, and\n" "so it cannot trigger and we can safely drop the patch. It wasn't\n" - immediate to think at the locks taken within vma_adjust sorry. + "immediate to think at the locks taken within vma_adjust sorry.\n" + "\n" + "--\n" + "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" + "the body to majordomo@kvack.org. For more info on Linux MM,\n" + "see: http://www.linux-mm.org/ .\n" + "Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/\n" + "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -21e5e610104b7b44fa6c8210f897889a99522eea4a8eef623f364b33be7f6ec2 +b7820067fc5cdc51da654c93cd8fb971eb3d7b72ac68bd29bef3bc648d5991c3
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.