From: Hillf Danton <dhillf@gmail.com> To: Will Deacon <will.deacon@arm.com> Cc: linux-mm@kvack.org, akpm@linux-foundation.org, mhocko@suse.cz, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: hugetlb: flush dcache before returning zeroed huge page to userspace Date: Thu, 5 Jul 2012 20:37:46 +0800 [thread overview] Message-ID: <CAJd=RBAmF3dtb8wtEbS-A7BNT=RLsb5emQQWVU8ioeQOO8D7NA@mail.gmail.com> (raw) In-Reply-To: <1341412376-6272-1-git-send-email-will.deacon@arm.com> On Wed, Jul 4, 2012 at 10:32 PM, Will Deacon <will.deacon@arm.com> wrote: > When allocating and returning clear huge pages to userspace as a > response to a fault, we may zero and return a mapping to a previously > dirtied physical region (for example, it may have been written by > a private mapping which was freed as a result of an ftruncate on the > backing file). On architectures with Harvard caches, this can lead to > I/D inconsistency since the zeroed view may not be visible to the > instruction stream. > > This patch solves the problem by flushing the region after allocating > and clearing a new huge page. Note that PowerPC avoids this issue by > performing the flushing in their clear_user_page implementation to keep > the loader happy, however this is closely tied to the semantics of the > PG_arch_1 page flag which is architecture-specific. > > Acked-by: Catalin Marinas <catalin.marinas@arm.com> > Signed-off-by: Will Deacon <will.deacon@arm.com> > --- Thanks:) Acked-by: Hillf Danton <dhillf@gmail.com> > mm/hugetlb.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index e198831..b83d026 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -2646,6 +2646,7 @@ retry: > goto out; > } > clear_huge_page(page, address, pages_per_huge_page(h)); > + flush_dcache_page(page); > __SetPageUptodate(page); > > if (vma->vm_flags & VM_MAYSHARE) { > -- > 1.7.4.1 >
WARNING: multiple messages have this Message-ID (diff)
From: Hillf Danton <dhillf@gmail.com> To: Will Deacon <will.deacon@arm.com> Cc: linux-mm@kvack.org, akpm@linux-foundation.org, mhocko@suse.cz, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: hugetlb: flush dcache before returning zeroed huge page to userspace Date: Thu, 5 Jul 2012 20:37:46 +0800 [thread overview] Message-ID: <CAJd=RBAmF3dtb8wtEbS-A7BNT=RLsb5emQQWVU8ioeQOO8D7NA@mail.gmail.com> (raw) In-Reply-To: <1341412376-6272-1-git-send-email-will.deacon@arm.com> On Wed, Jul 4, 2012 at 10:32 PM, Will Deacon <will.deacon@arm.com> wrote: > When allocating and returning clear huge pages to userspace as a > response to a fault, we may zero and return a mapping to a previously > dirtied physical region (for example, it may have been written by > a private mapping which was freed as a result of an ftruncate on the > backing file). On architectures with Harvard caches, this can lead to > I/D inconsistency since the zeroed view may not be visible to the > instruction stream. > > This patch solves the problem by flushing the region after allocating > and clearing a new huge page. Note that PowerPC avoids this issue by > performing the flushing in their clear_user_page implementation to keep > the loader happy, however this is closely tied to the semantics of the > PG_arch_1 page flag which is architecture-specific. > > Acked-by: Catalin Marinas <catalin.marinas@arm.com> > Signed-off-by: Will Deacon <will.deacon@arm.com> > --- Thanks:) Acked-by: Hillf Danton <dhillf@gmail.com> > mm/hugetlb.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index e198831..b83d026 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -2646,6 +2646,7 @@ retry: > goto out; > } > clear_huge_page(page, address, pages_per_huge_page(h)); > + flush_dcache_page(page); > __SetPageUptodate(page); > > if (vma->vm_flags & VM_MAYSHARE) { > -- > 1.7.4.1 > -- 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>
next prev parent reply other threads:[~2012-07-05 12:37 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-07-04 14:32 [PATCH] mm: hugetlb: flush dcache before returning zeroed huge page to userspace Will Deacon 2012-07-04 14:32 ` Will Deacon 2012-07-05 12:37 ` Hillf Danton [this message] 2012-07-05 12:37 ` Hillf Danton 2012-07-05 14:17 ` Will Deacon 2012-07-05 14:17 ` Will Deacon 2012-07-06 13:15 ` Hillf Danton 2012-07-06 13:15 ` Hillf Danton 2012-07-09 12:25 ` Michal Hocko 2012-07-09 12:25 ` Michal Hocko 2012-07-09 14:13 ` Will Deacon 2012-07-09 14:13 ` Will Deacon 2012-07-09 23:57 ` Hugh Dickins 2012-07-09 23:57 ` Hugh Dickins 2012-07-10 9:45 ` Will Deacon 2012-07-10 9:45 ` Will Deacon 2012-07-10 10:42 ` Will Deacon 2012-07-10 10:42 ` Will Deacon 2012-07-11 17:48 ` Will Deacon 2012-07-11 17:48 ` Will Deacon 2012-07-12 11:16 ` Michal Hocko 2012-07-12 11:16 ` Michal Hocko 2012-07-12 11:26 ` James Bottomley 2012-07-12 11:26 ` James Bottomley 2012-07-12 11:26 ` Will Deacon 2012-07-12 11:26 ` Will Deacon 2012-07-12 11:57 ` Michal Hocko 2012-07-12 11:57 ` Michal Hocko 2012-08-07 16:03 ` Will Deacon 2012-08-07 16:03 ` Will Deacon 2012-08-08 16:26 ` Michal Hocko 2012-08-08 16:26 ` Michal Hocko 2012-08-16 16:09 ` Will Deacon 2012-08-16 16:09 ` Will Deacon 2012-08-16 16:09 ` Will Deacon 2012-08-16 16:09 ` Will Deacon 2012-08-16 17:25 ` Michal Hocko 2012-08-16 17:25 ` Michal Hocko 2012-08-16 17:34 ` Will Deacon 2012-08-16 17:34 ` Will Deacon 2012-08-16 18:06 ` Michal Hocko 2012-08-16 18:06 ` Michal Hocko 2012-08-16 18:19 ` Will Deacon 2012-08-16 18:19 ` Will Deacon 2012-08-16 18:20 ` Michal Hocko 2012-08-16 18:20 ` Michal Hocko 2012-08-16 18:32 ` Will Deacon 2012-08-16 18:32 ` Will Deacon
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAJd=RBAmF3dtb8wtEbS-A7BNT=RLsb5emQQWVU8ioeQOO8D7NA@mail.gmail.com' \ --to=dhillf@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@suse.cz \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.