From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au,
linuxram@us.ibm.com
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 1/2] powerpc/mm: Fix crashes with PUD level hugetlb config
Date: Sat, 10 Feb 2018 15:17:02 +0530 [thread overview]
Message-ID: <87o9kxfa7d.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <87r2pvfr5g.fsf@linux.vnet.ibm.com>
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> writes:
> "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
>
>> To support memory keys, we moved the hash pte slot information to the second
>> half of the page table. This was ok with PTE entries at level 4 and level 3.
>> We already allocate larger page table pages at those level to accomodate extra
>> details. For level 4 we already have the extra space which was used to track
>> 4k hash page table entry details and at pmd level the extra space was allocated
>> to track the THP details.
>>
>> With hugetlbfs PTE, we used this extra space at the PMD level to store the
>> slot details. But we also support hugetlbfs PTE at PUD leve and PUD level page
>> didn't allocate extra space. This resulted in memory corruption.
>>
>> Fix this by allocating extra space at PUD level when HUGETLB is enabled. We
>> may need further changes to allocate larger space at PMD level when we enable
>> HUGETLB. That will be done in next patch.
>>
>> Fixes:bf9a95f9a6481bc6e(" powerpc: Free up four 64K PTE bits in 64K backed HPTE pages")
>>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>
> Another fix, I still get random memory corruption with hugetlb test with
> 16G hugepage config.
Another one. I am not sure whether we really want this in this form. But
with this tests are running fine.
-aneesh
commit 658fe8c310a913e69e5bc9a40d4c28a3b88d5c08
Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Date: Sat Feb 10 13:17:34 2018 +0530
powerpc/mm/hash64: memset the pagetable pages on allocation.
Now that we are using second half of the table to store slot details and we
don't clear them in the huge_pte_get_and_clear, we need to make sure we zero
out the range on allocation. This done some extra work because the first half
of the table is cleared by huge_pte_get_and_clear and memset in this patch
zero-out the full table page.
We need to do this for pgd and pud because both get allocated from the same slab
cache.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
The other option is to get huget_pte_get_and_clear to clear the second half of the page table.
That requires generic changes, because we don't have hugetlb page size available there.
diff --git a/arch/powerpc/include/asm/book3s/64/pgalloc.h b/arch/powerpc/include/asm/book3s/64/pgalloc.h
index 53df86d3cfce..adb7fba4b6c7 100644
--- a/arch/powerpc/include/asm/book3s/64/pgalloc.h
+++ b/arch/powerpc/include/asm/book3s/64/pgalloc.h
@@ -73,10 +73,13 @@ static inline void radix__pgd_free(struct mm_struct *mm, pgd_t *pgd)
static inline pgd_t *pgd_alloc(struct mm_struct *mm)
{
+ pgd_t *pgd;
if (radix_enabled())
return radix__pgd_alloc(mm);
- return kmem_cache_alloc(PGT_CACHE(PGD_INDEX_SIZE),
- pgtable_gfp_flags(mm, GFP_KERNEL));
+ pgd = kmem_cache_alloc(PGT_CACHE(PGD_INDEX_SIZE),
+ pgtable_gfp_flags(mm, GFP_KERNEL));
+ memset(pgd, 0, PGD_TABLE_SIZE);
+ return pgd;
}
static inline void pgd_free(struct mm_struct *mm, pgd_t *pgd)
@@ -93,8 +96,11 @@ static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, pud_t *pud)
static inline pud_t *pud_alloc_one(struct mm_struct *mm, unsigned long addr)
{
- return kmem_cache_alloc(PGT_CACHE(PUD_CACHE_INDEX),
- pgtable_gfp_flags(mm, GFP_KERNEL));
+ pud_t *pud;
+ pud = kmem_cache_alloc(PGT_CACHE(PUD_CACHE_INDEX),
+ pgtable_gfp_flags(mm, GFP_KERNEL));
+ memset(pud, 0, PUD_TABLE_SIZE);
+ return pud;
}
static inline void pud_free(struct mm_struct *mm, pud_t *pud)
next prev parent reply other threads:[~2018-02-10 9:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-08 10:34 [PATCH 1/2] powerpc/mm: Fix crashes with PUD level hugetlb config Aneesh Kumar K.V
2018-02-08 10:34 ` [PATCH 2/2] powerpc/mm/hash64: Allocate larger PMD table if hugetlb config is enabled Aneesh Kumar K.V
2018-02-08 15:16 ` [PATCH 1/2] powerpc/mm: Fix crashes with PUD level hugetlb config Aneesh Kumar K.V
2018-02-08 19:29 ` Ram Pai
2018-02-09 15:31 ` Aneesh Kumar K.V
2018-02-10 9:47 ` Aneesh Kumar K.V [this message]
2018-02-10 16:50 ` Ram Pai
2018-02-10 17:14 ` Aneesh Kumar K.V
2018-02-08 19:22 ` Ram Pai
2018-02-09 15:30 ` Aneesh Kumar K.V
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=87o9kxfa7d.fsf@linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=linuxram@us.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
/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 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.