From: Greg Ungerer <gerg@linux-m68k.org>
To: Will Deacon <will@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/5] Rewrite Motorola MMU page-table layout
Date: Fri, 31 Jan 2020 23:04:02 +1000 [thread overview]
Message-ID: <6b345fe8-448f-83b4-5527-db0dfe6036f7@linux-m68k.org> (raw)
In-Reply-To: <20200131093813.GA3938@willie-the-truck>
Hi Will,
On 31/1/20 7:38 pm, Will Deacon wrote:
> On Fri, Jan 31, 2020 at 04:31:48PM +1000, Greg Ungerer wrote:
>> On 29/1/20 8:39 pm, Peter Zijlstra wrote:
>>> In order to faciliate Will's READ_ONCE() patches:
>>>
>>> https://lkml.kernel.org/r/20200123153341.19947-1-will@kernel.org
>>>
>>> we need to fix m68k/motorola to not have a giant pmd_t. These patches do so and
>>> are tested using ARAnyM/68040.
>>>
>>> It would be very good if someone can either test or tell us what emulator to
>>> use for 020/030.
>>
>> This series breaks compilation for the ColdFire (with MMU) variant of
>> the m68k family:
>
> [...]
>
>> Easy to reproduce. Build for the m5475evb_defconfig.
>
> I've hacked up a fix below, but I don't know how to test whether it actually
> works (it does fix the build).
Yep, I can confirm that too.
There is no emulators for the MMU based ColdFires (qemu only supports
a non-MMU variant).
I can test on real hardware - but not until Monday when I am back
in my lab. I'll report back then.
> However, I also notice that building for
> m5475evb_defconfig with vanilla v5.5 triggers this scary looking warning
> due to a mismatch between the pgd size and the (8k!) page size:
>
>
> | In function 'pgd_alloc.isra.111',
> | inlined from 'mm_alloc_pgd' at kernel/fork.c:634:12,
> | inlined from 'mm_init.isra.112' at kernel/fork.c:1043:6:
> | ./arch/m68k/include/asm/string.h:72:25: warning: '__builtin_memcpy' forming offset [4097, 8192] is out of the bounds [0, 4096] of object 'kernel_pg_dir' with type 'pgd_t[1024]' {aka 'struct <anonymous>[1024]'} [-Warray-bounds]
> | #define memcpy(d, s, n) __builtin_memcpy(d, s, n)
> | ^~~~~~~~~~~~~~~~~~~~~~~~~
> | ./arch/m68k/include/asm/mcf_pgalloc.h:93:2: note: in expansion of macro 'memcpy'
> | memcpy(new_pgd, swapper_pg_dir, PAGE_SIZE);
> | ^~~~~~
>
>
> I think the correct fix is to add this:
>
>
> diff --git a/arch/m68k/include/asm/mcf_pgalloc.h b/arch/m68k/include/asm/mcf_pgalloc.h
> index 82ec54c2eaa4..c335e6a381a1 100644
> --- a/arch/m68k/include/asm/mcf_pgalloc.h
> +++ b/arch/m68k/include/asm/mcf_pgalloc.h
> @@ -90,7 +90,7 @@ static inline pgd_t *pgd_alloc(struct mm_struct *mm)
> new_pgd = (pgd_t *)__get_free_page(GFP_DMA | __GFP_NOWARN);
> if (!new_pgd)
> return NULL;
> - memcpy(new_pgd, swapper_pg_dir, PAGE_SIZE);
> + memcpy(new_pgd, swapper_pg_dir, PTRS_PER_PGD * sizeof(pgd_t));
> memset(new_pgd, 0, PAGE_OFFSET >> PGDIR_SHIFT);
> return new_pgd;
> }
>
>
> but maybe it should be done as a separate patch give that it's not caused
> by the rework we've been doing.
Indeed I hadn't noticed that before. But good idea, a separate patch
would make sense.
Regards
Greg
> Will
>
> --->8
>
> diff --git a/arch/m68k/include/asm/mcf_pgalloc.h b/arch/m68k/include/asm/mcf_pgalloc.h
> index 82ec54c2eaa4..955d54a6e973 100644
> --- a/arch/m68k/include/asm/mcf_pgalloc.h
> +++ b/arch/m68k/include/asm/mcf_pgalloc.h
> @@ -28,21 +28,22 @@ extern inline pmd_t *pmd_alloc_kernel(pgd_t *pgd, unsigned long address)
> return (pmd_t *) pgd;
> }
>
> -#define pmd_populate(mm, pmd, page) (pmd_val(*pmd) = \
> - (unsigned long)(page_address(page)))
> +#define pmd_populate(mm, pmd, pte) (pmd_val(*pmd) = (unsigned long)(pte))
>
> -#define pmd_populate_kernel(mm, pmd, pte) (pmd_val(*pmd) = (unsigned long)(pte))
> +#define pmd_populate_kernel pmd_populate
>
> -#define pmd_pgtable(pmd) pmd_page(pmd)
> +#define pmd_pgtable(pmd) pfn_to_virt(pmd_val(pmd) >> PAGE_SHIFT)
>
> -static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t page,
> +static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t pgtable,
> unsigned long address)
> {
> + struct page *page = virt_to_page(pgtable);
> +
> pgtable_pte_page_dtor(page);
> __free_page(page);
> }
>
> -static inline struct page *pte_alloc_one(struct mm_struct *mm)
> +static inline pgtable_t pte_alloc_one(struct mm_struct *mm)
> {
> struct page *page = alloc_pages(GFP_DMA, 0);
> pte_t *pte;
> @@ -54,20 +55,19 @@ static inline struct page *pte_alloc_one(struct mm_struct *mm)
> return NULL;
> }
>
> - pte = kmap(page);
> - if (pte) {
> - clear_page(pte);
> - __flush_page_to_ram(pte);
> - flush_tlb_kernel_page(pte);
> - nocache_page(pte);
> - }
> - kunmap(page);
> + pte = page_address(page);
> + clear_page(pte);
> + __flush_page_to_ram(pte);
> + flush_tlb_kernel_page(pte);
> + nocache_page(pte);
>
> - return page;
> + return pte;
> }
>
> -static inline void pte_free(struct mm_struct *mm, struct page *page)
> +static inline void pte_free(struct mm_struct *mm, pgtable_t pgtable)
> {
> + struct page *page = virt_to_page(pgtable);
> +
> pgtable_pte_page_dtor(page);
> __free_page(page);
> }
>
prev parent reply other threads:[~2020-01-31 13:14 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-29 10:39 [PATCH 0/5] Rewrite Motorola MMU page-table layout Peter Zijlstra
2020-01-29 10:39 ` [PATCH 1/5] m68k,mm: Restructure motorola mmu " Peter Zijlstra
2020-01-29 10:39 ` [PATCH 2/5] m68k,mm: Improve kernel_page_table() Peter Zijlstra
2020-01-29 10:39 ` [PATCH 3/5] m68k,mm: Use table allocator for pgtables Peter Zijlstra
2020-01-29 12:11 ` Will Deacon
2020-01-29 12:24 ` Peter Zijlstra
2020-01-29 10:39 ` [PATCH 4/5] m68k,mm: Extend table allocator for multiple sizes Peter Zijlstra
2020-01-29 12:17 ` Will Deacon
2020-01-29 12:43 ` Peter Zijlstra
2020-01-29 13:15 ` Will Deacon
2020-01-29 10:39 ` [PATCH 5/5] m68k,mm: Fully initialize the page-table allocator Peter Zijlstra
2020-01-29 10:49 ` [PATCH 0/5] Rewrite Motorola MMU page-table layout John Paul Adrian Glaubitz
2020-01-29 11:54 ` Peter Zijlstra
2020-01-29 12:05 ` John Paul Adrian Glaubitz
2020-01-29 12:30 ` Peter Zijlstra
2020-01-29 18:52 ` Michael Schmitz
2020-01-29 19:31 ` Peter Zijlstra
2020-01-30 7:31 ` Michael Schmitz
2020-01-30 8:16 ` Peter Zijlstra
2020-01-30 19:12 ` Michael Schmitz
2020-01-31 6:31 ` Greg Ungerer
2020-01-31 9:38 ` Will Deacon
2020-01-31 10:22 ` Peter Zijlstra
2020-01-31 11:14 ` Peter Zijlstra
2020-01-31 11:18 ` Will Deacon
2020-01-31 11:31 ` Peter Zijlstra
2020-01-31 11:43 ` Will Deacon
2020-01-31 13:04 ` Greg Ungerer [this message]
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=6b345fe8-448f-83b4-5527-db0dfe6036f7@linux-m68k.org \
--to=gerg@linux-m68k.org \
--cc=geert@linux-m68k.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=peterz@infradead.org \
--cc=will@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).