arch/powerpc/mm/init_64.c: In function 'vmemmap_free':
arch/powerpc/mm/init_64.c:277:16: error: variable 'section_base' set but
not used [-Werror=unused-but-set-variable]
Signed-off-by: Qian Cai
---
arch/powerpc/mm/init_64.c | 2 --
1 file changed, 2 deletions(-)
diff --g
arch/powerpc/mm/hugetlbpage-hash64.c: In function '__hash_page_huge':
arch/powerpc/mm/hugetlbpage-hash64.c:29:28: warning: variable 'sz' set
but not used [-Wunused-but-set-variable]
Signed-off-by: Qian Cai
---
arch/powerpc/mm/hugetlbpage-hash64.c | 3 +--
1 file change
t_64.c:277:16: error: variable 'section_base' set but
not used [-Werror=unused-but-set-variable]
Signed-off-by: Qian Cai
---
v2: improve the commit message.
arch/powerpc/mm/init_64.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
in
variable 'orig_pte' set but not used
[-Wunused-but-set-variable]
mm/swap_state.c: In function 'swap_ra_info':
mm/swap_state.c:634:15: warning: variable 'orig_pte' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Qian Cai
---
arch/powerpc/include/asm/bo
wap_ra_info':
mm/swap_state.c:634:15: warning: variable 'orig_pte' set but not used
[-Wunused-but-set-variable]
Suggested-by: Christophe Leroy
Signed-off-by: Qian Cai
---
v2: make it a static inline function.
arch/powerpc/include/asm/book3s/64/pgtable.h | 3 ++-
arch/powerpc/includ
0 6000 3bff0008 7fbcf840
409d00b8 4bfffeed 2fa3 409e00ac e93e0128 7fa91840
419dffdc
Signed-off-by: Qian Cai
---
arch/powerpc/kernel/kvm.c | 3 +++
include/linux/kmemleak.h | 4
mm/kmemleak.c | 25 -
3 files changed, 31 insertions(+), 1 deletio
Fixing some email addresses.
On Tue, 2019-03-12 at 15:14 -0400, Qian Cai wrote:
> The commit 2d4f567103ff ("KVM: PPC: Introduce kvm_tmp framework") adds
> kvm_tmp[] into the .bss section and then free the rest of unused spaces
> back to the page allocator.
>
> kerne
0 6000 6000 3bff0008 7fbcf840
409d00b8 4bfffeed 2fa3 409e00ac e93e0128 7fa91840
419dffdc
Signed-off-by: Qian Cai
---
v2: make the function __init per Andrew.
arch/powerpc/kernel/kvm.c | 3 +++
include/linux/kmemleak.h | 4
mm/kmemleak.c | 25
wap_ra_info':
mm/swap_state.c:634:15: warning: variable 'orig_pte' set but not used
[-Wunused-but-set-variable]
Suggested-by: Christophe Leroy
Reviewed-by:: Christophe Leroy
Signed-off-by: Qian Cai
---
v2: make it a static inline function.
arch/powerpc/include/asm/book3s/64/pgta
On 3/19/19 5:21 AM, Christophe Leroy wrote:
> Is there a reason for resending ? AFAICS, both are identical and still marked
> new in patchwork:
> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?submitter=76055
>
"RESEND" because of no maintainer response for more than one week.
> Inde
On Wed, 2019-03-20 at 18:16 +, Catalin Marinas wrote:
> I think I have a simpler idea. Kmemleak allows punching holes in
> allocated objects, so just turn the data/bss sections into dedicated
> kmemleak objects. This happens when kmemleak is initialised, before the
> initcalls are invoked. The
ed pages.
>
> This patch creates dedicated kmemleak objects for the .data, .bss and
> potentially .data..ro_after_init sections to allow partial freeing via
> the kmemleak_free_part() in the powerpc kvm_free_tmp() function.
>
> Acked-by: Michael Ellerman (powerpc)
> Reported-by: Qian Cai
> Signed-off-by: Catalin Marinas
Tested-by: Qian Cai
Ping. The patchwork status is still New after a month.
On 3/7/19 9:40 AM, Qian Cai wrote:
> pte_unmap() compiles away on some powerpc platforms, so silence the
> warnings below by making it a static inline function.
>
> mm/memory.c: In function 'copy_pte_range':
> mm
iable 'count'
set but not used [-Wunused-but-set-variable]
Signed-off-by: Qian Cai
---
arch/powerpc/platforms/pseries/pmem.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/pmem.c
b/arch/powerpc/platforms/pseries/pmem.c
index 27f0
7;:
arch/powerpc/platforms/pseries/iommu.c:948:7: warning: variable 'ranges'
set but not used [-Wunused-but-set-variable]
int ranges, n_mem_addr_cells, n_mem_size_cells, len;
^~
Signed-off-by: Qian Cai
---
arch/powerpc/platforms/pseries/iommu.c | 13 +
1 file cha
On Wed, 2020-02-26 at 10:51 -0500, Qian Cai wrote:
> On Wed, 2020-02-26 at 15:45 +0100, Christophe Leroy wrote:
> >
> > Le 26/02/2020 à 15:09, Qian Cai a écrit :
> > > On Mon, 2020-02-17 at 08:47 +0530, Anshuman Khandual wrote:
> > > > This adds tests which w
> Below is slightly modified version of your change above and should still
> prevent the bug on powerpc. Will it be possible for you to re-test this
> ? Once confirmed, will send a patch enabling this test on powerpc64
> keeping your authorship. Thank you.
This works fine on radix MMU but I deci
> On Mar 4, 2020, at 1:49 AM, Christophe Leroy wrote:
>
> AFAIU, you are not taking an interrupt here. You are stuck in the
> pte_update(), most likely due to nested locks. Try with LOCKDEP ?
Not exactly sure what did you mean here, but the kernel has all lockdep enabled
and did not flag an
282
(inlined by) walk_pagetables at arch/powerpc/mm/ptdump/ptdump.c:311
ptdump_check_wx+0x8c/0xf0
mark_rodata_ro+0x48/0x80
kernel_init+0x74/0x194
ret_from_kernel_thread+0x5c/0x74
Fixes: 8eb07b187000 ("powerpc/mm: Dump linux pagetables")
Signed-off-by: Qian Cai
---
Notes for maintainers:
This
bles+0x2cc/0x700
walk_pud at arch/powerpc/mm/ptdump/ptdump.c:282
(inlined by) walk_pagetables at arch/powerpc/mm/ptdump/ptdump.c:311
ptdump_check_wx+0x8c/0xf0
mark_rodata_ro+0x48/0x80
kernel_init+0x74/0x194
ret_from_kernel_thread+0x5c/0x74
Suggested-by: Christophe Leroy
Signed-off-by: Qia
c/0x700
walk_pud at arch/powerpc/mm/ptdump/ptdump.c:282
(inlined by) walk_pagetables at arch/powerpc/mm/ptdump/ptdump.c:311
ptdump_check_wx+0x8c/0xf0
mark_rodata_ro+0x48/0x80
kernel_init+0x74/0x194
ret_from_kernel_thread+0x5c/0x74
Suggested-by: Christophe Leroy
Signed-off-by: Qian Cai
---
v3: c
> On Mar 5, 2020, at 2:22 PM, Christophe Leroy wrote:
>
>
>
> Le 05/03/2020 à 15:32, Qian Cai a écrit :
>> Booting a power9 server with hash MMU could trigger an undefined
>> behaviour because pud_offset(p4d, 0) will do,
>> 0 >> (PAGE_SHIFT:16 +
On Fri, 2020-03-06 at 05:27 +0530, Anshuman Khandual wrote:
> This adds tests which will validate architecture page table helpers and
> other accessors in their compliance with expected generic MM semantics.
> This will help various architectures in validating changes to existing
> page table helpe
> On Mar 6, 2020, at 7:03 PM, Anshuman Khandual
> wrote:
>
> Hmm, set_pte_at() function is not preferred here for these tests. The idea
> is to avoid or atleast minimize TLB/cache flushes triggered from these sort
> of 'static' tests. set_pte_at() is platform provided and could/might trigger
> On Mar 6, 2020, at 7:56 PM, Anshuman Khandual
> wrote:
>
>
>
> On 03/07/2020 06:04 AM, Qian Cai wrote:
>>
>>
>>> On Mar 6, 2020, at 7:03 PM, Anshuman Khandual
>>> wrote:
>>>
>>> Hmm, set_pte_at() function is not p
> On Mar 24, 2020, at 4:06 PM, Chris Packham
> wrote:
>
> On Tue, 2020-03-24 at 15:47 +1100, Michael Ellerman wrote:
>> Chris Packham writes:
>>> Hi All,
>>>
>>> Just booting up v5.5.11 on a Freescale T2080RDB and I'm seeing the
>>> following mesage.
>>>
>>> kern.warning linuxbox kernel: A
+0x264/0x570
free_unref_page+0x38/0xf0
__mmdrop+0x21c/0x2c0
idle_task_exit+0x170/0x1b0
pnv_smp_cpu_kill_self+0x38/0x2e0
cpu_die+0x48/0x64
arch_cpu_idle_dead+0x30/0x50
do_idle+0x2f4/0x470
cpu_startup_entry+0x38/0x40
start_secondary+0x7a8/0xa80
start_secondary_resume+0x10/0x14
Signed-off-
> On Apr 2, 2020, at 7:24 AM, Michael Ellerman wrote:
>
> Qian Cai writes:
>> From: Peter Zijlstra
>>
>> In the CPU-offline process, it calls mmdrop() after idle entry and the
>> subsequent call to cpuhp_report_idle_dead(). Once execution passes the
>
> On Apr 2, 2020, at 11:54 AM, Paul E. McKenney wrote:
>
> I do run this combination quite frequently, but only as part of
> rcutorture, which might not be a representative workload. For one thing,
> it has a minimal userspace consisting only of a trivial init program.
> I don't recall having
ge_alloc_init_late() per Michal and Qian
> - Updated the commit message per Michal
> - Updated W=1 GCC warning problem on x86 per Qian Cai
It would be interesting to know if you actually tested out to see if the
warning went away. As far I can tell, the GCC is quite stubborn there, so I am
not going to insist.
> On Oct 24, 2019, at 11:45 PM, Anshuman Khandual
> wrote:
>
> Nothing specific. But just tested this with x86 defconfig with relevant
> configs
> which are required for this test. Not sure if it involved W=1.
No, it will not. It needs to run like,
make W=1 -j 64 2>/tmp/warns
_dead+0x30/0x50
do_idle+0x2e4/0x460
cpu_startup_entry+0x3c/0x40
start_secondary+0x7a8/0xa80
start_secondary_resume+0x10/0x14
because it calls local_irq_disable() before arch_cpu_idle_dead().
Fixes: e78a7614f387 ("idle: Prevent late-arriving interrupts from disrupting
offline")
Sig
> On Oct 28, 2019, at 1:29 AM, Anshuman Khandual
> wrote:
>
> This adds tests which will validate architecture page table helpers and
> other accessors in their compliance with expected generic MM semantics.
> This will help various architectures in validating changes to existing
> page table
> On Oct 30, 2019, at 6:28 AM, Peter Zijlstra wrote:
>
> It only makes 'wild' guesses when the BIOS is shit and it complains
> about that.
>
> Or do you like you BIOS broken?
Agree. It is the garbage in and garbage out. No need to complicate the existing
code further.
On Tue, 2019-07-23 at 16:57 +0530, Anju T Sudhakar wrote:
> Hi Qian,
>
> On 7/16/19 12:11 AM, Qian Cai wrote:
> > On Thu, 2019-07-11 at 14:53 +1000, Michael Ellerman wrote:
> > > Hi Maddy,
> > >
> > > Madhavan Srinivasan writes:
> > > >
Still see those,
WARNING: vmlinux.o(.text+0x2d04): Section mismatch in reference from the
variable __boot_from_prom to the function .init.text:prom_init()
The function __boot_from_prom() references
the function __init prom_init().
This is often because __boot_from_prom lacks a __init
annotation or
On Thu, 2019-10-31 at 20:39 +1100, Daniel Axtens wrote:
> /*
>* In this function, newly allocated vm_struct has VM_UNINITIALIZED
>* flag. It means that vm_struct is not fully initialized.
> @@ -3377,6 +3411,9 @@ struct vm_struct **pcpu_get_vm_areas(const unsigned
> long *offs
# echo function >/sys/kernel/debug/tracing/current_tracer
It hangs forever with today's linux-next on powerpc. Reverted the conflict fix
[1] as below fixes the issue.
[1] https://lore.kernel.org/linux-next/20191115135357.10386...@canb.auug.org.au/
diff --git a/include/asm-generic/vmlinux.lds.h b
On Fri, 2019-11-15 at 16:02 -0500, Steven Rostedt wrote:
> On Fri, 15 Nov 2019 15:28:52 -0500
> Qian Cai wrote:
>
> > # echo function >/sys/kernel/debug/tracing/current_tracer
> >
> > It hangs forever with today's linux-next on powerpc. Reverted the conflict
On Mon, 2019-11-18 at 10:16 -0500, Steven Rostedt wrote:
> On Mon, 18 Nov 2019 09:58:42 -0500
> Steven Rostedt wrote:
>
> > On Mon, 18 Nov 2019 09:51:04 -0500
> > Steven Rostedt wrote:
> >
> > > > > Test this commit please: b83b43ffc6e4b514ca034a0fbdee01322e2f7022
> > > > >
> > > >
> >
> On Sep 4, 2019, at 11:55 PM, Michael Ellerman wrote:
>
> Bart Van Assche writes:
>> On 8/30/19 2:13 PM, Qian Cai wrote:
>>> https://raw.githubusercontent.com/cailca/linux-mm/master/powerpc.config
>>>
>>> Once in a while, booting an IBM POWER9 Pow
> On Nov 29, 2019, at 7:29 AM, Daniel Axtens wrote:
>
Nope, it's vm_map_ram() not being handled
>>>
>>>
>>> Another suspicious one. Related to kasan/vmalloc?
>>
>> Very likely the same as with ion:
>>
>> # git grep vm_map_ram|grep xfs
>> fs/xfs/xfs_buf.c:* vm_map
Ever since 1st Apr, linux-next starts to trigger a NULL pointer NIP on POWER9
below using
this config,
https://raw.githubusercontent.com/cailca/linux-mm/master/powerpc.config
It takes a while to reproduce, so before I bury myself into bisecting and just
send a head-up
to see if anyone spots any
+ Steven
> On Apr 7, 2020, at 8:42 AM, Michael Ellerman wrote:
>
> Qian Cai writes:
>> Ever since 1st Apr, linux-next starts to trigger a NULL pointer NIP on
>> POWER9 below using
>> this config,
>>
>> https://raw.githubusercontent.com/cailca/linux-mm/
> On Apr 7, 2020, at 9:30 AM, Steven Rostedt wrote:
>
> On Tue, 7 Apr 2020 09:01:10 -0400
> Qian Cai wrote:
>
>> + Steven
>>
>>> On Apr 7, 2020, at 8:42 AM, Michael Ellerman wrote:
>>>
>>> Qian Cai writes:
>>>> Ever
> On Apr 7, 2020, at 9:30 AM, Steven Rostedt wrote:
>
> On Tue, 7 Apr 2020 09:01:10 -0400
> Qian Cai wrote:
>
>> + Steven
>>
>>> On Apr 7, 2020, at 8:42 AM, Michael Ellerman wrote:
>>>
>>> Qian Cai writes:
>>>> Ever
> On Apr 9, 2020, at 10:14 AM, Steven Rostedt wrote:
>
> On Thu, 9 Apr 2020 06:06:35 -0400
> Qian Cai wrote:
>
>>>> I’ll go to bisect some more but it is going to take a while.
>>>>
>>>> $ git log --oneline 4c205c84e249..8e99cf91b99b
&
> On Apr 10, 2020, at 3:20 PM, Qian Cai wrote:
>
>
>
>> On Apr 9, 2020, at 10:14 AM, Steven Rostedt wrote:
>>
>> On Thu, 9 Apr 2020 06:06:35 -0400
>> Qian Cai wrote:
>>
>>>>> I’ll go to bisect some more but it is going to ta
OK, reverted the commit,
c55d7b5e6426 (“powerpc: Remove STRICT_KERNEL_RWX incompatibility with
RELOCATABLE”)
or set STRICT_KERNEL_RWX=n fixed the crash below and also mentioned in this
thread,
https://lore.kernel.org/lkml/15ac5b0e-a221-4b8c-9039-fa96b8ef7...@lca.pw/
[ 148.110969][T13115] LTP
> On Apr 16, 2020, at 10:27 PM, Russell Currey wrote:
>
> Reverting the patch with the given config will have the same effect as
> STRICT_KERNEL_RWX=n. Not discounting that it could be a bug on the
> powerpc side (i.e. relocatable kernels with strict RWX on haven't been
> exhaustively tested
> On Apr 16, 2020, at 10:46 PM, Russell Currey wrote:
>
> On Thu, 2020-04-16 at 22:40 -0400, Qian Cai wrote:
>>> On Apr 16, 2020, at 10:27 PM, Russell Currey
>>> wrote:
>>>
>>> Reverting the patch with the given config will have the sam
> On Apr 16, 2020, at 10:46 PM, Russell Currey wrote:
>
> On Thu, 2020-04-16 at 22:40 -0400, Qian Cai wrote:
>>> On Apr 16, 2020, at 10:27 PM, Russell Currey
>>> wrote:
>>>
>>> Reverting the patch with the given config will have the sam
> On Apr 17, 2020, at 3:01 AM, Naveen N. Rao wrote:
>
> Hi Qian,
>
> Qian Cai wrote:
>> OK, reverted the commit,
>> c55d7b5e6426 (“powerpc: Remove STRICT_KERNEL_RWX incompatibility with
>> RELOCATABLE”)
>> or set STRICT_KERNEL_RWX=n fixed the
> On Apr 2, 2020, at 7:24 AM, Michael Ellerman wrote:
>
> Qian Cai writes:
>> From: Peter Zijlstra
>>
>> In the CPU-offline process, it calls mmdrop() after idle entry and the
>> subsequent call to cpuhp_report_idle_dead(). Once execution passes the
>
> On Apr 12, 2020, at 3:48 PM, Mike Rapoport wrote:
>
> From: Baoquan He
>
> When called during boot the memmap_init_zone() function checks if each PFN
> is valid and actually belongs to the node being initialized using
> early_pfn_valid() and early_pfn_in_nid().
>
> Each such check may cos
> On Apr 17, 2020, at 2:50 PM, Mike Kravetz wrote:
>
> Longpeng(Mike) reported a weird message from hugetlb command line processing
> and proposed a solution [1]. While the proposed patch does address the
> specific issue, there are other related issues in command line processing.
> As hugetl
V
> _mcount() stub
> [uses kernel TOC -> random entry]
>
> To address this, let's change over to using the special stub that is
> used for ftrace_[regs_]caller() for _mcount(). This ensures that we are
> not dependent on a valid module TOC in r2 for default _mcount()
> handling.
>
> Reported-by: Qian Cai
> Signed-off-by: Naveen N. Rao
Feel free to add,
Tested-by: Qian Cai
Booting POWER9 PowerNV has this message,
"ioremap() called early from pnv_pci_init_ioda_phb+0x420/0xdfc. Use
early_ioremap() instead”
but use the patch below will result in leaks because it will never call
early_iounmap() anywhere. However, it looks me it was by design that phb->regs
mapp
> On May 8, 2020, at 10:39 AM, Qian Cai wrote:
>
> Booting POWER9 PowerNV has this message,
>
> "ioremap() called early from pnv_pci_init_ioda_phb+0x420/0xdfc. Use
> early_ioremap() instead”
>
> but use the patch below will result in leaks because it wil
fc014>] kvm_arch_vcpu_ioctl+0x388/0x508 [kvm]
[<d25aea0f>] kvm_vcpu_ioctl+0x15c/0x950 [kvm]
[<48155cd6>] ksys_ioctl+0xd8/0x130
[<41ffeaa7>] sys_ioctl+0x28/0x40
[<4afc4310>] system_call_exception+0x114/0x1e0
[<000
> On Mar 6, 2020, at 1:56 AM, Christophe Leroy wrote:
>
>
>
> Le 06/03/2020 à 05:48, Qian Cai a écrit :
>> Booting a power9 server with hash MMU could trigger an undefined
>> behaviour because pud_offset(p4d, 0) will do,
>> 0 >> (PAGE_SHIFT:16 +
> On May 9, 2020, at 4:38 AM, Nicholas Piggin wrote:
>
> Your patch to use early_ioremap is faulting? I wonder why?
Yes, I don’t know the reasons either. I suppose not many places in other parts
of the kernel which keep using those addresses from early_ioremap() after
system booted. Otherwi
43128] sys_ioctl+0x28/0x40
[c010f29afdc0] [c0038af4] system_call_exception+0x114/0x1e0
[c010f29afe20] [c000c8f0] system_call_common+0xf0/0x278
Signed-off-by: Qian Cai
---
arch/powerpc/platforms/powernv/pci-ioda-tce.c | 4
1 file changed, 4 insertions(+)
diff --git a/a
-{0:0}, at:
kvmppc_h_put_tce+0x88/0x340 [kvm]
Signed-off-by: Qian Cai
---
arch/powerpc/mm/book3s64/iommu_api.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/book3s64/iommu_api.c
b/arch/powerpc/mm/book3s64/iommu_api.c
index fa05bbd1f682..bf010
at might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
1 lock held by qemu-kvm/4257:
#0: c000200b1b363a40 (&kv->lock){+.+.}-{3:3}, at:
kvm_vfio_set_attr+0x598/0x6c0 [kvm]
Signed-off-by: Qian Cai
---
arch/powerpc/kvm/book3s_64_vio.c | 19 +++
1 file changed, 15 i
> On May 11, 2020, at 7:15 AM, Michael Ellerman wrote:
>
> There is kmemleak_alloc_phys(), which according to the docs can be used
> for tracking a phys address.
>
> Did you try that?
Caitlin, feel free to give your thoughts here.
My understanding is that it seems the doc is a bit misleadin
Running some container workloads on an IBM power9 server with the latest
mainline (rc2) triggered this,
[ 1283.894167] Unable to handle kernel paging request for data at address
0xc1da
[ 1283.894215] Faulting instruction address: 0xc0487ab8
[ 1283.894223] Oops: Kernel access
On Thu, 2019-06-20 at 20:31 +0200, David Hildenbrand wrote:
> @Andrew: Only patch 1, 4 and 6 changed compared to v1.
>
> Some further cleanups around memory block devices. Especially, clean up
> and simplify walk_memory_range(). Including some other minor cleanups.
>
> Compiled + tested on x86 wi
On Fri, 2019-06-21 at 20:56 +0200, David Hildenbrand wrote:
> On 21.06.19 20:24, David Hildenbrand wrote:
> > On 21.06.19 17:15, Qian Cai wrote:
> > > On Thu, 2019-06-20 at 20:31 +0200, David Hildenbrand wrote:
> > > > @Andrew: Only patch 1, 4 and 6 changed compare
On Fri, 2019-06-21 at 20:24 +0200, David Hildenbrand wrote:
> On 21.06.19 17:15, Qian Cai wrote:
> > On Thu, 2019-06-20 at 20:31 +0200, David Hildenbrand wrote:
> > > @Andrew: Only patch 1, 4 and 6 changed compared to v1.
> > >
> > > Some further cleanups aro
Ping.
On Wed, 2019-06-05 at 16:53 -0400, Qian Cai wrote:
> At the beginning of setup_64.c, it has,
>
> #ifdef DEBUG
> #define DBG(fmt...) udbg_printf(fmt)
> #else
> #define DBG(fmt...)
> #endif
>
> where DBG() could be compiled away, and generate warning
Ping.
On Thu, 2019-06-06 at 09:58 -0400, Qian Cai wrote:
> The powerpc's flush_cache_vmap() is defined as a macro and never use
> both of its arguments, so it will generate a compilation warning,
>
> lib/ioremap.c: In function 'ioremap_page_range':
> lib/iorem
Ping.
On Wed, 2019-06-05 at 16:46 -0400, Qian Cai wrote:
> The opening comment mark "/**" is reserved for kernel-doc comments, so
> it will generate a warning with "make W=1".
>
> arch/powerpc/kernel/eeh_cache.c:37: warning: cannot understand function
> p
Read of debugfs imc_cmd file for a memory-less node will trigger a crash below
on this power9 machine which has the following NUMA layout. I don't understand
why I only saw it recently on linux-next where it was tested everyday. I can
reproduce it back to 4.20 where 4.18 seems work fine.
# cat /sy
> On Jun 27, 2019, at 11:12 PM, Michael Ellerman wrote:
>
> Qian Cai writes:
>> Read of debugfs imc_cmd file for a memory-less node will trigger a crash
>> below
>> on this power9 machine which has the following NUMA layout.
>
> What type of machine is
On Fri, 2019-06-28 at 17:19 +0530, Anju T Sudhakar wrote:
> On 6/28/19 9:04 AM, Qian Cai wrote:
> >
> > > On Jun 27, 2019, at 11:12 PM, Michael Ellerman
> > > wrote:
> > >
> > > Qian Cai writes:
> > > > Read of debugfs imc_cmd file
in an 'if' statement [-Wempty-body]
DBG("Argh, can't find icache properties !\n");
Fix it by using the no_printk() macro, and make sure that format and
argument are always verified by the compiler.
Suggested-by: Tyrel Datwyler
Suggested-by: Joe Perches
Signed-off
Ping.
On Wed, 2019-05-22 at 12:09 -0400, Qian Cai wrote:
> The commit b575c731fe58 ("powerpc/powernv/npu: Add set/unset window
> helpers") called pnv_npu_set_window() in a void function
> pnv_npu_dma_set_32(), but the return code from pnv_npu_set_window() has
> no use
Ping.
On Fri, 2019-06-28 at 10:03 -0400, Qian Cai wrote:
> At the beginning of setup_64.c, it has,
>
> #ifdef DEBUG
> #define DBG(fmt...) udbg_printf(fmt)
> #else
> #define DBG(fmt...)
> #endif
>
> where DBG() could be compiled away, and generate warning
dbg_putc is NULL, then we could just
call udbg_printf() unconditionally and get rid of the DBG macro
entirely."
Suggested-by: Michael Ellerman
Signed-off-by: Qian Cai
---
v4: Use the suggestions from Michael and __func__ per checkpatch.
v3: Use no_printk() macro, and make sure that forma
On Thu, 2019-07-11 at 14:53 +1000, Michael Ellerman wrote:
> Hi Maddy,
>
> Madhavan Srinivasan writes:
> > diff --git a/arch/powerpc/platforms/powernv/opal-imc.c
> > b/arch/powerpc/platforms/powernv/opal-imc.c
> > index 186109bdd41b..e04b20625cb9 100644
> > --- a/arch/powerpc/platforms/powernv/op
The linux-next commit "ftrace: Rework event_create_dir()” [1] triggers boot
warnings
for Clang-build (Clang version 8.0.1) kernels (reproduced on both arm64 and
powerpc).
Reverted it (with trivial conflict fixes) on the top of today’s linux-next
fixed the issue.
configs:
https://raw.githubuserc
> On Dec 18, 2019, at 11:31 PM, Steven Rostedt wrote:
>
> On Wed, 18 Dec 2019 22:58:23 -0500
> Qian Cai wrote:
>
>> The linux-next commit "ftrace: Rework event_create_dir()” [1] triggers boot
>> warnings
>> for Clang-build (Clang version 8.0.1)
> On Dec 18, 2019, at 11:31 PM, Steven Rostedt wrote:
>
> On Wed, 18 Dec 2019 22:58:23 -0500
> Qian Cai wrote:
>
>> The linux-next commit "ftrace: Rework event_create_dir()” [1] triggers boot
>> warnings
>> for Clang-build (Clang version 8.0.1)
> On Jan 27, 2020, at 8:28 PM, Anshuman Khandual
> wrote:
>
> This adds tests which will validate architecture page table helpers and
> other accessors in their compliance with expected generic MM semantics.
> This will help various architectures in validating changes to existing
> page table
> On Jan 27, 2020, at 10:06 PM, Anshuman Khandual
> wrote:
>
>
>
> On 01/28/2020 07:41 AM, Qian Cai wrote:
>>
>>
>>> On Jan 27, 2020, at 8:28 PM, Anshuman Khandual
>>> wrote:
>>>
>>> This adds tests which will validat
> On Jan 27, 2020, at 11:58 PM, Anshuman Khandual
> wrote:
>
> As I had mentioned before, the test attempts to formalize page table helper
> semantics
> as expected from generic MM code paths and intend to catch deviations when
> enabled on
> a given platform. How else should we test semant
> On Jan 28, 2020, at 1:17 AM, Christophe Leroy wrote:
>
> It is 'default y' so there is no much risk that it is forgotten, at least all
> test suites run with 'allyes_defconfig' will trigger the test, so I think it
> is really a good feature.
This thing depends on DEBUG_VM which I don’t se
> On Jan 28, 2020, at 2:03 AM, Anshuman Khandual
> wrote:
>
> 'allyesconfig' makes 'DEBUG_VM = y' which in turn will enable
> 'DEBUG_VM_PGTABLE = y'
> on platforms that subscribe ARCH_HAS_DEBUG_VM_PGTABLE.
Isn’t that only for compiling testing? Who is booting such a beast and make
sure eve
> On Jan 28, 2020, at 1:13 AM, Christophe Leroy wrote:
>
> ppc32 an indecent / legacy platform ? Are you kidying ?
>
> Powerquicc II PRO for instance is fully supported by the manufacturer and
> widely used in many small networking devices.
Of course I forgot about embedded devices. The pro
> On Jan 28, 2020, at 7:10 AM, Mike Rapoport wrote:
>
> Aren't x86 and arm64 not decent enough?
> Even if this test could be used to detect regressions only on these two
> platforms, the test is valuable.
The question is does it detect regressions good enough? Where is the list of
past bugs
> On Jan 28, 2020, at 12:47 PM, Catalin Marinas wrote:
>
> The primary goal here is not finding regressions but having clearly
> defined semantics of the page table accessors across architectures. x86
> and arm64 are a good starting point and other architectures will be
> enabled as they are a
> On Jan 29, 2020, at 5:36 AM, Catalin Marinas wrote:
>
> On Tue, Jan 28, 2020 at 02:07:10PM -0500, Qian Cai wrote:
>> On Jan 28, 2020, at 12:47 PM, Catalin Marinas
>> wrote:
>>> The primary goal here is not finding regressions but having clearly
>>&
> On Jan 30, 2020, at 9:13 AM, Christophe Leroy wrote:
>
> config DEBUG_VM_PGTABLE
>bool "Debug arch page table for semantics compliance" if
> ARCH_HAS_DEBUG_VM_PGTABLE || EXPERT
>depends on MMU
>default 'n' if !ARCH_HAS_DEBUG_VM_PGTABLE
>default 'y' if DEBUG_VM
Does it reall
On Mon, 2020-02-03 at 16:14 +0100, Christophe Leroy wrote:
>
> Le 02/02/2020 à 12:26, Qian Cai a écrit :
> >
> >
> > > On Jan 30, 2020, at 9:13 AM, Christophe Leroy
> > > wrote:
> > >
> > > config DEBUG_VM_PGTABLE
> > &g
ormation message in debug_vm_pgtable() per Christophe
> - Dropped random_vaddr boundary condition checks per Christophe and Qian
> - Replaced virt_addr_valid() check with pfn_valid() check in
> debug_vm_pgtable()
> - Slightly changed pr_fmt(fmt) information
>
> Changes
On Wed, 2020-02-26 at 09:09 -0500, Qian Cai wrote:
> On Mon, 2020-02-17 at 08:47 +0530, Anshuman Khandual wrote:
> > This adds tests which will validate architecture page table helpers and
> > other accessors in their compliance with expected generic MM semantics.
> > T
On Wed, 2020-02-26 at 15:45 +0100, Christophe Leroy wrote:
>
> Le 26/02/2020 à 15:09, Qian Cai a écrit :
> > On Mon, 2020-02-17 at 08:47 +0530, Anshuman Khandual wrote:
> > > This adds tests which will validate architecture page table helpers and
> > > other acce
l) and radix root for kernel:
(ptrval)
Signed-off-by: Qian Cai
---
arch/powerpc/mm/book3s64/radix_pgtable.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c
b/arch/powerpc/mm/book3s64/radix_pgtable.c
index b4ca9e95e678..b6692ee9411d 100644
https://raw.githubusercontent.com/cailca/linux-mm/master/powerpc.config
Once in a while, booting an IBM POWER9 PowerNV system (8335-GTH) would generate
a warning in lockdep_register_key() at,
if (WARN_ON_ONCE(static_obj(key)))
because
key = 0xc19ad118
&_stext = 0xc000
&_end
1 - 100 of 155 matches
Mail list logo
