* Re: [PATCH V2 0/3] mm/debug: Add more arch page table helper tests
From: Christophe Leroy @ 2020-03-26 15:23 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm
Cc: linux-doc, Heiko Carstens, Paul Mackerras, H. Peter Anvin,
linux-riscv, Will Deacon, linux-arch, linux-s390, Jonathan Corbet,
x86, Mike Rapoport, Christian Borntraeger, Ingo Molnar,
Catalin Marinas, linux-snps-arc, Vasily Gorbik, Borislav Petkov,
Paul Walmsley, Kirill A . Shutemov, Thomas Gleixner,
linux-arm-kernel, Vineet Gupta, linux-kernel, Palmer Dabbelt,
Andrew Morton, linuxppc-dev
In-Reply-To: <2bb4badc-2b7a-e15d-a99b-b1bd38c9d9bf@arm.com>
Le 26/03/2020 à 03:23, Anshuman Khandual a écrit :
>
>
> On 03/24/2020 10:52 AM, Anshuman Khandual wrote:
>> This series adds more arch page table helper tests. The new tests here are
>> either related to core memory functions and advanced arch pgtable helpers.
>> This also creates a documentation file enlisting all expected semantics as
>> suggested by Mike Rapoport (https://lkml.org/lkml/2020/1/30/40).
>>
>> This series has been tested on arm64 and x86 platforms.
>
> If folks can test these patches out on remaining ARCH_HAS_DEBUG_VM_PGTABLE
> enabled platforms i.e s390, arc, powerpc (32 and 64), that will be really
> appreciated. Thank you.
>
On powerpc 8xx (PPC32), I get:
[ 53.338368] debug_vm_pgtable: debug_vm_pgtable: Validating
architecture page table helpers
[ 53.347403] ------------[ cut here ]------------
[ 53.351832] WARNING: CPU: 0 PID: 1 at mm/debug_vm_pgtable.c:647
debug_vm_pgtable+0x280/0x3f4
[ 53.360140] CPU: 0 PID: 1 Comm: swapper Not tainted
5.6.0-rc7-s3k-dev-01090-g92710e99881f #3544
[ 53.368718] NIP: c0777c04 LR: c0777bb8 CTR: 00000000
[ 53.373720] REGS: c9023df0 TRAP: 0700 Not tainted
(5.6.0-rc7-s3k-dev-01090-g92710e99881f)
[ 53.382042] MSR: 00029032 <EE,ME,IR,DR,RI> CR: 22000222 XER: 20000000
[ 53.388667]
[ 53.388667] GPR00: c0777bb8 c9023ea8 c6120000 00000001 1e410000
00000000 00000000 007641c9
[ 53.388667] GPR08: 00000000 00000001 00000000 ffffffff 82000222
00000000 c00039b8 00000000
[ 53.388667] GPR16: 00000000 00000000 00000000 fffffff0 065fc000
1e410000 c6600000 000001e4
[ 53.388667] GPR24: 000001d9 c062d14c c65fc000 c642d448 000006c9
00000000 c65f8000 c65fc040
[ 53.423400] NIP [c0777c04] debug_vm_pgtable+0x280/0x3f4
[ 53.428559] LR [c0777bb8] debug_vm_pgtable+0x234/0x3f4
[ 53.433593] Call Trace:
[ 53.436048] [c9023ea8] [c0777bb8] debug_vm_pgtable+0x234/0x3f4
(unreliable)
[ 53.442936] [c9023f28] [c00039e0] kernel_init+0x28/0x124
[ 53.448184] [c9023f38] [c000f174] ret_from_kernel_thread+0x14/0x1c
[ 53.454245] Instruction dump:
[ 53.457180] 41a20008 4bea3ed9 62890021 7d36b92e 7d36b82e 71290fd0
3149ffff 7d2a4910
[ 53.464838] 0f090000 5789077e 3149ffff 7d2a4910 <0f090000> 38c00000
38a00000 38800000
[ 53.472671] ---[ end trace fd5dd92744dc0065 ]---
[ 53.519778] Freeing unused kernel memory: 608K
^ permalink raw reply
* [RFC PATCH] powerpc/lib: Fixing use a temporary mm for code patching
From: Christophe Leroy @ 2020-03-26 14:42 UTC (permalink / raw)
To: cmr; +Cc: linuxppc-dev, linux-kernel
This patch fixes the RFC series identified below.
It fixes three points:
- Failure with CONFIG_PPC_KUAP
- Failure to write do to lack of DIRTY bit set on the 8xx
- Inadequaly complex WARN post verification
However, it has an impact on the CPU load. Here is the time
needed on an 8xx to run the ftrace selftests without and
with this series:
- Without CONFIG_STRICT_KERNEL_RWX ==> 38 seconds
- With CONFIG_STRICT_KERNEL_RWX ==> 40 seconds
- With CONFIG_STRICT_KERNEL_RWX + this series ==> 43 seconds
Link: https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=166003
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/lib/code-patching.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index f156132e8975..4ccff427592e 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -97,6 +97,7 @@ static int map_patch(const void *addr, struct patch_mapping *patch_mapping)
}
pte = mk_pte(page, pgprot);
+ pte = pte_mkdirty(pte);
set_pte_at(patching_mm, patching_addr, ptep, pte);
init_temp_mm(&patch_mapping->temp_mm, patching_mm);
@@ -168,7 +169,9 @@ static int do_patch_instruction(unsigned int *addr, unsigned int instr)
(offset_in_page((unsigned long)addr) /
sizeof(unsigned int));
+ allow_write_to_user(patch_addr, sizeof(instr));
__patch_instruction(addr, instr, patch_addr);
+ prevent_write_to_user(patch_addr, sizeof(instr));
err = unmap_patch(&patch_mapping);
if (err)
@@ -179,7 +182,7 @@ static int do_patch_instruction(unsigned int *addr, unsigned int instr)
* think we just wrote.
* XXX: BUG_ON() instead?
*/
- WARN_ON(memcmp(addr, &instr, sizeof(instr)));
+ WARN_ON(*addr != instr);
out:
local_irq_restore(flags);
--
2.25.0
^ permalink raw reply related
* Re: [PATCH v2] mm/sparse: Fix kernel crash with pfn_section_valid check
From: Michal Hocko @ 2020-03-26 13:55 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Sachin Sant, Pankaj Gupta, Baoquan He, David Hildenbrand,
linux-kernel, stable, Mike Rapoport, linux-mm, Wei Yang, akpm,
linuxppc-dev, Dan Williams, Oscar Salvador
In-Reply-To: <20200326133235.343616-1-aneesh.kumar@linux.ibm.com>
On Thu 26-03-20 19:02:35, Aneesh Kumar K.V wrote:
> Fixes the below crash
>
> BUG: Kernel NULL pointer dereference on read at 0x00000000
> Faulting instruction address: 0xc000000000c3447c
> Oops: Kernel access of bad area, sig: 11 [#1]
> LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
> CPU: 11 PID: 7519 Comm: lt-ndctl Not tainted 5.6.0-rc7-autotest #1
> ...
> NIP [c000000000c3447c] vmemmap_populated+0x98/0xc0
> LR [c000000000088354] vmemmap_free+0x144/0x320
> Call Trace:
> section_deactivate+0x220/0x240
> __remove_pages+0x118/0x170
> arch_remove_memory+0x3c/0x150
> memunmap_pages+0x1cc/0x2f0
> devm_action_release+0x30/0x50
> release_nodes+0x2f8/0x3e0
> device_release_driver_internal+0x168/0x270
> unbind_store+0x130/0x170
> drv_attr_store+0x44/0x60
> sysfs_kf_write+0x68/0x80
> kernfs_fop_write+0x100/0x290
> __vfs_write+0x3c/0x70
> vfs_write+0xcc/0x240
> ksys_write+0x7c/0x140
> system_call+0x5c/0x68
>
> The crash is due to NULL dereference at
>
> test_bit(idx, ms->usage->subsection_map); due to ms->usage = NULL; in pfn_section_valid()
>
> With commit: d41e2f3bd546 ("mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case")
> section_mem_map is set to NULL after depopulate_section_mem(). This
> was done so that pfn_page() can work correctly with kernel config that disables
> SPARSEMEM_VMEMMAP. With that config pfn_to_page does
>
> __section_mem_map_addr(__sec) + __pfn;
> where
>
> static inline struct page *__section_mem_map_addr(struct mem_section *section)
> {
> unsigned long map = section->section_mem_map;
> map &= SECTION_MAP_MASK;
> return (struct page *)map;
> }
>
> Now with SPASEMEM_VMEMAP enabled, mem_section->usage->subsection_map is used to
> check the pfn validity (pfn_valid()). Since section_deactivate release
> mem_section->usage if a section is fully deactivated, pfn_valid() check after
> a subsection_deactivate cause a kernel crash.
>
> static inline int pfn_valid(unsigned long pfn)
> {
> ...
> return early_section(ms) || pfn_section_valid(ms, pfn);
> }
>
> where
>
> static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn)
> {
> int idx = subsection_map_index(pfn);
>
> return test_bit(idx, ms->usage->subsection_map);
> }
>
> Avoid this by clearing SECTION_HAS_MEM_MAP when mem_section->usage is freed.
> For architectures like ppc64 where large pages are used for vmmemap mapping (16MB),
> a specific vmemmap mapping can cover multiple sections. Hence before a vmemmap
> mapping page can be freed, the kernel needs to make sure there are no valid sections
> within that mapping. Clearing the section valid bit before
> depopulate_section_memap enables this.
I believe that the necessity of clearing the section before the tear
down is worth a comment into the code. Because this is just way to easy
to miss or not be aware at all while looking into the code without git
balme.
> Fixes: d41e2f3bd546 ("mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case")
> Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
> Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Wei Yang <richardw.yang@linux.intel.com>
> Cc: Oscar Salvador <osalvador@suse.de>
> Cc: Mike Rapoport <rppt@linux.ibm.com>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Thanks!
> ---
> mm/sparse.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/mm/sparse.c b/mm/sparse.c
> index aadb7298dcef..65599e8bd636 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -781,6 +781,12 @@ static void section_deactivate(unsigned long pfn, unsigned long nr_pages,
> ms->usage = NULL;
> }
> memmap = sparse_decode_mem_map(ms->section_mem_map, section_nr);
> + /*
> + * Mark the section invalid so that valid_section()
> + * return false. This prevents code from dereferencing
> + * ms->usage array.
> + */
> + ms->section_mem_map &= ~SECTION_HAS_MEM_MAP;
> }
>
> if (section_is_early && memmap)
> --
> 2.25.1
>
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [powerpc] Intermittent crashes ( link_path_walk) with linux-next
From: Al Viro @ 2020-03-26 13:49 UTC (permalink / raw)
To: Michael Ellerman
Cc: Sachin Sant, linux-fsdevel, Linux Next Mailing List, linuxppc-dev
In-Reply-To: <87h7ybwdih.fsf@mpe.ellerman.id.au>
On Thu, Mar 26, 2020 at 10:40:06PM +1100, Michael Ellerman wrote:
> > The code in question (link_path_walk() in fs/namei.c ) was recently changed by
> > following commit:
> >
> > commit 881386f7e46a:
> > link_path_walk(): sample parent's i_uid and i_mode for the last component
>
> That and about 10 other commits.
>
> Unless Al can give us a clue we'll need to bisect.
Already fixed yesterday. It's not link_path_walk(), it's handle_dots()
ignoring an error returned by step_into().
commit 5e3c3570ec97 is the broken one; commit 20971012f63e is its variant with the
fix folded in. So next-20200325 has the bug and next-20200326 should have it
fixed. Could you check the current -next and see if you still observe that crap?
^ permalink raw reply
* Re: [PATCH v2] mm/sparse: Fix kernel crash with pfn_section_valid check
From: Baoquan He @ 2020-03-26 13:38 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Sachin Sant, Pankaj Gupta, Michal Hocko, David Hildenbrand,
linux-kernel, stable, Mike Rapoport, linux-mm, Wei Yang, akpm,
linuxppc-dev, Dan Williams, Oscar Salvador
In-Reply-To: <20200326133235.343616-1-aneesh.kumar@linux.ibm.com>
On 03/26/20 at 07:02pm, Aneesh Kumar K.V wrote:
> Fixes the below crash
>
> BUG: Kernel NULL pointer dereference on read at 0x00000000
> Faulting instruction address: 0xc000000000c3447c
> Oops: Kernel access of bad area, sig: 11 [#1]
> LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
> CPU: 11 PID: 7519 Comm: lt-ndctl Not tainted 5.6.0-rc7-autotest #1
> ...
> NIP [c000000000c3447c] vmemmap_populated+0x98/0xc0
> LR [c000000000088354] vmemmap_free+0x144/0x320
> Call Trace:
> section_deactivate+0x220/0x240
> __remove_pages+0x118/0x170
> arch_remove_memory+0x3c/0x150
> memunmap_pages+0x1cc/0x2f0
> devm_action_release+0x30/0x50
> release_nodes+0x2f8/0x3e0
> device_release_driver_internal+0x168/0x270
> unbind_store+0x130/0x170
> drv_attr_store+0x44/0x60
> sysfs_kf_write+0x68/0x80
> kernfs_fop_write+0x100/0x290
> __vfs_write+0x3c/0x70
> vfs_write+0xcc/0x240
> ksys_write+0x7c/0x140
> system_call+0x5c/0x68
>
> The crash is due to NULL dereference at
>
> test_bit(idx, ms->usage->subsection_map); due to ms->usage = NULL; in pfn_section_valid()
>
> With commit: d41e2f3bd546 ("mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case")
> section_mem_map is set to NULL after depopulate_section_mem(). This
> was done so that pfn_page() can work correctly with kernel config that disables
> SPARSEMEM_VMEMMAP. With that config pfn_to_page does
>
> __section_mem_map_addr(__sec) + __pfn;
> where
>
> static inline struct page *__section_mem_map_addr(struct mem_section *section)
> {
> unsigned long map = section->section_mem_map;
> map &= SECTION_MAP_MASK;
> return (struct page *)map;
> }
>
> Now with SPASEMEM_VMEMAP enabled, mem_section->usage->subsection_map is used to
> check the pfn validity (pfn_valid()). Since section_deactivate release
> mem_section->usage if a section is fully deactivated, pfn_valid() check after
> a subsection_deactivate cause a kernel crash.
>
> static inline int pfn_valid(unsigned long pfn)
> {
> ...
> return early_section(ms) || pfn_section_valid(ms, pfn);
> }
>
> where
>
> static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn)
> {
> int idx = subsection_map_index(pfn);
>
> return test_bit(idx, ms->usage->subsection_map);
> }
>
> Avoid this by clearing SECTION_HAS_MEM_MAP when mem_section->usage is freed.
> For architectures like ppc64 where large pages are used for vmmemap mapping (16MB),
> a specific vmemmap mapping can cover multiple sections. Hence before a vmemmap
> mapping page can be freed, the kernel needs to make sure there are no valid sections
> within that mapping. Clearing the section valid bit before
> depopulate_section_memap enables this.
>
> Fixes: d41e2f3bd546 ("mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case")
> Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
> Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Wei Yang <richardw.yang@linux.intel.com>
> Cc: Oscar Salvador <osalvador@suse.de>
> Cc: Mike Rapoport <rppt@linux.ibm.com>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> mm/sparse.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/mm/sparse.c b/mm/sparse.c
> index aadb7298dcef..65599e8bd636 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -781,6 +781,12 @@ static void section_deactivate(unsigned long pfn, unsigned long nr_pages,
> ms->usage = NULL;
> }
> memmap = sparse_decode_mem_map(ms->section_mem_map, section_nr);
> + /*
> + * Mark the section invalid so that valid_section()
> + * return false. This prevents code from dereferencing
> + * ms->usage array.
> + */
> + ms->section_mem_map &= ~SECTION_HAS_MEM_MAP;
> }
Reviewed-by: Baoquan He <bhe@redhat.com>
^ permalink raw reply
* [PATCH v2] mm/sparse: Fix kernel crash with pfn_section_valid check
From: Aneesh Kumar K.V @ 2020-03-26 13:32 UTC (permalink / raw)
To: linux-mm, akpm
Cc: Sachin Sant, Pankaj Gupta, Michal Hocko, Baoquan He,
David Hildenbrand, linux-kernel, stable, Mike Rapoport, Wei Yang,
Aneesh Kumar K.V, Dan Williams, linuxppc-dev, Oscar Salvador
Fixes the below crash
BUG: Kernel NULL pointer dereference on read at 0x00000000
Faulting instruction address: 0xc000000000c3447c
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
CPU: 11 PID: 7519 Comm: lt-ndctl Not tainted 5.6.0-rc7-autotest #1
...
NIP [c000000000c3447c] vmemmap_populated+0x98/0xc0
LR [c000000000088354] vmemmap_free+0x144/0x320
Call Trace:
section_deactivate+0x220/0x240
__remove_pages+0x118/0x170
arch_remove_memory+0x3c/0x150
memunmap_pages+0x1cc/0x2f0
devm_action_release+0x30/0x50
release_nodes+0x2f8/0x3e0
device_release_driver_internal+0x168/0x270
unbind_store+0x130/0x170
drv_attr_store+0x44/0x60
sysfs_kf_write+0x68/0x80
kernfs_fop_write+0x100/0x290
__vfs_write+0x3c/0x70
vfs_write+0xcc/0x240
ksys_write+0x7c/0x140
system_call+0x5c/0x68
The crash is due to NULL dereference at
test_bit(idx, ms->usage->subsection_map); due to ms->usage = NULL; in pfn_section_valid()
With commit: d41e2f3bd546 ("mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case")
section_mem_map is set to NULL after depopulate_section_mem(). This
was done so that pfn_page() can work correctly with kernel config that disables
SPARSEMEM_VMEMMAP. With that config pfn_to_page does
__section_mem_map_addr(__sec) + __pfn;
where
static inline struct page *__section_mem_map_addr(struct mem_section *section)
{
unsigned long map = section->section_mem_map;
map &= SECTION_MAP_MASK;
return (struct page *)map;
}
Now with SPASEMEM_VMEMAP enabled, mem_section->usage->subsection_map is used to
check the pfn validity (pfn_valid()). Since section_deactivate release
mem_section->usage if a section is fully deactivated, pfn_valid() check after
a subsection_deactivate cause a kernel crash.
static inline int pfn_valid(unsigned long pfn)
{
...
return early_section(ms) || pfn_section_valid(ms, pfn);
}
where
static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn)
{
int idx = subsection_map_index(pfn);
return test_bit(idx, ms->usage->subsection_map);
}
Avoid this by clearing SECTION_HAS_MEM_MAP when mem_section->usage is freed.
For architectures like ppc64 where large pages are used for vmmemap mapping (16MB),
a specific vmemmap mapping can cover multiple sections. Hence before a vmemmap
mapping page can be freed, the kernel needs to make sure there are no valid sections
within that mapping. Clearing the section valid bit before
depopulate_section_memap enables this.
Fixes: d41e2f3bd546 ("mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case")
Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Wei Yang <richardw.yang@linux.intel.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
mm/sparse.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/mm/sparse.c b/mm/sparse.c
index aadb7298dcef..65599e8bd636 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -781,6 +781,12 @@ static void section_deactivate(unsigned long pfn, unsigned long nr_pages,
ms->usage = NULL;
}
memmap = sparse_decode_mem_map(ms->section_mem_map, section_nr);
+ /*
+ * Mark the section invalid so that valid_section()
+ * return false. This prevents code from dereferencing
+ * ms->usage array.
+ */
+ ms->section_mem_map &= ~SECTION_HAS_MEM_MAP;
}
if (section_is_early && memmap)
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v5 10/13] powerpc/ptrace: split out ADV_DEBUG_REGS related functions.
From: Christophe Leroy @ 2020-03-26 12:53 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras, mikey
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <87k13axoda.fsf@mpe.ellerman.id.au>
Le 24/03/2020 à 07:23, Michael Ellerman a écrit :
> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>> On 03/20/2020 02:12 AM, Michael Ellerman wrote:
>>> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>>>> Move ADV_DEBUG_REGS functions out of ptrace.c, into
>>>> ptrace-adv.c and ptrace-noadv.c
>>>>
>>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>>> ---
>>>> v4: Leave hw_breakpoint.h for ptrace.c
>>>> ---
>>>> arch/powerpc/kernel/ptrace/Makefile | 4 +
>>>> arch/powerpc/kernel/ptrace/ptrace-adv.c | 468 ++++++++++++++++
>>>> arch/powerpc/kernel/ptrace/ptrace-decl.h | 5 +
>>>> arch/powerpc/kernel/ptrace/ptrace-noadv.c | 236 ++++++++
>>>> arch/powerpc/kernel/ptrace/ptrace.c | 650 ----------------------
>>>> 5 files changed, 713 insertions(+), 650 deletions(-)
>>>> create mode 100644 arch/powerpc/kernel/ptrace/ptrace-adv.c
>>>> create mode 100644 arch/powerpc/kernel/ptrace/ptrace-noadv.c
>>>
>>> This is somehow breaking the ptrace-hwbreak selftest on Power8:
>>>
>>> test: ptrace-hwbreak
>>> tags: git_version:v5.6-rc6-892-g7a285a6067d6
>>> PTRACE_SET_DEBUGREG, WO, len: 1: Ok
>>> PTRACE_SET_DEBUGREG, WO, len: 2: Ok
>>> PTRACE_SET_DEBUGREG, WO, len: 4: Ok
>>> PTRACE_SET_DEBUGREG, WO, len: 8: Ok
>>> PTRACE_SET_DEBUGREG, RO, len: 1: Ok
>>> PTRACE_SET_DEBUGREG, RO, len: 2: Ok
>>> PTRACE_SET_DEBUGREG, RO, len: 4: Ok
>>> PTRACE_SET_DEBUGREG, RO, len: 8: Ok
>>> PTRACE_SET_DEBUGREG, RW, len: 1: Ok
>>> PTRACE_SET_DEBUGREG, RW, len: 2: Ok
>>> PTRACE_SET_DEBUGREG, RW, len: 4: Ok
>>> PTRACE_SET_DEBUGREG, RW, len: 8: Ok
>>> PPC_PTRACE_SETHWDEBUG, MODE_EXACT, WO, len: 1: Ok
>>> PPC_PTRACE_SETHWDEBUG, MODE_EXACT, RO, len: 1: Ok
>>> PPC_PTRACE_SETHWDEBUG, MODE_EXACT, RW, len: 1: Ok
>>> PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW ALIGNED, WO, len: 6: Ok
>>> PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW ALIGNED, RO, len: 6: Ok
>>> PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW ALIGNED, RW, len: 6: Ok
>>> PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW UNALIGNED, WO, len: 6: Ok
>>> PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW UNALIGNED, RO, len: 6: Fail
>>> failure: ptrace-hwbreak
>>>
>>> I haven't had time to work out why yet.
>>>
>>
>> A (big) part of commit c3f68b0478e7 ("powerpc/watchpoint: Fix ptrace
>> code that muck around with address/len") was lost during rebase.
>>
>> I'll send a fix, up to you to squash it in or commit it as is.
>
> Thanks.
>
One person asked me if I sent the fix already. So yes, it is there:
https://patchwork.ozlabs.org/patch/1259348/
Christophe
^ permalink raw reply
* Re: [PATCH] powerpc/prom_init: Remove leftover comment
From: Michael Ellerman @ 2020-03-26 12:07 UTC (permalink / raw)
To: Fabiano Rosas, linuxppc-dev
In-Reply-To: <20200324182912.1048906-1-farosas@linux.ibm.com>
On Tue, 2020-03-24 at 18:29:12 UTC, Fabiano Rosas wrote:
> The if statement that this comment referred to was removed in
> commit 11fdb309341c ("powerpc/prom_init: Remove support for OPAL v2").
>
> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/7074695ac6fb965d478f373b95bc5c636e9f21b0
cheers
^ permalink raw reply
* Re: [PATCH v6 1/2] powerpc/64: Setup a paca before parsing device tree etc.
From: Michael Ellerman @ 2020-03-26 12:06 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: npiggin, dja
In-Reply-To: <20200320032116.1024773-1-mpe@ellerman.id.au>
On Fri, 2020-03-20 at 03:21:15 UTC, Michael Ellerman wrote:
> From: Daniel Axtens <dja@axtens.net>
>
> Currently we set up the paca after parsing the device tree for CPU
> features. Prior to that, r13 contains random data, which means there
> is random data in r13 while we're running the generic dt parsing code.
>
> This random data varies depending on whether we boot through a vmlinux
> or a zImage: for the vmlinux case it's usually around zero, but for
> zImages we see random values like 912a72603d420015.
>
> This is poor practice, and can also lead to difficult-to-debug
> crashes. For example, when kcov is enabled, the kcov instrumentation
> attempts to read preempt_count out of the current task, which goes via
> the paca. This then crashes in the zImage case.
>
> Similarly stack protector can cause crashes if r13 is bogus, by
> reading from the stack canary in the paca.
>
> To resolve this:
>
> - move the paca setup to before the CPU feature parsing.
>
> - because we no longer have access to CPU feature flags in paca
> setup, change the HV feature test in the paca setup path to consider
> the actual value of the MSR rather than the CPU feature.
>
> Translations get switched on once we leave early_setup, so I think
> we'd already catch any other cases where the paca or task aren't set
> up.
>
> Boot tested on a P9 guest and host.
>
> Fixes: fb0b0a73b223 ("powerpc: Enable kcov")
> Fixes: 06ec27aea9fc ("powerpc/64: add stack protector support")
> Cc: stable@vger.kernel.org # v4.20+
> Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
> Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Daniel Axtens <dja@axtens.net>
> [mpe: Reword comments & change log a bit to mention stack protector]
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Series applied to powerpc next.
https://git.kernel.org/powerpc/c/d4a8e98621543d5798421eed177978bf2b3cdd11
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: avoid harmless preempt warning
From: Michael Ellerman @ 2020-03-26 12:06 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20200320152436.1468651-1-npiggin@gmail.com>
On Fri, 2020-03-20 at 15:24:36 UTC, Nicholas Piggin wrote:
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/adde8715cf0571878d37fcb20595aad57b923bab
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/maple: Fix declaration made after definition
From: Michael Ellerman @ 2020-03-26 12:07 UTC (permalink / raw)
To: Nathan Chancellor, Benjamin Herrenschmidt, Paul Mackerras
Cc: Ilie Halip, Nick Desaulniers, linux-kernel, clang-built-linux,
Nathan Chancellor, linuxppc-dev
In-Reply-To: <20200323222729.15365-1-natechancellor@gmail.com>
On Mon, 2020-03-23 at 22:27:29 UTC, Nathan Chancellor wrote:
> When building ppc64 defconfig, Clang errors (trimmed for brevity):
>
> arch/powerpc/platforms/maple/setup.c:365:1: error: attribute declaration
> must precede definition [-Werror,-Wignored-attributes]
> machine_device_initcall(maple, maple_cpc925_edac_setup);
> ^
>
> machine_device_initcall expands to __define_machine_initcall, which in
> turn has the macro machine_is used in it, which declares mach_##name
> with an __attribute__((weak)). define_machine actually defines
> mach_##name, which in this file happens before the declaration, hence
> the warning.
>
> To fix this, move define_machine after machine_device_initcall so that
> the declaration occurs before the definition, which matches how
> machine_device_initcall and define_machine work throughout arch/powerpc.
>
> While we're here, remove some spaces before tabs.
>
> Fixes: 8f101a051ef0 ("edac: cpc925 MC platform device setup")
> Link: https://godbolt.org/z/kDoYSA
> Link: https://github.com/ClangBuiltLinux/linux/issues/662
> Reported-by: Nick Desaulniers <ndesaulniers@google.com>
> Suggested-by: Ilie Halip <ilie.halip@gmail.com>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/af6cf95c4d003fccd6c2ecc99a598fb854b537e7
cheers
^ permalink raw reply
* Re: [PATCHv2] selftests/powerpc: Turn off timeout setting for benchmarks, dscr, signal, tm
From: Michael Ellerman @ 2020-03-26 12:06 UTC (permalink / raw)
To: Po-Hsu Lin, linux-kselftest; +Cc: paulus, shuah, linuxppc-dev, linux-kernel
In-Reply-To: <20200318060004.10685-1-po-hsu.lin@canonical.com>
On Wed, 2020-03-18 at 06:00:04 UTC, Po-Hsu Lin wrote:
> Some specific tests in powerpc can take longer than the default 45
> seconds that added in commit 852c8cbf34d3 ("selftests/kselftest/runner.sh:
> Add 45 second timeout per test") to run, the following test result was
> collected across 2 Power8 nodes and 1 Power9 node in our pool:
> powerpc/benchmarks/futex_bench - 52s
> powerpc/dscr/dscr_sysfs_test - 116s
> powerpc/signal/signal_fuzzer - 88s
> powerpc/tm/tm_unavailable_test - 168s
> powerpc/tm/tm-poison - 240s
>
> Thus they will fail with TIMEOUT error. Disable the timeout setting
> for these sub-tests to allow them finish properly.
>
> https://bugs.launchpad.net/bugs/1864642
> Fixes: 852c8cbf34d3 ("selftests/kselftest/runner.sh: Add 45 second timeout per test")
> Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/850507f30c38dff21ed557cb98ab16db26c32bbc
cheers
^ permalink raw reply
* Re: [PATCH] cpufreq: powernv: Fix frame-size-overflow in powernv_cpufreq_work_fn
From: Michael Ellerman @ 2020-03-26 12:06 UTC (permalink / raw)
To: Pratik Rajesh Sampat, linux-pm, linuxppc-dev, linux-kernel,
psampat, pratik.r.sampat, ego, dja
In-Reply-To: <20200316135743.57735-1-psampat@linux.ibm.com>
On Mon, 2020-03-16 at 13:57:43 UTC, Pratik Rajesh Sampat wrote:
> The patch avoids allocating cpufreq_policy on stack hence fixing frame
> size overflow in 'powernv_cpufreq_work_fn'
>
> Fixes: 227942809b52 ("cpufreq: powernv: Restore cpu frequency to policy->cur on unthrottling")
> Signed-off-by: Pratik Rajesh Sampat <psampat@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/d95fe371ecd28901f11256c610b988ed44e36ee2
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/book3s/hash64/devmap: Use H_PAGE_THP_HUGE when setting up huge devmap pte entries
From: Michael Ellerman @ 2020-03-26 12:06 UTC (permalink / raw)
To: Aneesh Kumar K.V, linuxppc-dev; +Cc: Aneesh Kumar K.V, oohall
In-Reply-To: <20200313094842.351830-1-aneesh.kumar@linux.ibm.com>
On Fri, 2020-03-13 at 09:48:42 UTC, "Aneesh Kumar K.V" wrote:
> H_PAGE_THP_HUGE is used to differentiate between a THP hugepage and hugetlb
> hugepage entries. The difference is w.r.t how we handle hash fault on these
> address. THP address enables MPSS in segments. We want to manage devmap hugepage
> entries similar to THP pt entries. Hence use H_PAGE_THP_HUGE for devmap huge pte
> entries.
>
> With current code while handling hash pte fault, we do set is_thp = true when
> finding devmap pte huge pte entries.
>
> Current code also does the below sequence we setting up huge devmap entries.
> entry = pmd_mkhuge(pfn_t_pmd(pfn, prot));
> if (pfn_t_devmap(pfn))
> entry = pmd_mkdevmap(entry);
>
> In that case we would find both H_PAGE_THP_HUGE and PAGE_DEVMAP set for huge
> devmap pte entries. This results in false positive error like below.
>
> kernel BUG at /home/kvaneesh/src/linux/mm/memory.c:4321!
> Oops: Exception in kernel mode, sig: 5 [#1]
> LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
> Modules linked in:
> CPU: 56 PID: 67996 Comm: t_mmap_dio Not tainted 5.6.0-rc4-59640-g371c804dedbc #128
> ....
> NIP [c00000000044c9e4] __follow_pte_pmd+0x264/0x900
> LR [c0000000005d45f8] dax_writeback_one+0x1a8/0x740
> Call Trace:
> [c000000c6e9f38c0] [c0000000013f4130] str_spec.74809+0x22ffb4/0x2d116c (unreliable)
> [c000000c6e9f3960] [c0000000005d45f8] dax_writeback_one+0x1a8/0x740
> [c000000c6e9f3a40] [c0000000005d4dfc] dax_writeback_mapping_range+0x26c/0x700
> [c000000c6e9f3b30] [c000000000666580] ext4_dax_writepages+0x150/0x5a0
> [c000000c6e9f3ba0] [c0000000003fe278] do_writepages+0x68/0x180
> [c000000c6e9f3c10] [c0000000003ecc58] __filemap_fdatawrite_range+0x138/0x180
> [c000000c6e9f3cc0] [c0000000003ede74] file_write_and_wait_range+0xa4/0x110
> [c000000c6e9f3d10] [c0000000006552d0] ext4_sync_file+0x370/0x6e0
> [c000000c6e9f3d70] [c00000000057d330] vfs_fsync_range+0x70/0xf0
> [c000000c6e9f3db0] [c00000000046a000] sys_msync+0x220/0x2e0
> [c000000c6e9f3e20] [c00000000000b478] system_call+0x5c/0x68
> Instruction dump:
> 7a941564 392affff 7fbffc36 7a94f082 7d2907b4 78f4f00e 7fff4838 7bff1f24
> 7e54f82a 7e74fa14 724900a0 40820410 <0b080000> 72490040 418201c8 2fb7000
>
> This is because our pmd_trans_huge check doesn't exclude _PAGE_DEVMAP.
>
> To make this all consistent, update pmd_mkdevmap to set H_PAGE_THP_HUGE and
> pmd_trans_huge check now excludes _PAGE_DEVMAP correctly.
>
> Fixes: ebd31197931d ("powerpc/mm: Add devmap support for ppc64")
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/36b78402d97a3b9aeab136feb9b00d8647ec2c20
cheers
^ permalink raw reply
* Re: [PATCH -next] PCI: rpaphp: remove set but not used variable 'value'
From: Michael Ellerman @ 2020-03-26 12:06 UTC (permalink / raw)
To: Chen Zhou, paulus, tyreld, bhelgaas
Cc: chenzhou10, linux-pci, linuxppc-dev, linux-kernel
In-Reply-To: <20200312140412.32373-1-chenzhou10@huawei.com>
On Thu, 2020-03-12 at 14:04:12 UTC, Chen Zhou wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/pci/hotplug/rpaphp_core.c: In function is_php_type:
> drivers/pci/hotplug/rpaphp_core.c:291:16: warning:
> variable value set but not used [-Wunused-but-set-variable]
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/9475af081ec1fb6cc794a17ae90f2c01aa8a7993
cheers
^ permalink raw reply
* Re: [PATCH kernel] powerpc/prom_init: Pass the "os-term" message to hypervisor
From: Michael Ellerman @ 2020-03-26 12:06 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev
Cc: Alexey Kardashevskiy, Ram Pai, kvm-ppc, Thiago Jung Bauermann,
David Gibson
In-Reply-To: <20200312074404.87293-1-aik@ozlabs.ru>
On Thu, 2020-03-12 at 07:44:04 UTC, Alexey Kardashevskiy wrote:
> The "os-term" RTAS calls has one argument with a message address of
> OS termination cause. rtas_os_term() already passes it but the recently
> added prom_init's version of that missed it; it also does not fill args
> correctly.
>
> This passes the message address and initializes the number of arguments.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/74bb84e5117146fa73eb9d01305975c53022b3c3
cheers
^ permalink raw reply
* Re: [PATCH v4] powerpc: Replace setup_irq() by request_irq()
From: Michael Ellerman @ 2020-03-26 12:06 UTC (permalink / raw)
To: afzal mohammed, linuxppc-dev, linux-kernel
Cc: Scott Wood, afzal mohammed, Paul Mackerras
In-Reply-To: <20200312064256.18735-1-afzal.mohd.ma@gmail.com>
On Thu, 2020-03-12 at 06:42:55 UTC, afzal mohammed wrote:
> request_irq() is preferred over setup_irq(). Invocations of setup_irq()
> occur after memory allocators are ready.
>
> Per tglx[1], setup_irq() existed in olden days when allocators were not
> ready by the time early interrupts were initialized.
>
> Hence replace setup_irq() by request_irq().
>
> [1] https://lkml.kernel.org/r/alpine.DEB.2.20.1710191609480.1971@nanos
>
> Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/b4f00d5b2098320a0d4c4a6d31099bc0c9a85b02
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc test_emulate_step: fix DS operand in ld encoding to appropriate value
From: Michael Ellerman @ 2020-03-26 12:06 UTC (permalink / raw)
To: Balamuruhan S
Cc: ravi.bangoria, jniethe5, Balamuruhan S, paulus, sandipan,
naveen.n.rao, linuxppc-dev
In-Reply-To: <20200311102405.392263-1-bala24@linux.ibm.com>
On Wed, 2020-03-11 at 10:24:05 UTC, Balamuruhan S wrote:
> ld instruction should have 14 bit immediate field (DS) concatenated with
> 0b00 on the right, encode it accordingly. Introduce macro `IMM_DS()`
> to encode DS form instructions with 14 bit immediate field.
>
> Fixes: 4ceae137bdab ("powerpc: emulate_step() tests for load/store instructions")
> Reviewed-by: Sandipan Das <sandipan@linux.ibm.com>
> Signed-off-by: Balamuruhan S <bala24@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/3e74a0e16342626511c43937c120beb990539307
cheers
^ permalink raw reply
* Re: [PATCH -next 017/491] CELL BROADBAND ENGINE ARCHITECTURE: Use fallthrough;
From: Michael Ellerman @ 2020-03-26 12:06 UTC (permalink / raw)
To: Joe Perches, Jeremy Kerr
Cc: linuxppc-dev, Paul Mackerras, linux-kernel, Arnd Bergmann
In-Reply-To: <03073a9a269010ca439e9e658629c44602b0cc9f.1583896348.git.joe@perches.com>
On Wed, 2020-03-11 at 04:51:31 UTC, Joe Perches wrote:
> Convert the various uses of fallthrough comments to fallthrough;
>
> Done via script
> Link: https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git.joe.com/
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/addf3727ad28bd159ae2da433b48daf2ffb339f7
cheers
^ permalink raw reply
* Re: [PATCH v3] powerpc/32s: reorder Linux PTE bits to better match Hash PTE bits.
From: Michael Ellerman @ 2020-03-26 12:06 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <c4d6c18a7f8d9d3b899bc492f55fbc40ef38896a.1583861325.git.christophe.leroy@c-s.fr>
On Tue, 2020-03-10 at 17:29:12 UTC, Christophe Leroy wrote:
> Reorder Linux PTE bits to (almost) match Hash PTE bits.
>
> RW Kernel : PP = 00
> RO Kernel : PP = 00
> RW User : PP = 01
> RO User : PP = 11
>
> So naturally, we should have
> _PAGE_USER = 0x001
> _PAGE_RW = 0x002
>
> Today 0x001 and 0x002 and _PAGE_PRESENT and _PAGE_HASHPTE which
> both are software only bits.
>
> Switch _PAGE_USER and _PAGE_PRESET
> Switch _PAGE_RW and _PAGE_HASHPTE
>
> This allows to remove a few insns.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/697ece78f8f749aeea40f2711389901f0974017a
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: fix of_read_drc_info_cell() to point at next record
From: Michael Ellerman @ 2020-03-26 12:06 UTC (permalink / raw)
To: Tyrel Datwyler; +Cc: Tyrel Datwyler, mwb, msuchanek, linuxppc-dev
In-Reply-To: <20200307024547.5748-1-tyreld@linux.ibm.com>
On Sat, 2020-03-07 at 02:45:47 UTC, Tyrel Datwyler wrote:
> The expectation is that when calling of_read_drc_info_cell()
> repeatedly to parse multiple drc-info records that the in/out curval
> parameter points at the start of the next record on return. However,
> the current behavior has curval still pointing at the final value of
> the record just parsed. The result of which is that if the
> ibm,drc-info property contains multiple properties the parsed value
> of the drc_type for any record after the first has the power_domain
> value of the previous record appended to the type string.
>
> Ex: observed the following 0xffffffff prepended to PHB
>
> [ 69.485037] drc-info: type: \xff\xff\xff\xffPHB, prefix: PHB , index_start: 0x20000001
> [ 69.485038] drc-info: suffix_start: 1, sequential_elems: 3072, sequential_inc: 1
> [ 69.485038] drc-info: power-domain: 0xffffffff, last_index: 0x20000c00
>
> Fix by incrementing curval past the power_domain value to point at
> drc_type string of next record.
>
> Fixes: a29396653b8bf ("pseries/drc-info: Search DRC properties for CPU indexes")
> Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/c5e76fa05b2df519b9f08571cc57e623c1569faa
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/kasan: Fix kasan_remap_early_shadow_ro()
From: Michael Ellerman @ 2020-03-26 12:06 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4e7b56865e01569058914c991143f5961b5d4719.1583507333.git.christophe.leroy@c-s.fr>
On Fri, 2020-03-06 at 15:09:40 UTC, Christophe Leroy wrote:
> At the moment kasan_remap_early_shadow_ro() does nothing, because
> k_end is 0 and k_cur < 0 is always true.
>
> Change the test to k_cur != k_end, as done in
> kasan_init_shadow_page_tables()
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Fixes: cbd18991e24f ("powerpc/mm: Fix an Oops in kasan_mmu_init()")
> Cc: stable@vger.kernel.org
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/af92bad615be75c6c0d1b1c5b48178360250a187
cheers
^ permalink raw reply
* Re: [PATCH v2 1/6] powerpc/eeh: Add sysfs files in late probe
From: Michael Ellerman @ 2020-03-26 12:06 UTC (permalink / raw)
To: Oliver O'Halloran, linuxppc-dev; +Cc: Sam Bobroff, Oliver O'Halloran
In-Reply-To: <20200306073904.4737-1-oohall@gmail.com>
On Fri, 2020-03-06 at 07:38:59 UTC, Oliver O'Halloran wrote:
> Move creating the EEH specific sysfs files into eeh_add_device_late()
> rather than being open-coded all over the place. Calling the function is
> generally done immediately after calling eeh_add_device_late() anyway. This
> is also a correctness fix since currently the sysfs files will be added
> even if the EEH probe happens to fail.
>
> Similarly, on pseries we currently add the sysfs files before calling
> eeh_add_device_late(). This is flat-out broken since the sysfs files
> require the pci_dev->dev.archdata.edev pointer to be set, and that is done
> in eeh_add_device_late().
>
> Reviewed-by: Sam Bobroff <sbobroff@linux.ibm.com>
> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/8645aaa87963439007773ed8862ae6a29ea15eae
cheers
^ permalink raw reply
* Re: [PATCH] selftests/powerpc: Add a test of sigreturn vs VDSO
From: Michael Ellerman @ 2020-03-26 12:06 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20200304110402.6038-1-mpe@ellerman.id.au>
On Wed, 2020-03-04 at 11:04:02 UTC, Michael Ellerman wrote:
> There's two different paths through the sigreturn code, depending on
> whether the VDSO is mapped or not. We recently discovered a bug in the
> unmapped case, because it's not commonly used these days.
>
> So add a test that sends itself a signal, then moves the VDSO, takes
> another signal and finally unmaps the VDSO before sending itself
> another signal. That tests the standard signal path, the code that
> handles the VDSO being moved, and also the signal path in the case
> where the VDSO is unmapped.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/a0968a025c04702427a4aee2c618f451a5098cd8
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/kuap: PPC_KUAP_DEBUG should depend on PPC_KUAP
From: Michael Ellerman @ 2020-03-26 12:06 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20200301111738.22497-1-mpe@ellerman.id.au>
On Sun, 2020-03-01 at 11:17:38 UTC, Michael Ellerman wrote:
> Currently you can enable PPC_KUAP_DEBUG when PPC_KUAP is disabled,
> even though the former has not effect without the latter.
>
> Fix it so that PPC_KUAP_DEBUG can only be enabled when PPC_KUAP is
> enabled, not when the platform could support KUAP (PPC_HAVE_KUAP).
>
> Fixes: 890274c2dc4c ("powerpc/64s: Implement KUAP for Radix MMU")
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/61da50b76b62fd815aa82d853bf82bf4f69568f5
cheers
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox