From: Catalin Marinas <catalin.marinas@arm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Ralf Baechle <ralf@linux-mips.org>,
Will Deacon <will.deacon@arm.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-arch@vger.kernel.org, mhocko@suse.cz,
Steve Capper <steve.capper@arm.com>
Subject: Re: [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c
Date: Wed, 19 Sep 2012 10:12:28 +0100 [thread overview]
Message-ID: <CAHkRjk7uCZZvA_Ubq7vgkAV2r-vMNHxs+hZmvf+99ks+4v7isA@mail.gmail.com> (raw)
In-Reply-To: <20120918123331.6ca5833c.akpm@linux-foundation.org>
On 18 September 2012 20:33, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Sat, 15 Sep 2012 15:38:33 +0200
> Ralf Baechle <ralf@linux-mips.org> wrote:
>> On Tue, Sep 11, 2012 at 05:47:15PM +0100, Will Deacon wrote:
>> > The update_mmu_cache() takes a pointer (to pte_t by default) as the last
>> > argument but the huge_memory.c passes a pmd_t value. The patch changes
>> > the argument to the pmd_t * pointer.
>> >
>> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
>> > Signed-off-by: Steve Capper <steve.capper@arm.com>
>> > Signed-off-by: Will Deacon <will.deacon@arm.com>
>> > ---
>> > mm/huge_memory.c | 6 +++---
>> > 1 files changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> > index 57c4b93..4aa6d02 100644
>> > --- a/mm/huge_memory.c
>> > +++ b/mm/huge_memory.c
>> > @@ -934,7 +934,7 @@ int do_huge_pmd_wp_page(struct mm_struct *mm, struct vm_area_struct *vma,
>> > entry = pmd_mkyoung(orig_pmd);
>> > entry = maybe_pmd_mkwrite(pmd_mkdirty(entry), vma);
>> > if (pmdp_set_access_flags(vma, haddr, pmd, entry, 1))
>> > - update_mmu_cache(vma, address, entry);
>> > + update_mmu_cache(vma, address, pmd);
>>
>> Documentation/cachetlb.txt will need an update as well. Currently it says:
>>
>> 5) void update_mmu_cache(struct vm_area_struct *vma,
>> unsigned long address, pte_t *ptep)
>
> Yes please.
Should we just use a generic (void *) for the last argument or force a
cast in mm/huge_memory.c?
Ralf's point is that transparent huge page code calls update_mmu_cache
with a (pmd_t *) as the last argument. This could make sense for THP
as it assumes that huge pages can only be created at the pmd level.
But that's unlike mm/hugetlb.c which casts huge page types to pte_t,
even though on ARM they are implemented at the pmd level.
On ARM (with VIPT caches) update_mmu_cache() is empty like on x86,
though a static inline rather than macro.
--
Catalin
--
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-09-19 9:12 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-11 16:47 [PATCH 0/3] Minor changes to common hugetlb code for ARM Will Deacon
2012-09-11 16:47 ` [PATCH 1/3] mm: thp: Fix the pmd_clear() arguments in pmdp_get_and_clear() Will Deacon
2012-09-11 17:12 ` Kirill A. Shutemov
2012-09-12 15:30 ` Michal Hocko
2012-09-11 16:47 ` [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c Will Deacon
2012-09-11 17:38 ` Kirill A. Shutemov
2012-09-12 15:40 ` Michal Hocko
2012-09-12 15:51 ` Catalin Marinas
2012-09-15 13:38 ` Ralf Baechle
2012-09-18 19:33 ` Andrew Morton
2012-09-19 9:12 ` Catalin Marinas [this message]
2012-09-19 15:53 ` Ralf Baechle
2012-09-20 12:44 ` Will Deacon
2012-09-20 19:32 ` David Miller
2012-09-11 16:47 ` [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE Will Deacon
2012-09-11 17:41 ` Kirill A. Shutemov
2012-09-12 15:32 ` Michal Hocko
2012-09-12 18:06 ` Chris Metcalf
2012-09-12 18:10 ` Will Deacon
2012-09-13 19:05 ` Andrew Morton
2012-09-13 21:26 ` Will Deacon
2012-09-13 21:27 ` Stephen Rothwell
2012-09-13 21:40 ` Andrew Morton
2012-09-12 15:27 ` [PATCH 0/3] Minor changes to common hugetlb code for ARM Michal Hocko
2012-09-12 15:55 ` Will Deacon
2012-09-13 12:22 ` Michal Hocko
2012-09-13 0:12 ` Andrea Arcangeli
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=CAHkRjk7uCZZvA_Ubq7vgkAV2r-vMNHxs+hZmvf+99ks+4v7isA@mail.gmail.com \
--to=catalin.marinas@arm.com \
--cc=akpm@linux-foundation.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=ralf@linux-mips.org \
--cc=steve.capper@arm.com \
--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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox