From: Michael Ellerman <mpe@ellerman.id.au>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
Nicholas Piggin <npiggin@gmail.com>
Cc: "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] powerpc: Refactor __kernel_map_pages()
Date: Fri, 23 Feb 2024 17:28:32 +1100 [thread overview]
Message-ID: <87ttlzae3z.fsf@mail.lhotse> (raw)
In-Reply-To: <4e610204-492d-4e3f-9ae6-7b8084b523f9@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 22/02/2024 à 06:32, Michael Ellerman a écrit :
>> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>>> __kernel_map_pages() is almost identical for PPC32 and RADIX.
>>>
>>> Refactor it.
>>>
>>> On PPC32 it is not needed for KFENCE, but to keep it simple
>>> just make it similar to PPC64.
>>>
>>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>>> ---
>>> arch/powerpc/include/asm/book3s/64/pgtable.h | 10 ----------
>>> arch/powerpc/include/asm/book3s/64/radix.h | 2 --
>>> arch/powerpc/mm/book3s64/radix_pgtable.c | 14 --------------
>>> arch/powerpc/mm/pageattr.c | 19 +++++++++++++++++++
>>> arch/powerpc/mm/pgtable_32.c | 15 ---------------
>>> 5 files changed, 19 insertions(+), 41 deletions(-)
>>>
>>> diff --git a/arch/powerpc/mm/pageattr.c b/arch/powerpc/mm/pageattr.c
>>> index 421db7c4f2a4..16b8d20d6ca8 100644
>>> --- a/arch/powerpc/mm/pageattr.c
>>> +++ b/arch/powerpc/mm/pageattr.c
>>> @@ -101,3 +101,22 @@ int change_memory_attr(unsigned long addr, int numpages, long action)
>>> return apply_to_existing_page_range(&init_mm, start, size,
>>> change_page_attr, (void *)action);
>>> }
>>> +
>>> +#if defined(CONFIG_DEBUG_PAGEALLOC) || defined(CONFIG_KFENCE)
>>> +#ifdef CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC
>>> +void __kernel_map_pages(struct page *page, int numpages, int enable)
>>> +{
>>> + unsigned long addr = (unsigned long)page_address(page);
>>> +
>>> + if (PageHighMem(page))
>>> + return;
>>> +
>>> + if (IS_ENABLED(CONFIG_PPC_BOOK3S_64) && !radix_enabled())
>>> + hash__kernel_map_pages(page, numpages, enable);
>>> + else if (enable)
>>> + set_memory_p(addr, numpages);
>>> + else
>>> + set_memory_np(addr, numpages);
>>> +}
>>
>> This doesn't build on 32-bit, eg. ppc32_allmodconfig:
>>
>> ../arch/powerpc/mm/pageattr.c: In function '__kernel_map_pages':
>> ../arch/powerpc/mm/pageattr.c:116:23: error: implicit declaration of function 'hash__kernel_map_pages' [-Werror=implicit-function-declaration]
>> 116 | err = hash__kernel_map_pages(page, numpages, enable);
>> | ^~~~~~~~~~~~~~~~~~~~~~
>>
>> I couldn't see a nice way to get around it, so ended up with:
>>
>> void __kernel_map_pages(struct page *page, int numpages, int enable)
>> {
>> int err;
>> unsigned long addr = (unsigned long)page_address(page);
>>
>> if (PageHighMem(page))
>> return;
>>
>> #ifdef CONFIG_PPC_BOOK3S_64
>> if (!radix_enabled())
>> err = hash__kernel_map_pages(page, numpages, enable);
>> else
>> #endif
>> if (enable)
>> err = set_memory_p(addr, numpages);
>> else
>> err = set_memory_np(addr, numpages);
>>
>
>
> I missed something it seems. Not good to leave something unterminated
> when you leave for vacation and think it was finished when you come back.
>
> The best solution I see is to move hash__kernel_map_pages() prototype
> somewhere else.
> $ git grep -e hash__ -e radix__ -- arch/powerpc/include/asm/*.h
> arch/powerpc/include/asm/bug.h:void hash__do_page_fault(struct pt_regs *);
> arch/powerpc/include/asm/mmu.h:extern void radix__mmu_cleanup_all(void);
> arch/powerpc/include/asm/mmu_context.h:extern void radix__switch_mmu_context(struct mm_struct *prev,
> arch/powerpc/include/asm/mmu_context.h: return radix__switch_mmu_context(prev, next);
> arch/powerpc/include/asm/mmu_context.h:extern int hash__alloc_context_id(void);
> arch/powerpc/include/asm/mmu_context.h:void __init hash__reserve_context_id(int id);
> arch/powerpc/include/asm/mmu_context.h: context_id = hash__alloc_context_id();
> arch/powerpc/include/asm/mmu_context.h: * radix__flush_all_mm() to determine the scope (local/global)
> arch/powerpc/include/asm/mmu_context.h: radix__flush_all_mm(mm);
If anything I'd prefer to move those out of there into the book3s/64/
headers :)
> Maybe asm/mmu.h ?
>
> Or mm/mmu_decl.h ?
Yeah I'll do that. It's a bit of a dumping ground, but at least it's
internal to arch code, not exported to the rest of the kernel.
cheers
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
Nicholas Piggin <npiggin@gmail.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 1/2] powerpc: Refactor __kernel_map_pages()
Date: Fri, 23 Feb 2024 17:28:32 +1100 [thread overview]
Message-ID: <87ttlzae3z.fsf@mail.lhotse> (raw)
In-Reply-To: <4e610204-492d-4e3f-9ae6-7b8084b523f9@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 22/02/2024 à 06:32, Michael Ellerman a écrit :
>> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>>> __kernel_map_pages() is almost identical for PPC32 and RADIX.
>>>
>>> Refactor it.
>>>
>>> On PPC32 it is not needed for KFENCE, but to keep it simple
>>> just make it similar to PPC64.
>>>
>>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>>> ---
>>> arch/powerpc/include/asm/book3s/64/pgtable.h | 10 ----------
>>> arch/powerpc/include/asm/book3s/64/radix.h | 2 --
>>> arch/powerpc/mm/book3s64/radix_pgtable.c | 14 --------------
>>> arch/powerpc/mm/pageattr.c | 19 +++++++++++++++++++
>>> arch/powerpc/mm/pgtable_32.c | 15 ---------------
>>> 5 files changed, 19 insertions(+), 41 deletions(-)
>>>
>>> diff --git a/arch/powerpc/mm/pageattr.c b/arch/powerpc/mm/pageattr.c
>>> index 421db7c4f2a4..16b8d20d6ca8 100644
>>> --- a/arch/powerpc/mm/pageattr.c
>>> +++ b/arch/powerpc/mm/pageattr.c
>>> @@ -101,3 +101,22 @@ int change_memory_attr(unsigned long addr, int numpages, long action)
>>> return apply_to_existing_page_range(&init_mm, start, size,
>>> change_page_attr, (void *)action);
>>> }
>>> +
>>> +#if defined(CONFIG_DEBUG_PAGEALLOC) || defined(CONFIG_KFENCE)
>>> +#ifdef CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC
>>> +void __kernel_map_pages(struct page *page, int numpages, int enable)
>>> +{
>>> + unsigned long addr = (unsigned long)page_address(page);
>>> +
>>> + if (PageHighMem(page))
>>> + return;
>>> +
>>> + if (IS_ENABLED(CONFIG_PPC_BOOK3S_64) && !radix_enabled())
>>> + hash__kernel_map_pages(page, numpages, enable);
>>> + else if (enable)
>>> + set_memory_p(addr, numpages);
>>> + else
>>> + set_memory_np(addr, numpages);
>>> +}
>>
>> This doesn't build on 32-bit, eg. ppc32_allmodconfig:
>>
>> ../arch/powerpc/mm/pageattr.c: In function '__kernel_map_pages':
>> ../arch/powerpc/mm/pageattr.c:116:23: error: implicit declaration of function 'hash__kernel_map_pages' [-Werror=implicit-function-declaration]
>> 116 | err = hash__kernel_map_pages(page, numpages, enable);
>> | ^~~~~~~~~~~~~~~~~~~~~~
>>
>> I couldn't see a nice way to get around it, so ended up with:
>>
>> void __kernel_map_pages(struct page *page, int numpages, int enable)
>> {
>> int err;
>> unsigned long addr = (unsigned long)page_address(page);
>>
>> if (PageHighMem(page))
>> return;
>>
>> #ifdef CONFIG_PPC_BOOK3S_64
>> if (!radix_enabled())
>> err = hash__kernel_map_pages(page, numpages, enable);
>> else
>> #endif
>> if (enable)
>> err = set_memory_p(addr, numpages);
>> else
>> err = set_memory_np(addr, numpages);
>>
>
>
> I missed something it seems. Not good to leave something unterminated
> when you leave for vacation and think it was finished when you come back.
>
> The best solution I see is to move hash__kernel_map_pages() prototype
> somewhere else.
> $ git grep -e hash__ -e radix__ -- arch/powerpc/include/asm/*.h
> arch/powerpc/include/asm/bug.h:void hash__do_page_fault(struct pt_regs *);
> arch/powerpc/include/asm/mmu.h:extern void radix__mmu_cleanup_all(void);
> arch/powerpc/include/asm/mmu_context.h:extern void radix__switch_mmu_context(struct mm_struct *prev,
> arch/powerpc/include/asm/mmu_context.h: return radix__switch_mmu_context(prev, next);
> arch/powerpc/include/asm/mmu_context.h:extern int hash__alloc_context_id(void);
> arch/powerpc/include/asm/mmu_context.h:void __init hash__reserve_context_id(int id);
> arch/powerpc/include/asm/mmu_context.h: context_id = hash__alloc_context_id();
> arch/powerpc/include/asm/mmu_context.h: * radix__flush_all_mm() to determine the scope (local/global)
> arch/powerpc/include/asm/mmu_context.h: radix__flush_all_mm(mm);
If anything I'd prefer to move those out of there into the book3s/64/
headers :)
> Maybe asm/mmu.h ?
>
> Or mm/mmu_decl.h ?
Yeah I'll do that. It's a bit of a dumping ground, but at least it's
internal to arch code, not exported to the rest of the kernel.
cheers
next prev parent reply other threads:[~2024-02-23 6:29 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-16 10:17 [PATCH 1/2] powerpc: Refactor __kernel_map_pages() Christophe Leroy
2024-02-16 10:17 ` Christophe Leroy
2024-02-16 10:17 ` [PATCH 2/2] powerpc: Don't ignore errors from set_memory_{n}p() in __kernel_map_pages() Christophe Leroy
2024-02-16 10:17 ` Christophe Leroy
2024-02-21 12:09 ` Michael Ellerman
2024-02-21 12:09 ` Michael Ellerman
2024-02-21 12:55 ` Christophe Leroy
2024-02-21 12:55 ` Christophe Leroy
2024-02-21 22:59 ` Michael Ellerman
2024-02-21 22:59 ` Michael Ellerman
2024-02-22 5:32 ` [PATCH 1/2] powerpc: Refactor __kernel_map_pages() Michael Ellerman
2024-02-22 5:32 ` Michael Ellerman
2024-02-22 7:59 ` Christophe Leroy
2024-02-22 7:59 ` Christophe Leroy
2024-02-23 6:28 ` Michael Ellerman [this message]
2024-02-23 6:28 ` Michael Ellerman
2024-03-13 13:19 ` Michael Ellerman
2024-03-13 13:19 ` Michael Ellerman
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=87ttlzae3z.fsf@mail.lhotse \
--to=mpe@ellerman.id.au \
--cc=christophe.leroy@csgroup.eu \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=npiggin@gmail.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 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.