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
[-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/book3s/64/pgtable.h | 2 +-
arch/powerpc/include/asm/nohash/64/pgtable.h
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 --git a/arch/powerpc/mm
: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
index a5091c034747..a4
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 changed, 1 insertion(+), 2
'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/pgtable.h | 3 ++-
arch/powerpc/include/asm/nohash/64/pgtable.h | 3 ++-
2
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
'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/include/asm/nohash/64/pgtable.h | 3 ++-
2 files changed, 4 insertions(+), 2
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.
>
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
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
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
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 changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/pow
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/memory.c:
nt'
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 27f0a915c8a9..f860a897a9
ct below, but rather an
overview of this source eeh_cache.c, just use the free-form comments
kernel-doc syntax instead.
Signed-off-by: Qian Cai
---
arch/powerpc/kernel/eeh_cache.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/kernel/eeh_cache.c b/arch/powerpc/kernel/eeh_cache.
empty-body]
DBG("Argh, can't find icache properties !\n");
Signed-off-by: Qian Cai
---
arch/powerpc/kernel/setup_64.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 44b4c432a273.
it an inline function.
Signed-off-by: Qian Cai
---
arch/powerpc/include/asm/cacheflush.h | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/cacheflush.h
b/arch/powerpc/include/asm/cacheflush.h
index 74d60cfe8ce5..fd318f7c3eed 100644
--- a/arch
empty-body]
DBG("Argh, can't find icache properties !\n");
Suggested-by: Tyrel Datwyler
Signed-off-by: Qian Cai
---
v2: fix it by using a NOP while loop.
arch/powerpc/kernel/setup_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/setup
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
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
the unused variable to avoid a compilation warning,
arch/powerpc/platforms/powernv/npu-dma.c: In function
'pnv_npu_dma_set_32':
arch/powerpc/platforms/powernv/npu-dma.c:198:10: warning: variable ‘rc’
set but not used [-Wunused-but-set-variable]
Signed-off-by: Qian Cai
---
arch/powerpc/platforms/p
pnv_npu2_handle_fault(),
arch/powerpc/platforms/powernv/npu-dma.c: In function 'pnv_npu2_handle_fault':
arch/powerpc/platforms/powernv/npu-dma.c:1122:7: warning: variable 'c'
set but not used [-Wunused-but-set-variable]
Fixed it by appending the __maybe_unused attribute, so compilers would
ignor
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
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/ioremap.c:203:16: wa
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
> 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
empty-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-by: Qian Cai
---
v3: Use no_printk()
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
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
On Tue, 2019-09-03 at 15:30 +0200, Christoph Hellwig wrote:
> On Tue, Sep 03, 2019 at 09:29:14AM -0400, Qian Cai wrote:
> > I saw Christ start to remove npu-dma.c code [1]
> >
> > [1] https://lore.kernel.org/linuxppc-dev/20190625145239.2759-4-...@lst.de/
> >
&g
don't need to bother fixing
the warning here.
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_n
ptrval) 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
On Thu, 2019-09-05 at 13:55 +1000, 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 PO
Fixes: 108c14858b9e ("locking/lockdep: Add support for dynamic keys")
Signed-off-by: Qian Cai
---
arch/powerpc/include/asm/sections.h | 10 ++
arch/powerpc/kernel/kvm.c | 5 +
include/asm-generic/sections.h | 7 +++
kernel/locking/lockdep.c
Fixes: 108c14858b9e ("locking/lockdep: Add support for dynamic keys")
Signed-off-by: Qian Cai
---
v2: No need to actually define arch_is_bss_hole() powerpc64 only.
arch/powerpc/include/asm/sections.h | 11 +++
arch/powerpc/kernel/kvm.c | 5 +
include/as
Michael, Aneesh, please take a take at this trivial patch.
On Fri, 2019-08-23 at 10:22 -0400, Qian Cai wrote:
> Booting a POWER9 PowerNV system generates a few messages below with
> "ptrval" due to the pointers printed without a specifier
> extension (i.e unado
> On Sep 7, 2019, at 3:05 AM, Ingo Molnar wrote:
>
>
> * Qian Cai wrote:
>
>> The commit 108c14858b9e ("locking/lockdep: Add support for dynamic
>> keys") introduced a boot warning on powerpc below, because since the
>> commit 2d4f567103ff (&q
Fixes: 108c14858b9e ("locking/lockdep: Add support for dynamic keys")
Signed-off-by: Qian Cai
---
v3: Change arch_is_bss_hole() to return a "bool".
Rearrange variables in kvm.c a bit.
v2: No need to actually define arch_is_bss_hole() powerpc64 only.
arch/powerpc/inclu
compiler warning flag.
Fixes: a4fcc877d4e1 ("powerpc/pkeys: Preallocate execute-only key")
Signed-off-by: Qian Cai
---
arch/powerpc/mm/book3s64/pkeys.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/powerpc/mm/book3s64/pkeys.c b/arch/powerpc/mm/book3s64/pkeys.c
index ae7f
Michael, ping in case that you might forget this one forever as well.
On Mon, 2019-07-15 at 14:32 -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
&
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
> > ---
_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 format and argument are always
verified by the comp
On Fri, 2019-09-20 at 19:55 +0530, Aneesh Kumar K.V wrote:
> Qian Cai writes:
>
> > The linux-next commit "libnvdimm/dax: Pick the right alignment default when
> > creating dax devices" causes powerpc failed to build with this config.
> > Reverted
>
> 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
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 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
# 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
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 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 Tue, 2019-10-15 at 20:51 +0530, Anshuman Khandual wrote:
>
> On 10/15/2019 08:11 PM, Qian Cai wrote:
> > The x86 will crash with linux-next during boot due to this series (v5) with
> > the
> > config below plus CONFIG_DEBUG_VM_PGTABLE=y. I am not sure
On Tue, 2019-10-15 at 14:51 +0530, Anshuman Khandual wrote:
> +static unsigned long __init get_random_vaddr(void)
> +{
> + unsigned long random_vaddr, random_pages, total_user_pages;
> +
> + total_user_pages = (TASK_SIZE - FIRST_USER_ADDRESS) / PAGE_SIZE;
> +
> + random_pages =
The x86 will crash with linux-next during boot due to this series (v5) with the
config below plus CONFIG_DEBUG_VM_PGTABLE=y. I am not sure if v6 would address
it.
https://raw.githubusercontent.com/cailca/linux-mm/master/x86.config
[ 33.862600][T1] page:ea000900 is uninitialized and
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
> 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:*
The linux-next commit "libnvdimm/dax: Pick the right alignment default when
creating dax devices" causes powerpc failed to build with this config. Reverted
it fixed the issue.
ERROR: "hash__has_transparent_hugepage" [drivers/nvdimm/libnvdimm.ko] undefined!
ERROR: "radix__has_transparent_hugepage"
> On Oct 2, 2019, at 9:36 PM, Leonardo Bras wrote:
>
> Adds config option LOCKLESS_PAGE_TABLE_WALK_TRACKING to make possible
> enabling tracking lockless pagetable walks directly from kernel config.
Can’t this name and all those new *lockless* function names be shorter? There
are many
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:
> 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.
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
e 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 in V7:
> (h
nlined 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 is on the
> 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
> 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
> 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 +
lk_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: convert pud
/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
---
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
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
> 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 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
> 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 wil
> 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
> 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
> 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
> 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
> 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
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
> >
> 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
> 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.
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
> 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 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:
>>>> E
> 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:
>>>> E
> 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 t
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]
> 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
+ 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-m
1 - 100 of 155 matches
Mail list logo
