On 6/24/2021 7:48 AM, Will Deacon wrote:
> Ok, diff below which attempts to tackle the offset issue I mentioned as
> well. Qian Cai -- please can you try with these changes?
This works fine.
>
> Will
>
> --->8
>
> diff --git a/include/linux/swiotlb.h b/incl
On 6/23/2021 2:37 PM, Will Deacon wrote:
> On Wed, Jun 23, 2021 at 12:39:29PM -0400, Qian Cai wrote:
>>
>>
>> On 6/18/2021 11:40 PM, Claire Chang wrote:
>>> Propagate the swiotlb_force into io_tlb_default_mem->force_bounce and
>>> use
On 6/18/2021 11:40 PM, Claire Chang wrote:
> Propagate the swiotlb_force into io_tlb_default_mem->force_bounce and
> use it to determine whether to bounce the data or not. This will be
> useful later to allow for different pools.
>
> Signed-off-by: Claire Chang
> Reviewed-by: Christoph
, and I wasn't
> able to reproduce the issue you reported. I did enable the list-debug
> config option.
The setup here is an arm64 server with 32 CPUs.
>
> On 14-06-21, 09:48, Qian Cai wrote:
>> Unfortunately, this series looks like needing more works.
>>
>> [ 48
On 6/10/2021 4:23 AM, Viresh Kumar wrote:
> Hi Qian,
>
> It would be helpful if you can test this patchset and confirm if the races you
> mentioned went away or not and that the FIE code works as we wanted it to.
>
> I don't have a real setup and so it won't be easy for me to test this out.
>
.config:
https://cailca.coding.net/public/linux/mm/git/files/master/powerpc.config
Today's linux-next starts to generate random process hang quite easily.
Yesterday's build seems work fine. Sometimes, the process stack seems corrupt
while the process is running 100% CPU with gdb shows it just
On Fri, 2020-11-06 at 13:20 +, Christophe Leroy wrote:
> All hugetlb range freeing functions have a verification like the following,
> which only differs by the mask used, depending on the page table level.
>
> start &= MASK;
> if (start < floor)
> return;
> if
On Sun, 2020-11-29 at 23:07 +, Krzysztof Wilczyński wrote:
> Unify ECAM-related constants into a single set of standard constants
> defining memory address shift values for the byte-level address that can
> be used when accessing the PCI Express Configuration Space, and then
> move native PCI
On Thu, 2020-12-03 at 12:17 -0500, Qian Cai wrote:
> []
> > +static inline bool
> > +bad_kuap_fault(struct pt_regs *regs, unsigned long address, bool is_write)
> > +{
> > + return WARN(mmu_has_feature(MMU_FTR_RADIX_KUAP) &&
> > + (regs
On Thu, 2020-12-03 at 12:17 -0500, Qian Cai wrote:
> A simple "echo t > /proc/sysrq-trigger" will trigger this warning almost
> endlessly on Power8 NV.
Correction -- POWER9 NV.
On Fri, 2020-11-20 at 10:13 +1100, Daniel Axtens wrote:
> From: Nicholas Piggin
>
> IBM Power9 processors can speculatively operate on data in the L1 cache
> before it has been completely validated, via a way-prediction mechanism. It
> is not possible for an attacker to determine the contents of
On Wed, 2020-10-28 at 17:31 -0700, Paul E. McKenney wrote:
> On Thu, Oct 29, 2020 at 11:09:07AM +1100, Michael Ellerman wrote:
> > Qian Cai writes:
> > > The call to rcu_cpu_starting() in start_secondary() is not early enough
> > > in the CPU-hotplug onlining proces
On Thu, 2020-10-29 at 11:09 +1100, Michael Ellerman wrote:
> Qian Cai writes:
> > The call to rcu_cpu_starting() in start_secondary() is not early enough
> > in the CPU-hotplug onlining process, which results in lockdep splats as
> > follows:
>
> Since when?
For
that the
raw_smp_processor_id() is required in order to avoid calling into
lockdep before RCU has declared the CPU to be watched for readers.
Link:
https://lore.kernel.org/lkml/160223032121.7002.1269740091547117869.tip-bot2@tip-bot2/
Signed-off-by: Qian Cai
---
arch/powerpc/kernel/smp.c | 3 ++-
1 file
/0x130
system_call_exception+0xf8/0x1d0
system_call_common+0xe8/0x218
Fixes: 5ca85ae6318d ("powerpc/eeh_cache: Add a way to dump the EEH address
cache")
Signed-off-by: Qian Cai
---
arch/powerpc/kernel/eeh_cache.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arc
This reverts commit 3a3181e16fbde752007759f8759d25e0ff1fc425 which
causes memory corruptions on POWER9 NV.
Signed-off-by: Qian Cai
---
arch/powerpc/include/asm/pci-bridge.h | 6 --
arch/powerpc/kernel/pci-common.c | 114 --
2 files changed, 120 deletions(-)
diff
On Wed, 2020-09-23 at 09:06 +0200, Cédric Le Goater wrote:
> On 9/23/20 2:33 AM, Qian Cai wrote:
> > On Fri, 2020-08-07 at 12:18 +0200, Cédric Le Goater wrote:
> > > When a passthrough IO adapter is removed from a pseries machine using
> > > hash MMU and the XIV
On Wed, 2020-10-07 at 19:47 +0530, Srikar Dronamraju wrote:
> Can you confirm if CONFIG_CPUMASK_OFFSTACK is enabled in your config?
Yes, https://gitlab.com/cailca/linux-mm/-/blob/master/powerpc.config
We tested here almost daily on linux-next.
On Mon, 2020-09-21 at 15:26 +0530, Srikar Dronamraju wrote:
> All threads of a SMT4 core can either be part of this CPU's l2-cache
> mask or not related to this CPU l2-cache mask. Use this relation to
> reduce the number of iterations needed to find all the CPUs that share
> the same l2-cache.
>
On Fri, 2020-08-07 at 12:18 +0200, Cédric Le Goater wrote:
> When a passthrough IO adapter is removed from a pseries machine using
> hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the
> guest OS to clear all page table entries related to the adapter. If
> some are still
On Wed, Jul 22, 2020 at 03:44:06PM +0200, Peter Zijlstra wrote:
> On Wed, Jul 22, 2020 at 09:19:00AM -0400, Qian Cai wrote:
> > On Wed, Jul 22, 2020 at 12:06:37PM +0200, pet...@infradead.org wrote:
> > > On Thu, Jun 04, 2020 at 11:03:44AM -0400, Qian Cai wrote:
> > &
On Fri, Jul 03, 2020 at 11:06:05AM +0530, Bharata B Rao wrote:
> Hypervisor may choose not to enable Guest Translation Shootdown Enable
> (GTSE) option for the guest. When GTSE isn't ON, the guest OS isn't
> permitted to use instructions like tblie and tlbsync directly, but is
> expected to make
On Mon, Jun 29, 2020 at 09:39:45PM +0200, Christoph Hellwig wrote:
> Split out a __submit_bio_noacct helper for the actual de-recursion
> algorithm, and simplify the loop by using a continue when we can't
> enter the queue for a bio.
>
> Signed-off-by: Christoph Hellwig
Reverting this commit
> On Jun 3, 2020, at 3:05 PM, Andrew Morton wrote:
>
> A bunch of new material just landed in linux-next/powerpc.
>
> The timing is awkward! I trust this will be going into mainline during
> this merge window? If not, please drop it and repull after -rc1.
I have noticed the same pattern
On Tue, Jun 02, 2020 at 05:05:11PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 02, 2020 at 10:42:35AM -0400, Qian Cai wrote:
>
> > Reverted this commit fixed the POWER9 boot warning,
>
> ARGH, I'm an idiot. Please try this instead:
>
>
> diff --git a/kernel/softirq.c
On Fri, May 29, 2020 at 11:27:39PM +0200, Peter Zijlstra wrote:
> Because:
>
> irq_enter_rcu() includes lockdep_hardirq_enter()
> irq_exit_rcu() does *NOT* include lockdep_hardirq_exit()
>
> Which resulted in two 'stray' lockdep_hardirq_exit() calls in
> idtentry.h, and me spending a long
On Wed, May 27, 2020 at 11:13:23AM +1000, Paul Mackerras wrote:
> On Sun, May 10, 2020 at 01:18:34AM -0400, Qian Cai wrote:
> > It is unsafe to traverse kvm->arch.spapr_tce_tables and
> > stt->iommu_tables without the RCU read lock held. Also, add
> > cond_resched_rcu()
On Thu, May 21, 2020 at 11:39:38AM +0200, Peter Zijlstra wrote:
> On Thu, May 21, 2020 at 02:40:36AM +0200, Frederic Weisbecker wrote:
> > On Wed, May 20, 2020 at 02:50:56PM +0200, Peter Zijlstra wrote:
> > > On Tue, May 19, 2020 at 11:58:17PM -0400, Qian Cai wrote:
>
On Wed, May 20, 2020 at 02:50:56PM +0200, Peter Zijlstra wrote:
> On Tue, May 19, 2020 at 11:58:17PM -0400, Qian Cai wrote:
> > Just a head up. Repeatedly compiling kernels for a while would trigger
> > endless soft-lockups since next-20200519 on both x86_64 and power
Just a head up. Repeatedly compiling kernels for a while would trigger
endless soft-lockups since next-20200519 on both x86_64 and powerpc.
.config are in,
https://github.com/cailca/linux-mm
I did first try to revert the linux-next commit 68cd9f4e7238
("tick/nohz: Narrow down noise while setting
[kvm]
[<93dfc014>] 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
[<
]
[<d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm]
[<d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm]
[<2543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm]
[<48155cd6>] ksys_ioctl+0xd8/0x130
[<41ffeaa7>] sys_ioctl+0x28/0x40
[<
> On May 13, 2020, at 12:04 AM, Michael Ellerman wrote:
>
> This should probably also have an include of ?
No, asm/book3s/64/pgalloc.h has already had it and since this is
book3s_64_mmu_radix.c, it will include it eventually from,
asm/pgalloc.h
asm/book3s/pgalloc.h
> 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
uler_active = 2, debug_locks = 1
1 lock held by qemu-kvm/4257:
#0: c000200b1b363a40 (>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 insertions(+), 4 deletions(-)
diff --
info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
2 locks held by qemu-kvm/4312:
#0: c00ecafe23c8 (>mutex){+.+.}-{3:3}, at:
kvm_vcpu_ioctl+0xdc/0x950 [kvm]
#1: c00045e6c468 (>srcu){}-{0:0}, at:
kvmppc_h_put_tce+0x88/0x340 [kvm]
Signed-off-by
0f29afdc0] [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/arch/powerpc/platforms/powernv/pci-ioda-tce.
> 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.
> 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 +
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 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
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
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
> 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
> 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
> 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 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 f
> 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
> 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
> 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
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 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
> 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..8e99cf91b99
> 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
+ 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
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
> 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
> 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
+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-by: Qian Cai
---
arch/powerpc
> 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:
> 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 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 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 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
---
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 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 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
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 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 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 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 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 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 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 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 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 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 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 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.
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 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:*
> 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 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 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
# 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 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
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 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:
> > > >
> 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 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
_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 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
1 - 100 of 155 matches
Mail list logo
