diff for duplicates of <1502470781.6577.49.camel@redhat.com> diff --git a/a/1.txt b/N1/1.txt index 580c356..6b0cc95 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -10,10 +10,10 @@ On Fri, 2017-08-11 at 09:36 -0700, Mike Kravetz wrote: > > > > @@ -659,6 +659,13 @@ static __latent_entropy int > > > > dup_mmap(struct > > > > mm_struct *mm, -> > > > A tmp->vm_flags &= ~(VM_LOCKED | +> > > > tmp->vm_flags &= ~(VM_LOCKED | > > > > VM_LOCKONFAULT); -> > > > A tmp->vm_next = tmp->vm_prev = NULL; -> > > > A file = tmp->vm_file; +> > > > tmp->vm_next = tmp->vm_prev = NULL; +> > > > file = tmp->vm_file; > > > > + > > > > + /* With VM_WIPEONFORK, the child gets an empty > > > > VMA. */ @@ -29,13 +29,13 @@ On Fri, 2017-08-11 at 09:36 -0700, Mike Kravetz wrote: > > > miss > > > where those flags are cleared? > > -> > Huh, good spotting.A A That makes me wonder why the test case that +> > Huh, good spotting. That makes me wonder why the test case that > > Mike and I ran worked just fine on a MAP_SHARED|MAP_ANONYMOUS VMA, > > and returned zero-filled memory when read by the child process. > > Well, I think I still got a BUG with a MAP_SHARED|MAP_ANONYMOUS vma > on -> your v2 patch.A A Did not really want to start a discussion on the +> your v2 patch. Did not really want to start a discussion on the > implementation until the issue of exactly what VM_WIPEONFORK was > supposed > to do was settled. @@ -53,14 +53,8 @@ It worked here, but now I don't understand why :) > > Seems reasonable. > -> You should also add VM_HUGETLB to those returning -EINVAL.A A IIRC, a +> You should also add VM_HUGETLB to those returning -EINVAL. IIRC, a > VM_HUGETLB vma even without VM_SHARED expects vm_file != NULL. In other words (flags & MAP_SHARED || vma->vm_file) would catch hugetlbfs, too? - --- -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/ . -Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> diff --git a/a/content_digest b/N1/content_digest index 21ca391..468607f 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -33,10 +33,10 @@ "> > > > @@ -659,6 +659,13 @@ static __latent_entropy int\n" "> > > > dup_mmap(struct\n" "> > > > mm_struct *mm,\n" - "> > > > A \t\ttmp->vm_flags &= ~(VM_LOCKED |\n" + "> > > > \302\240\t\ttmp->vm_flags &= ~(VM_LOCKED |\n" "> > > > VM_LOCKONFAULT);\n" - "> > > > A \t\ttmp->vm_next = tmp->vm_prev = NULL;\n" - "> > > > A \t\tfile = tmp->vm_file;\n" + "> > > > \302\240\t\ttmp->vm_next = tmp->vm_prev = NULL;\n" + "> > > > \302\240\t\tfile = tmp->vm_file;\n" "> > > > +\n" "> > > > +\t\t/* With VM_WIPEONFORK, the child gets an empty\n" "> > > > VMA. */\n" @@ -52,13 +52,13 @@ "> > > miss\n" "> > > where those flags are cleared?\n" "> > \n" - "> > Huh, good spotting.A A That makes me wonder why the test case that\n" + "> > Huh, good spotting.\302\240\302\240That makes me wonder why the test case that\n" "> > Mike and I ran worked just fine on a MAP_SHARED|MAP_ANONYMOUS VMA,\n" "> > and returned zero-filled memory when read by the child process.\n" "> \n" "> Well, I think I still got a BUG with a MAP_SHARED|MAP_ANONYMOUS vma\n" "> on\n" - "> your v2 patch.A A Did not really want to start a discussion on the\n" + "> your v2 patch.\302\240\302\240Did not really want to start a discussion on the\n" "> implementation until the issue of exactly what VM_WIPEONFORK was\n" "> supposed\n" "> to do was settled.\n" @@ -76,16 +76,10 @@ "> \n" "> Seems reasonable.\n" "> \n" - "> You should also add VM_HUGETLB to those returning -EINVAL.A A IIRC, a\n" + "> You should also add VM_HUGETLB to those returning -EINVAL.\302\240\302\240IIRC, a\n" "> VM_HUGETLB vma even without VM_SHARED expects vm_file != NULL.\n" "\n" "In other words (flags & MAP_SHARED || vma->vm_file) would catch\n" - "hugetlbfs, too?\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" - "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" + hugetlbfs, too? -48395ae1970ea6e84dc7520efa52e8d59fdbb2f54ef2ea15a39dda7e2aa8cc2b +41a81b4163881ade785adc78bb7d7b5afb16767adf67a6fa750cc9e073bef0d4
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.