[PATCH] powerpc/6xx: Fix power_save_ppc32_restore() with CONFIG_VMAP_STACK
power_save_ppc32_restore() is called during exception entry, before
re-enabling the MMU. It substracts KERNELBASE from the address
of nap_save_msscr0 to access it.
With CONFIG_VMAP_STACK enabled, data MMU translation has already been
re-enabled, so power_save_ppc32_restore() has to access
nap_save_msscr0 by its virtual address.
Reported-by: Larry Finger
Signed-off-by: Christophe Leroy
Fixes: cd08f109e262 ("powerpc/32s: Enable CONFIG_VMAP_STACK")
Tested-by: Larry Finger
---
arch/powerpc/kernel/idle_6xx.S | 8
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/kernel/idle_6xx.S b/arch/powerpc/kernel/idle_6xx.S
index 0ffdd18b9f26..433d97bea1f3 100644
--- a/arch/powerpc/kernel/idle_6xx.S
+++ b/arch/powerpc/kernel/idle_6xx.S
@@ -166,7 +166,11 @@ BEGIN_FTR_SECTION
mfspr r9,SPRN_HID0
andis. r9,r9,HID0_NAP@h
beq 1f
+#ifdef CONFIG_VMAP_STACK
+ addis r9, r11, nap_save_msscr0@ha
+#else
addis r9,r11,(nap_save_msscr0-KERNELBASE)@ha
+#endif
lwz r9,nap_save_msscr0@l(r9)
mtspr SPRN_MSSCR0, r9
sync
@@ -174,7 +178,11 @@ BEGIN_FTR_SECTION
1:
END_FTR_SECTION_IFSET(CPU_FTR_NAP_DISABLE_L2_PR)
BEGIN_FTR_SECTION
+#ifdef CONFIG_VMAP_STACK
+ addis r9, r11, nap_save_hid1@ha
+#else
addis r9,r11,(nap_save_hid1-KERNELBASE)@ha
+#endif
lwz r9,nap_save_hid1@l(r9)
mtspr SPRN_HID1, r9
END_FTR_SECTION_IFSET(CPU_FTR_DUAL_PLL_750FX)
--
2.25.0
Re: [PATCH v2] powerpc/32s: Fix DSI and ISI exceptions for CONFIG_VMAP_STACK
Le 13/02/2020 à 11:04, Christophe Leroy a écrit :
hash_page() needs to read page tables from kernel memory. When entire
kernel memory is mapped by BATs, which is normally the case when
CONFIG_STRICT_KERNEL_RWX is not set, it works even if the page hosting
the page table is not referenced in the MMU hash table.
However, if the page where the page table resides is not covered by
a BAT, a DSI fault can be encountered from hash_page(), and it loops
forever. This can happen when CONFIG_STRICT_KERNEL_RWX is selected
and the alignment of the different regions is too small to allow
covering the entire memory with BATs. This also happens when
CONFIG_DEBUG_PAGEALLOC is selected or when booting with 'nobats'
flag.
Also, if the page containing the kernel stack is not present in the
MMU hash table, registers cannot be saved and a recursive DSI fault
is encountered.
To allow hash_page() to properly do its job at all time and load the
MMU hash table whenever needed, it must run with data MMU disabled.
This means it must be called before re-enabling data MMU. To allow
this, registers clobbered by hash_page() and create_hpte() have to
be saved in the thread struct together with SRR0, SSR1, DAR and DSISR.
It is also necessary to ensure that DSI prolog doesn't overwrite
regs saved by prolog of the current running exception. That means:
- DSI can only use SPRN_SPRG_SCRATCH0
- Exceptions must free SPRN_SPRG_SCRATCH0 before writing to the stack.
This also fixes the Oops reported by Erhard when create_hpte() is
called by add_hash_page().
Fixes: cd08f109e262 ("powerpc/32s: Enable CONFIG_VMAP_STACK")
Reported-by: Erhard F.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206501
Signed-off-by: Christophe Leroy
Tested-by: Erhard F.
Re: RESEND: Re: Problem booting a PowerBook G4 Aluminum after commit cd08f109 with CONFIG_VMAP_STACK=y
Larry, Le 14/02/2020 à 00:09, Larry Finger a écrit : Christophe, With this patch, it gets further. Sometime after the boot process tries to start process init, it crashes with the unable to read data at 0x000157a0 with a faulting address of 0xc001683c. The screenshot is attached and the gzipped vmlinux is at http://www.lwfinger.com/download/vmlinux2.gz. The patches that were applied for this kernel are also attached, Did you try with the patch at https://patchwork.ozlabs.org/patch/1237387/ ? I see the problem happens in kprobe_handler(). Can you try without CONFIG_KPROBE ? Christophe
Re: [PATCH v2 1/4] mm/memremap_pages: Introduce memremap_compat_align()
Dan Williams writes:
> On Thu, Feb 13, 2020 at 8:58 AM Jeff Moyer wrote:
>>
>> Dan Williams writes:
>>
>> > The "sub-section memory hotplug" facility allows memremap_pages() users
>> > like libnvdimm to compensate for hardware platforms like x86 that have a
>> > section size larger than their hardware memory mapping granularity. The
>> > compensation that sub-section support affords is being tolerant of
>> > physical memory resources shifting by units smaller (64MiB on x86) than
>> > the memory-hotplug section size (128 MiB). Where the platform
>> > physical-memory mapping granularity is limited by the number and
>> > capability of address-decode-registers in the memory controller.
>> >
>> > While the sub-section support allows memremap_pages() to operate on
>> > sub-section (2MiB) granularity, the Power architecture may still
>> > require 16MiB alignment on "!radix_enabled()" platforms.
>> >
>> > In order for libnvdimm to be able to detect and manage this per-arch
>> > limitation, introduce memremap_compat_align() as a common minimum
>> > alignment across all driver-facing memory-mapping interfaces, and let
>> > Power override it to 16MiB in the "!radix_enabled()" case.
>> >
>> > The assumption / requirement for 16MiB to be a viable
>> > memremap_compat_align() value is that Power does not have platforms
>> > where its equivalent of address-decode-registers never hardware remaps a
>> > persistent memory resource on smaller than 16MiB boundaries. Note that I
>> > tried my best to not add a new Kconfig symbol, but header include
>> > entanglements defeated the #ifndef memremap_compat_align design pattern
>> > and the need to export it defeats the __weak design pattern for arch
>> > overrides.
>> >
>> > Based on an initial patch by Aneesh.
>>
>> I have just a couple of questions.
>>
>> First, can you please add a comment above the generic implementation of
>> memremap_compat_align describing its purpose, and why a platform might
>> want to override it?
>
> Sure, how about:
>
> /*
> * The memremap() and memremap_pages() interfaces are alternately used
> * to map persistent memory namespaces. These interfaces place different
> * constraints on the alignment and size of the mapping (namespace).
> * memremap() can map individual PAGE_SIZE pages. memremap_pages() can
> * only map subsections (2MB), and at least one architecture (PowerPC)
> * the minimum mapping granularity of memremap_pages() is 16MB.
> *
> * The role of memremap_compat_align() is to communicate the minimum
> * arch supported alignment of a namespace such that it can freely
> * switch modes without violating the arch constraint. Namely, do not
> * allow a namespace to be PAGE_SIZE aligned since that namespace may be
> * reconfigured into a mode that requires SUBSECTION_SIZE alignment.
> */
>
>> Second, I will take it at face value that the power architecture
>> requires a 16MB alignment, but it's not clear to me why mmu_linear_psize
>> was chosen to represent that. What's the relationship, there, and can
>> we please have a comment explaining it?
>
> Aneesh, can you help here?
With hash translation, we map the direct-map range with just one page
size. Based on different restrictions as described in htab_init_page_sizes
we can end up choosing 16M, 64K or even 4K. We use the variable
mmu_linear_psize to indicate which page size we used for direct-map
range.
ie we should do.
+unsigned long arch_namespace_align_size(void)
+{
+ unsigned long sub_section_size = (1UL << SUBSECTION_SHIFT);
+
+ if (radix_enabled())
+ return sub_section_size;
+ return max(sub_section_size, (1UL <<
mmu_psize_defs[mmu_linear_psize].shift));
+
+}
+EXPORT_SYMBOL_GPL(arch_namespace_align_size);
as done here
https://lore.kernel.org/linux-nvdimm/20200120140749.69549-4-aneesh.ku...@linux.ibm.com/
Dan can you update the powerpc definition?
-aneesh
Re: [PATCH v2] powerpc: setup_64: set up PACA earlier to avoid kcov problems
On 13/2/20 4:23 pm, Daniel Axtens wrote:
kcov instrumentation is collected the __sanitizer_cov_trace_pc hook in
kernel/kcov.c. The compiler inserts these hooks into every basic block
unless kcov is disabled for that file.
We then have a deep call-chain:
- __sanitizer_cov_trace_pc calls to check_kcov_mode()
- check_kcov_mode() (kernel/kcov.c) calls in_task()
- in_task() (include/linux/preempt.h) calls preempt_count().
- preempt_count() (include/asm-generic/preempt.h) calls
current_thread_info()
- because powerpc has THREAD_INFO_IN_TASK, current_thread_info()
(include/linux/thread_info.h) is defined to 'current'
- current (arch/powerpc/include/asm/current.h) is defined to
get_current().
- get_current (same file) loads an offset of r13.
- arch/powerpc/include/asm/paca.h makes r13 a register variable
called local_paca - it is the PACA for the current CPU, so
this has the effect of loading the current task from PACA.
- get_current returns the current task from PACA,
- current_thread_info returns the task cast to a thread_info
- preempt_count dereferences the thread_info to load preempt_count
- that value is used by in_task and so on up the chain
The problem is:
- kcov instrumentation is enabled for arch/powerpc/kernel/dt_cpu_ftrs.c
- even if it were not, dt_cpu_ftrs_init calls generic dt parsing code
which should definitely have instrumentation enabled.
- setup_64.c calls dt_cpu_ftrs_init before it sets up a PACA.
- If we don't set up a paca, r13 will contain unpredictable data.
- In a zImage compiled with kcov and KASAN, we see r13 containing a value
that leads to dereferencing invalid memory (something like
912a72603d420015).
- Weirdly, the same kernel as a vmlinux loaded directly by qemu does not
crash. Investigating with gdb, it seems that in the vmlinux boot case,
r13 is near enough to zero that we just happen to be able to read that
part of memory (we're operating with translation off at this point) and
the current pointer also happens to land in readable memory and
everything just works.
- PACA setup refers to CPU features - setup_paca() looks at
early_cpu_has_feature(CPU_FTR_HVMODE)
There's no generic kill switch for kcov (as far as I can tell), and we
don't want to have to turn off instrumentation in the generic dt parsing
code (which lives outside arch/powerpc/) just because we don't have a real
paca or task yet.
So:
- change the test when setting up a PACA to consider the actual value of
the MSR rather than the CPU feature.
- move the PACA setup to before the cpu feature parsing.
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")
Cc: Andrew Donnellan
Suggested-by: Michael Ellerman
Signed-off-by: Daniel Axtens
There's some special handling for CPU_FTR_HVMODE in
cpufeatures_setup_cpu() in kernel/dt_cpu_ftrs.c:
/* Initialize the base environment -- clear FSCR/HFSCR. */
hv_mode = !!(mfmsr() & MSR_HV);
if (hv_mode) {
/* CPU_FTR_HVMODE is used early in PACA setup */
cur_cpu_spec->cpu_features |= CPU_FTR_HVMODE;
mtspr(SPRN_HFSCR, 0);
}
With this patch, the comment about PACA setup I assume is no longer
true. It looks like we still rely on hv_mode being set to deal with
discrepancies between the device tree and the MSR.
--
Andrew Donnellan OzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited
[PATCH] powerpc: fix hardware PMU exception bug on PowerVM compatibility mode systems
PowerVM systems running compatibility mode on a few Power8 revisions are
still vulnerable to the hardware defect that loses PMU exceptions arriving
prior to a context switch.
The software fix for this issue is enabled through the CPU_FTR_PMAO_BUG
cpu_feature bit, nevertheless this bit also needs to be set for PowerVM
compatibility mode systems.
Fixes: 68f2f0d431d9ea4 ("powerpc: Add a cpu feature CPU_FTR_PMAO_BUG")
Signed-off-by: Desnes A. Nunes do Rosario
---
arch/powerpc/kernel/cputable.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index e745abc5457a..5bfef6263dfb 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -2198,6 +2198,8 @@ static struct cpu_spec * __init setup_cpu_spec(unsigned
long offset,
if (old.oprofile_cpu_type != NULL) {
t->oprofile_cpu_type = old.oprofile_cpu_type;
t->oprofile_type = old.oprofile_type;
+ if (old.cpu_features & CPU_FTR_PMAO_BUG)
+ t->cpu_features |= CPU_FTR_PMAO_BUG;
}
}
--
2.21.1
Re: [PATCH] KVM: PPC: Book3S HV: Treat unrecognized TM instructions as illegal
Hi Segher,
Thanks a lot for reviewing it.
On 02/13/2020 08:31 PM, Segher Boessenkool wrote:
---
arch/powerpc/kvm/book3s_hv_tm.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_hv_tm.c b/arch/powerpc/kvm/book3s_hv_tm.c
index 0db937497169..d342a9e11298 100644
--- a/arch/powerpc/kvm/book3s_hv_tm.c
+++ b/arch/powerpc/kvm/book3s_hv_tm.c
@@ -3,6 +3,8 @@
* Copyright 2017 Paul Mackerras, IBM Corp.
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
@@ -208,6 +210,8 @@ int kvmhv_p9_tm_emulation(struct kvm_vcpu *vcpu)
}
/* What should we do here? We didn't recognize the instruction */
- WARN_ON_ONCE(1);
+ kvmppc_core_queue_program(vcpu, SRR1_PROGILL);
+ pr_warn_ratelimited("Unrecognized TM-related instruction %#x for
emulation", instr);
+
return RESUME_GUEST;
}
Do we actually know it is TM-related here? Otherwise, looks good to me :-)
Correct, I understand it's only TM-related here, so I don't expect anything
else to hit 0x1500.
Best regards,
Gustavo
Re: [PATCH] KVM: PPC: Book3S HV: Treat unrecognized TM instructions as illegal
On Thu, Feb 13, 2020 at 10:15:32AM -0500, Gustavo Romero wrote:
> On P9 DD2.2 due to a CPU defect some TM instructions need to be emulated by
> KVM. This is handled at first by the hardware raising a softpatch interrupt
> when certain TM instructions that need KVM assistance are executed in the
> guest. Some TM instructions, although not defined in the Power ISA, might
> raise a softpatch interrupt. For instance, 'tresume.' instruction as
> defined in the ISA must have bit 31 set (1), but an instruction that
> matches 'tresume.' OP and XO opcodes but has bit 31 not set (0), like
> 0x7cfe9ddc, also raises a softpatch interrupt, for example, if a code
> like the following is executed in the guest it will raise a softpatch
> interrupt just like a 'tresume.' when the TM facility is enabled:
>
> int main() { asm("tabort. 0; .long 0x7cfe9ddc;"); }
>
> Currently in such a case KVM throws a complete trace like the following:
[snip]
> and then treats the executed instruction as 'nop' whilst it should actually
> be treated as an illegal instruction since it's not defined by the ISA.
>
> This commit changes the handling of the case above by treating the
> unrecognized TM instructions that can raise a softpatch but are not
> defined in the ISA as illegal ones instead of as 'nop' and by gently
> reporting it to the host instead of throwing a trace.
>
> Signed-off-by: Gustavo Romero
Reviewed-by: Segher Boessenkool
> ---
> arch/powerpc/kvm/book3s_hv_tm.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kvm/book3s_hv_tm.c b/arch/powerpc/kvm/book3s_hv_tm.c
> index 0db937497169..d342a9e11298 100644
> --- a/arch/powerpc/kvm/book3s_hv_tm.c
> +++ b/arch/powerpc/kvm/book3s_hv_tm.c
> @@ -3,6 +3,8 @@
> * Copyright 2017 Paul Mackerras, IBM Corp.
> */
>
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> #include
>
> #include
> @@ -208,6 +210,8 @@ int kvmhv_p9_tm_emulation(struct kvm_vcpu *vcpu)
> }
>
> /* What should we do here? We didn't recognize the instruction */
> - WARN_ON_ONCE(1);
> + kvmppc_core_queue_program(vcpu, SRR1_PROGILL);
> + pr_warn_ratelimited("Unrecognized TM-related instruction %#x for
> emulation", instr);
> +
> return RESUME_GUEST;
> }
Do we actually know it is TM-related here? Otherwise, looks good to me :-)
Segher
Re: [PATCH v2 2/4] libnvdimm/namespace: Enforce memremap_compat_align()
On Thu, Feb 13, 2020 at 1:55 PM Jeff Moyer wrote:
>
> Dan Williams writes:
>
> > The pmem driver on PowerPC crashes with the following signature when
> > instantiating misaligned namespaces that map their capacity via
> > memremap_pages().
> >
> > BUG: Unable to handle kernel data access at 0xc00100040600
> > Faulting instruction address: 0xc0090790
> > NIP [c0090790] arch_add_memory+0xc0/0x130
> > LR [c0090744] arch_add_memory+0x74/0x130
> > Call Trace:
> > arch_add_memory+0x74/0x130 (unreliable)
> > memremap_pages+0x74c/0xa30
> > devm_memremap_pages+0x3c/0xa0
> > pmem_attach_disk+0x188/0x770
> > nvdimm_bus_probe+0xd8/0x470
> >
> > With the assumption that only memremap_pages() has alignment
> > constraints, enforce memremap_compat_align() for
> > pmem_should_map_pages(), nd_pfn, or nd_dax cases.
> >
> > Reported-by: Aneesh Kumar K.V
> > Cc: Jeff Moyer
> > Reviewed-by: Aneesh Kumar K.V
> > Link:
> > https://lore.kernel.org/r/158041477336.3889308.4581652885008605170.st...@dwillia2-desk3.amr.corp.intel.com
> > Signed-off-by: Dan Williams
> > ---
> > drivers/nvdimm/namespace_devs.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/nvdimm/namespace_devs.c
> > b/drivers/nvdimm/namespace_devs.c
> > index 032dc61725ff..aff1f32fdb4f 100644
> > --- a/drivers/nvdimm/namespace_devs.c
> > +++ b/drivers/nvdimm/namespace_devs.c
> > @@ -1739,6 +1739,16 @@ struct nd_namespace_common
> > *nvdimm_namespace_common_probe(struct device *dev)
> > return ERR_PTR(-ENODEV);
> > }
> >
> > + if (pmem_should_map_pages(dev) || nd_pfn || nd_dax) {
> > + struct nd_namespace_io *nsio = to_nd_namespace_io(>dev);
> > + resource_size_t start = nsio->res.start;
> > +
> > + if (!IS_ALIGNED(start | size, memremap_compat_align())) {
> > + dev_dbg(>dev, "misaligned, unable to map\n");
> > + return ERR_PTR(-EOPNOTSUPP);
> > + }
> > + }
> > +
> > if (is_namespace_pmem(>dev)) {
> > struct nd_namespace_pmem *nspm;
> >
>
> Actually, I take back my ack. :) This prevents a previously working
> namespace from being successfully probed/setup.
Do you have a test case handy? I can see a potential gap with a
namespace that used internal padding to fix up the alignment. The goal
of this check is to catch cases that are just going to fail
devm_memremap_pages(), and the expectation is that it could not have
worked before unless it was ported from another platform, or someone
flipped the page-size switch on PowerPC.
> I thought we were only
> going to enforce the alignment for a newly created namespace? This should
> only check whether the alignment works for the current platform.
The model is a new default 16MB alignment is enforced at creation
time, but if you need to support previously created namespaces then
you can manually trim that alignment requirement to no less than
memremap_compat_align() because that's the point at which
devm_memremap_pages() will start failing or crashing.
Re: [PATCH v2 2/4] libnvdimm/namespace: Enforce memremap_compat_align()
Dan Williams writes:
> The pmem driver on PowerPC crashes with the following signature when
> instantiating misaligned namespaces that map their capacity via
> memremap_pages().
>
> BUG: Unable to handle kernel data access at 0xc00100040600
> Faulting instruction address: 0xc0090790
> NIP [c0090790] arch_add_memory+0xc0/0x130
> LR [c0090744] arch_add_memory+0x74/0x130
> Call Trace:
> arch_add_memory+0x74/0x130 (unreliable)
> memremap_pages+0x74c/0xa30
> devm_memremap_pages+0x3c/0xa0
> pmem_attach_disk+0x188/0x770
> nvdimm_bus_probe+0xd8/0x470
>
> With the assumption that only memremap_pages() has alignment
> constraints, enforce memremap_compat_align() for
> pmem_should_map_pages(), nd_pfn, or nd_dax cases.
>
> Reported-by: Aneesh Kumar K.V
> Cc: Jeff Moyer
> Reviewed-by: Aneesh Kumar K.V
> Link:
> https://lore.kernel.org/r/158041477336.3889308.4581652885008605170.st...@dwillia2-desk3.amr.corp.intel.com
> Signed-off-by: Dan Williams
> ---
> drivers/nvdimm/namespace_devs.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
> index 032dc61725ff..aff1f32fdb4f 100644
> --- a/drivers/nvdimm/namespace_devs.c
> +++ b/drivers/nvdimm/namespace_devs.c
> @@ -1739,6 +1739,16 @@ struct nd_namespace_common
> *nvdimm_namespace_common_probe(struct device *dev)
> return ERR_PTR(-ENODEV);
> }
>
> + if (pmem_should_map_pages(dev) || nd_pfn || nd_dax) {
> + struct nd_namespace_io *nsio = to_nd_namespace_io(>dev);
> + resource_size_t start = nsio->res.start;
> +
> + if (!IS_ALIGNED(start | size, memremap_compat_align())) {
> + dev_dbg(>dev, "misaligned, unable to map\n");
> + return ERR_PTR(-EOPNOTSUPP);
> + }
> + }
> +
> if (is_namespace_pmem(>dev)) {
> struct nd_namespace_pmem *nspm;
>
Actually, I take back my ack. :) This prevents a previously working
namespace from being successfully probed/setup. I thought we were only
going to enforce the alignment for a newly created namespace? This should
only check whether the alignment works for the current platform.
-Jeff
RE: [PATCH] serial: cpm_uart: call cpm_muram_init before registering console
> -Original Message-
> From: Rasmus Villemoes
> Sent: Thursday, February 13, 2020 5:44 AM
> To: Greg Kroah-Hartman ; Jiri Slaby
> ; Timur Tabi ; Leo Li
> ; Rasmus Villemoes
> Cc: Qiang Zhao ; linuxppc-dev@lists.ozlabs.org; Scott
> Wood ; Christophe Leroy ;
> linux-ser...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: [PATCH] serial: cpm_uart: call cpm_muram_init before registering
> console
>
> Christophe reports that powerpc 8xx silently fails to 5.6-rc1. It turns out I
> was
> wrong about nobody relying on the lazy initialization of the cpm/qe muram in
> commit b6231ea2b3c6 (soc: fsl: qe: drop broken lazy call of
> cpm_muram_init()).
>
> Rather than reinstating the somewhat dubious lazy call (initializing a
> currently
> held spinlock, and implicitly doing a GFP_KERNEL under that spinlock), make
> sure that cpm_muram_init() is called early enough - I thought the calls from
> the subsys_initcalls were good enough, but when used by console drivers,
> that's obviously not the case. cpm_muram_init() is safe to call twice (there's
> an early return if it is already initialized), so keep the call from
> cpm_init() - in
> case SERIAL_CPM_CONSOLE=n.
>
> Reported-by: Christophe Leroy
> Fixes: b6231ea2b3c6 (soc: fsl: qe: drop broken lazy call of cpm_muram_init())
> Signed-off-by: Rasmus Villemoes
Acked-by: Li Yang
> ---
>
> Christophe, can I get you to add a formal Tested-by?
>
> I'm not sure which tree this should go through.
>
> drivers/tty/serial/cpm_uart/cpm_uart_core.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/tty/serial/cpm_uart/cpm_uart_core.c
> b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
> index 19d5a4cf29a6..d4b81b06e0cb 100644
> --- a/drivers/tty/serial/cpm_uart/cpm_uart_core.c
> +++ b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
> @@ -1373,6 +1373,7 @@ static struct console cpm_scc_uart_console = {
>
> static int __init cpm_uart_console_init(void) {
> + cpm_muram_init();
> register_console(_scc_uart_console);
> return 0;
> }
> --
> 2.23.0
Re: [PATCH v2 1/4] mm/memremap_pages: Introduce memremap_compat_align()
Dan Williams writes:
> The "sub-section memory hotplug" facility allows memremap_pages() users
> like libnvdimm to compensate for hardware platforms like x86 that have a
> section size larger than their hardware memory mapping granularity. The
> compensation that sub-section support affords is being tolerant of
> physical memory resources shifting by units smaller (64MiB on x86) than
> the memory-hotplug section size (128 MiB). Where the platform
> physical-memory mapping granularity is limited by the number and
> capability of address-decode-registers in the memory controller.
>
> While the sub-section support allows memremap_pages() to operate on
> sub-section (2MiB) granularity, the Power architecture may still
> require 16MiB alignment on "!radix_enabled()" platforms.
>
> In order for libnvdimm to be able to detect and manage this per-arch
> limitation, introduce memremap_compat_align() as a common minimum
> alignment across all driver-facing memory-mapping interfaces, and let
> Power override it to 16MiB in the "!radix_enabled()" case.
>
> The assumption / requirement for 16MiB to be a viable
> memremap_compat_align() value is that Power does not have platforms
> where its equivalent of address-decode-registers never hardware remaps a
> persistent memory resource on smaller than 16MiB boundaries. Note that I
> tried my best to not add a new Kconfig symbol, but header include
> entanglements defeated the #ifndef memremap_compat_align design pattern
> and the need to export it defeats the __weak design pattern for arch
> overrides.
>
> Based on an initial patch by Aneesh.
I have just a couple of questions.
First, can you please add a comment above the generic implementation of
memremap_compat_align describing its purpose, and why a platform might
want to override it?
Second, I will take it at face value that the power architecture
requires a 16MB alignment, but it's not clear to me why mmu_linear_psize
was chosen to represent that. What's the relationship, there, and can
we please have a comment explaining it?
Thanks!
Jeff
>
> Link:
> http://lore.kernel.org/r/capcyv4gbgnp95apyabcsocea50tqj9b5h__83vgngjq3oug...@mail.gmail.com
> Reported-by: Aneesh Kumar K.V
> Reported-by: Jeff Moyer
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Signed-off-by: Dan Williams
> ---
> arch/powerpc/Kconfig |1 +
> arch/powerpc/mm/ioremap.c | 12
> drivers/nvdimm/pfn_devs.c |2 +-
> include/linux/memremap.h |8
> include/linux/mmzone.h|1 +
> lib/Kconfig |3 +++
> mm/memremap.c | 13 +
> 7 files changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 497b7d0b2d7e..e6ffe905e2b9 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -122,6 +122,7 @@ config PPC
> select ARCH_HAS_GCOV_PROFILE_ALL
> select ARCH_HAS_KCOV
> select ARCH_HAS_HUGEPD if HUGETLB_PAGE
> + select ARCH_HAS_MEMREMAP_COMPAT_ALIGN
> select ARCH_HAS_MMIOWB if PPC64
> select ARCH_HAS_PHYS_TO_DMA
> select ARCH_HAS_PMEM_API
> diff --git a/arch/powerpc/mm/ioremap.c b/arch/powerpc/mm/ioremap.c
> index fc669643ce6a..38b5ba7d3e2d 100644
> --- a/arch/powerpc/mm/ioremap.c
> +++ b/arch/powerpc/mm/ioremap.c
> @@ -2,6 +2,7 @@
>
> #include
> #include
> +#include
> #include
> #include
>
> @@ -97,3 +98,14 @@ void __iomem *do_ioremap(phys_addr_t pa, phys_addr_t
> offset, unsigned long size,
>
> return NULL;
> }
> +
> +#ifdef CONFIG_ZONE_DEVICE
> +/* override of the generic version in mm/memremap.c */
> +unsigned long memremap_compat_align(void)
> +{
> + if (radix_enabled())
> + return SUBSECTION_SIZE;
> + return (1UL << mmu_psize_defs[mmu_linear_psize].shift);
> +}
> +EXPORT_SYMBOL_GPL(memremap_compat_align);
> +#endif
> diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/nvdimm/pfn_devs.c
> index b94f7a7e94b8..a5c25cb87116 100644
> --- a/drivers/nvdimm/pfn_devs.c
> +++ b/drivers/nvdimm/pfn_devs.c
> @@ -750,7 +750,7 @@ static int nd_pfn_init(struct nd_pfn *nd_pfn)
> start = nsio->res.start;
> size = resource_size(>res);
> npfns = PHYS_PFN(size - SZ_8K);
> - align = max(nd_pfn->align, (1UL << SUBSECTION_SHIFT));
> + align = max(nd_pfn->align, SUBSECTION_SIZE);
> end_trunc = start + size - ALIGN_DOWN(start + size, align);
> if (nd_pfn->mode == PFN_MODE_PMEM) {
> /*
> diff --git a/include/linux/memremap.h b/include/linux/memremap.h
> index 6fefb09af7c3..8af1cbd8f293 100644
> --- a/include/linux/memremap.h
> +++ b/include/linux/memremap.h
> @@ -132,6 +132,7 @@ struct dev_pagemap *get_dev_pagemap(unsigned long pfn,
>
> unsigned long vmem_altmap_offset(struct vmem_altmap *altmap);
> void vmem_altmap_free(struct vmem_altmap *altmap, unsigned long nr_pfns);
> +unsigned long memremap_compat_align(void);
> #else
> static inline
[Bug 206527] New: Kernel 5.6-rc1 w. CONFIG_VMAP_STACK=y + CONFIG_KASAN=y fails to boot on a PowerMac G4 3,6
https://bugzilla.kernel.org/show_bug.cgi?id=206527 Bug ID: 206527 Summary: Kernel 5.6-rc1 w. CONFIG_VMAP_STACK=y + CONFIG_KASAN=y fails to boot on a PowerMac G4 3,6 Product: Platform Specific/Hardware Version: 2.5 Kernel Version: 5.6.0-rc1 Hardware: PPC-32 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: PPC-32 Assignee: platform_ppc...@kernel-bugs.osdl.org Reporter: erhar...@mailbox.org Regression: No Created attachment 287361 --> https://bugzilla.kernel.org/attachment.cgi?id=287361=edit screenshot of stuck boot process Happens on my G4 DP with kernel 5.6.0-rc1 and KASAN (outline) enabled + CONFIG_VMAP_STACK enabled. kernel is patched with Christophe's '[v2] powerpc/32s: Fix DSI and ISI exceptions for CONFIG_VMAP_STACK' (https://patchwork.ozlabs.org/patch/1237387/) The kernel loads but booting gets stuck at a stage where the display is initialized but before kernel dmesg gets show (see screenshot). The machine boots with either CONFIG_VMAP_STACK=y or CONFIG_KASAN=y enabled but not with both of them enabled together. -- You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v2 2/4] libnvdimm/namespace: Enforce memremap_compat_align()
Dan Williams writes: > The pmem driver on PowerPC crashes with the following signature when > instantiating misaligned namespaces that map their capacity via > memremap_pages(). > > BUG: Unable to handle kernel data access at 0xc00100040600 > Faulting instruction address: 0xc0090790 > NIP [c0090790] arch_add_memory+0xc0/0x130 > LR [c0090744] arch_add_memory+0x74/0x130 > Call Trace: > arch_add_memory+0x74/0x130 (unreliable) > memremap_pages+0x74c/0xa30 > devm_memremap_pages+0x3c/0xa0 > pmem_attach_disk+0x188/0x770 > nvdimm_bus_probe+0xd8/0x470 > > With the assumption that only memremap_pages() has alignment > constraints, enforce memremap_compat_align() for > pmem_should_map_pages(), nd_pfn, or nd_dax cases. > > Reported-by: Aneesh Kumar K.V > Cc: Jeff Moyer > Reviewed-by: Aneesh Kumar K.V > Link: > https://lore.kernel.org/r/158041477336.3889308.4581652885008605170.st...@dwillia2-desk3.amr.corp.intel.com > Signed-off-by: Dan Williams Reviewed-by: Jeff Moyer
Re: [PATCH v2 3/4] libnvdimm/region: Introduce NDD_LABELING
Dan Williams writes:
> @@ -312,8 +312,9 @@ static ssize_t flags_show(struct device *dev,
> {
> struct nvdimm *nvdimm = to_nvdimm(dev);
>
> - return sprintf(buf, "%s%s\n",
> + return sprintf(buf, "%s%s%s\n",
> test_bit(NDD_ALIASING, >flags) ? "alias " : "",
> + test_bit(NDD_LABELING, >flags) ? "label" : "",
^
Missing a space.
The rest looks sane.
Reviewed-by: Jeff Moyer
[Bug 206525] BUG: KASAN: stack-out-of-bounds in test_bit+0x30/0x44 (kernel 5.6-rc1)
https://bugzilla.kernel.org/show_bug.cgi?id=206525 --- Comment #1 from Erhard F. (erhar...@mailbox.org) --- Created attachment 287359 --> https://bugzilla.kernel.org/attachment.cgi?id=287359=edit kernel .config (5.6.0-rc1, PowerMac G4 DP) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206525] New: BUG: KASAN: stack-out-of-bounds in test_bit+0x30/0x44 (kernel 5.6-rc1)
https://bugzilla.kernel.org/show_bug.cgi?id=206525 Bug ID: 206525 Summary: BUG: KASAN: stack-out-of-bounds in test_bit+0x30/0x44 (kernel 5.6-rc1) Product: Platform Specific/Hardware Version: 2.5 Kernel Version: 5.6.0-rc1 Hardware: PPC-32 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: PPC-32 Assignee: platform_ppc...@kernel-bugs.osdl.org Reporter: erhar...@mailbox.org Regression: No Created attachment 287357 --> https://bugzilla.kernel.org/attachment.cgi?id=287357=edit dmesg (5.6.0-rc1 + v2 Fix DSI and ISI... patch, PowerMac G4 DP) [...] Feb 13 20:18:53 T600 kernel: == Feb 13 20:18:53 T600 kernel: BUG: KASAN: stack-out-of-bounds in test_bit+0x30/0x44 Feb 13 20:18:53 T600 kernel: Read of size 4 at addr ee8bddac by task systemd/1 Feb 13 20:18:53 T600 kernel: Feb 13 20:18:53 T600 kernel: CPU: 0 PID: 1 Comm: systemd Tainted: GW 5.6.0-rc1-PowerMacG4+ #20 Feb 13 20:18:53 T600 kernel: Call Trace: Feb 13 20:18:53 T600 kernel: [ee8bdc38] [c078cf18] dump_stack+0xbc/0x118 (unreliable) Feb 13 20:18:53 T600 kernel: [ee8bdc68] [c0249f94] print_address_description.isra.0+0x3c/0x420 Feb 13 20:18:53 T600 kernel: [ee8bdcf8] [c024a554] __kasan_report+0x138/0x180 Feb 13 20:18:53 T600 kernel: [ee8bdd38] [c0249718] kasan_report+0x7c/0x104 Feb 13 20:18:53 T600 kernel: [ee8bdd58] [c06526b4] test_bit+0x30/0x44 Feb 13 20:18:53 T600 kernel: [ee8bdd78] [c0657c6c] netlink_bind+0x24c/0x33c Feb 13 20:18:53 T600 kernel: [ee8bde18] [c05c0c3c] __sys_bind+0xd4/0x120 Feb 13 20:18:53 T600 kernel: [ee8bdf38] [c001a278] ret_from_syscall+0x0/0x34 Feb 13 20:18:53 T600 kernel: --- interrupt: c01 at 0x4f3ea8 LR = 0x8f5b80 Feb 13 20:18:53 T600 kernel: Feb 13 20:18:53 T600 kernel: The buggy address belongs to the page: Feb 13 20:18:53 T600 kernel: page:ef460a94 refcount:0 mapcount:0 mapping: index:0x0 Feb 13 20:18:53 T600 kernel: flags: 0x0() Feb 13 20:18:53 T600 kernel: raw: ef460a98 ef460a98 Feb 13 20:18:53 T600 kernel: raw: Feb 13 20:18:53 T600 kernel: page dumped because: kasan: bad access detected Feb 13 20:18:53 T600 kernel: Feb 13 20:18:53 T600 kernel: addr ee8bddac is located in stack of task systemd/1 at offset 36 in frame: Feb 13 20:18:53 T600 kernel: netlink_bind+0x0/0x33c Feb 13 20:18:53 T600 kernel: Feb 13 20:18:53 T600 kernel: this frame has 1 object: Feb 13 20:18:53 T600 kernel: [32, 36) 'groups' Feb 13 20:18:53 T600 kernel: Feb 13 20:18:53 T600 kernel: Memory state around the buggy address: Feb 13 20:18:53 T600 kernel: ee8bdc80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Feb 13 20:18:53 T600 kernel: ee8bdd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Feb 13 20:18:53 T600 kernel: >ee8bdd80: 00 f1 f1 f1 f1 04 f3 f3 f3 00 00 00 00 00 00 00 Feb 13 20:18:53 T600 kernel: ^ Feb 13 20:18:53 T600 kernel: ee8bde00: 00 00 00 00 00 f1 f1 f1 f1 04 f2 04 f2 00 00 00 Feb 13 20:18:53 T600 kernel: ee8bde80: 00 00 00 00 00 00 00 00 00 00 00 00 00 f3 f3 f3 Feb 13 20:18:53 T600 kernel: == Happens on my G4 DP with kernel 5.6.0-rc1 and KASAN enabled (outline) during boot. kernel is patched with Christophe's '[v2] powerpc/32s: Fix DSI and ISI exceptions for CONFIG_VMAP_STACK' (https://patchwork.ozlabs.org/patch/1237387/) but CONFIG_VMAP_STACK was not used here. -- You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH] serial: cpm_uart: call cpm_muram_init before registering console
On Thu, Feb 13, 2020 at 12:43:42PM +0100, Rasmus Villemoes wrote: > Christophe reports that powerpc 8xx silently fails to 5.6-rc1. It turns > out I was wrong about nobody relying on the lazy initialization of the > cpm/qe muram in commit b6231ea2b3c6 (soc: fsl: qe: drop broken lazy > call of cpm_muram_init()). > > Rather than reinstating the somewhat dubious lazy call (initializing a > currently held spinlock, and implicitly doing a GFP_KERNEL under that > spinlock), make sure that cpm_muram_init() is called early enough - I > thought the calls from the subsys_initcalls were good enough, but when > used by console drivers, that's obviously not the > case. cpm_muram_init() is safe to call twice (there's an early return > if it is already initialized), so keep the call from cpm_init() - in > case SERIAL_CPM_CONSOLE=n. > > Reported-by: Christophe Leroy > Fixes: b6231ea2b3c6 (soc: fsl: qe: drop broken lazy call of cpm_muram_init()) > Signed-off-by: Rasmus Villemoes > --- > > Christophe, can I get you to add a formal Tested-by? > > I'm not sure which tree this should go through. I can take it, thanks. greg k-h
[Bug 206501] Kernel 5.6-rc1 fails to boot on a PowerMac G4 3,6 with CONFIG_VMAP_STACK=y: Oops! Machine check, sig: 7 [#1]
https://bugzilla.kernel.org/show_bug.cgi?id=206501 --- Comment #10 from Erhard F. (erhar...@mailbox.org) --- Sure. Thanks! -- You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v2 1/4] mm/memremap_pages: Introduce memremap_compat_align()
On Thu, Feb 13, 2020 at 8:58 AM Jeff Moyer wrote: > > Dan Williams writes: > > > The "sub-section memory hotplug" facility allows memremap_pages() users > > like libnvdimm to compensate for hardware platforms like x86 that have a > > section size larger than their hardware memory mapping granularity. The > > compensation that sub-section support affords is being tolerant of > > physical memory resources shifting by units smaller (64MiB on x86) than > > the memory-hotplug section size (128 MiB). Where the platform > > physical-memory mapping granularity is limited by the number and > > capability of address-decode-registers in the memory controller. > > > > While the sub-section support allows memremap_pages() to operate on > > sub-section (2MiB) granularity, the Power architecture may still > > require 16MiB alignment on "!radix_enabled()" platforms. > > > > In order for libnvdimm to be able to detect and manage this per-arch > > limitation, introduce memremap_compat_align() as a common minimum > > alignment across all driver-facing memory-mapping interfaces, and let > > Power override it to 16MiB in the "!radix_enabled()" case. > > > > The assumption / requirement for 16MiB to be a viable > > memremap_compat_align() value is that Power does not have platforms > > where its equivalent of address-decode-registers never hardware remaps a > > persistent memory resource on smaller than 16MiB boundaries. Note that I > > tried my best to not add a new Kconfig symbol, but header include > > entanglements defeated the #ifndef memremap_compat_align design pattern > > and the need to export it defeats the __weak design pattern for arch > > overrides. > > > > Based on an initial patch by Aneesh. > > I have just a couple of questions. > > First, can you please add a comment above the generic implementation of > memremap_compat_align describing its purpose, and why a platform might > want to override it? Sure, how about: /* * The memremap() and memremap_pages() interfaces are alternately used * to map persistent memory namespaces. These interfaces place different * constraints on the alignment and size of the mapping (namespace). * memremap() can map individual PAGE_SIZE pages. memremap_pages() can * only map subsections (2MB), and at least one architecture (PowerPC) * the minimum mapping granularity of memremap_pages() is 16MB. * * The role of memremap_compat_align() is to communicate the minimum * arch supported alignment of a namespace such that it can freely * switch modes without violating the arch constraint. Namely, do not * allow a namespace to be PAGE_SIZE aligned since that namespace may be * reconfigured into a mode that requires SUBSECTION_SIZE alignment. */ > Second, I will take it at face value that the power architecture > requires a 16MB alignment, but it's not clear to me why mmu_linear_psize > was chosen to represent that. What's the relationship, there, and can > we please have a comment explaining it? Aneesh, can you help here?
[Bug 206501] Kernel 5.6-rc1 fails to boot on a PowerMac G4 3,6 with CONFIG_VMAP_STACK=y: Oops! Machine check, sig: 7 [#1]
https://bugzilla.kernel.org/show_bug.cgi?id=206501 --- Comment #9 from Christophe Leroy (christophe.le...@c-s.fr) --- Great. Can we add your Tested-by: to the commit ? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] powerpc: Fix /proc/cpuinfo revision for POWER9P processors
POWER9P PVR bits are same as that of POWER9. Hence mask off only the relevant bits for the major revision similar to POWER9. Without this patch the cpuinfo output shows 17.0 as revision: $ cat /proc/cpuinfo processor : 0 cpu : POWER9P, altivec supported clock : 2950.00MHz revision: 17.0 (pvr 004f 1100) With this change it reflects the correct revision: $ cat /proc/cpuinfo processor : 0 cpu : POWER9P, altivec supported clock : 2633.00MHz revision: 1.0 (pvr 004f 1100) Signed-off-by: Mahesh Salgaonkar --- arch/powerpc/kernel/setup-common.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c index 488f1eecc0de..37342ec42cb3 100644 --- a/arch/powerpc/kernel/setup-common.c +++ b/arch/powerpc/kernel/setup-common.c @@ -315,6 +315,7 @@ static int show_cpuinfo(struct seq_file *m, void *v) min = pvr & 0xFF; break; case 0x004e: /* POWER9 bits 12-15 give chip type */ + case 0x004f: /* POWER9P bits 12-15 give chip type */ maj = (pvr >> 8) & 0x0F; min = pvr & 0xFF; break;
[PATCH] KVM: PPC: Book3S HV: Treat unrecognized TM instructions as illegal
On P9 DD2.2 due to a CPU defect some TM instructions need to be emulated by
KVM. This is handled at first by the hardware raising a softpatch interrupt
when certain TM instructions that need KVM assistance are executed in the
guest. Some TM instructions, although not defined in the Power ISA, might
raise a softpatch interrupt. For instance, 'tresume.' instruction as
defined in the ISA must have bit 31 set (1), but an instruction that
matches 'tresume.' OP and XO opcodes but has bit 31 not set (0), like
0x7cfe9ddc, also raises a softpatch interrupt, for example, if a code
like the following is executed in the guest it will raise a softpatch
interrupt just like a 'tresume.' when the TM facility is enabled:
int main() { asm("tabort. 0; .long 0x7cfe9ddc;"); }
Currently in such a case KVM throws a complete trace like the following:
[345523.705984] WARNING: CPU: 24 PID: 64413 at
arch/powerpc/kvm/book3s_hv_tm.c:211 kvmhv_p9_tm_emulation+0x68/0x620 [kvm_hv]
[345523.705985] Modules linked in: kvm_hv(E) xt_conntrack ipt_REJECT
nf_reject_ipv4 xt_tcpudp ip6table_mangle ip6table_nat
iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4
ebtable_filter ebtables ip6table_filter
ip6_tables iptable_filter bridge stp llc sch_fq_codel ipmi_powernv at24
vmx_crypto ipmi_devintf ipmi_msghandler
ibmpowernv uio_pdrv_genirq kvm opal_prd uio leds_powernv ib_iser rdma_cm iw_cm
ib_cm ib_core iscsi_tcp libiscsi_tcp
libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs blake2b_generic
zstd_compress raid10 raid456
async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor
raid6_pq raid1 raid0 multipath linear tg3
crct10dif_vpmsum crc32c_vpmsum ipr [last unloaded: kvm_hv]
[345523.706030] CPU: 24 PID: 64413 Comm: CPU 0/KVM Tainted: GW E
5.5.0+ #1
[345523.706031] NIP: c008072cb9c0 LR: c008072b5e80 CTR:
c008085c7850
[345523.706034] REGS: c00399467680 TRAP: 0700 Tainted: GW E
(5.5.0+)
[345523.706034] MSR: 90010282b033
CR: 24022428 XER:
[345523.706042] CFAR: c008072b5e7c IRQMASK: 0
GPR00: c008072b5e80 c00399467910 c008072db500
c00375ccc720
GPR04: c00375ccc720 0003fbec a10395dda5a6
GPR08: 7cfe9ddc 7cfe9ddc05dc 7cfe9ddc7c0005dc
c008072cd530
GPR12: c008085c7850 c003fffeb800 0001
7dfb737f
GPR16: c0002001edcca558
0001
GPR20: c1b21258 c0002001edcca558 0018
GPR24: 0100 0001
1500
GPR28: c0002001edcc4278 c0037dd8 80050280f033
c00375ccc720
[345523.706062] NIP [c008072cb9c0] kvmhv_p9_tm_emulation+0x68/0x620 [kvm_hv]
[345523.706065] LR [c008072b5e80] kvmppc_handle_exit_hv.isra.53+0x3e8/0x798
[kvm_hv]
[345523.706066] Call Trace:
[345523.706069] [c00399467910] [c00399467940] 0xc00399467940
(unreliable)
[345523.706071] [c00399467950] [c00399467980] 0xc00399467980
[345523.706075] [c003994679f0] [c008072bd1c4]
kvmhv_run_single_vcpu+0xa1c/0xb80 [kvm_hv]
[345523.706079] [c00399467ac0] [c008072bd8e0]
kvmppc_vcpu_run_hv+0x5b8/0xb00 [kvm_hv]
[345523.706087] [c00399467b90] [c008085c93cc] kvmppc_vcpu_run+0x34/0x48
[kvm]
[345523.706095] [c00399467bb0] [c008085c582c]
kvm_arch_vcpu_ioctl_run+0x244/0x420 [kvm]
[345523.706101] [c00399467c40] [c008085b7498]
kvm_vcpu_ioctl+0x3d0/0x7b0 [kvm]
[345523.706105] [c00399467db0] [c04adf9c] ksys_ioctl+0x13c/0x170
[345523.706107] [c00399467e00] [c04adff8] sys_ioctl+0x28/0x80
[345523.706111] [c00399467e20] [c000b278] system_call+0x5c/0x68
[345523.706112] Instruction dump:
[345523.706114] 419e0390 7f8a4840 409d0048 6d497c00 2f89075d 419e021c 6d497c00
2f8907dd
[345523.706119] 419e01c0 6d497c00 2f8905dd 419e00a4 <0fe0> 38210040
3860 ebc1fff0
and then treats the executed instruction as 'nop' whilst it should actually
be treated as an illegal instruction since it's not defined by the ISA.
This commit changes the handling of the case above by treating the
unrecognized TM instructions that can raise a softpatch but are not
defined in the ISA as illegal ones instead of as 'nop' and by gently
reporting it to the host instead of throwing a trace.
Signed-off-by: Gustavo Romero
---
arch/powerpc/kvm/book3s_hv_tm.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_hv_tm.c b/arch/powerpc/kvm/book3s_hv_tm.c
index 0db937497169..d342a9e11298 100644
--- a/arch/powerpc/kvm/book3s_hv_tm.c
+++ b/arch/powerpc/kvm/book3s_hv_tm.c
@@ -3,6 +3,8 @@
* Copyright 2017 Paul Mackerras, IBM Corp.
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
@@ -208,6 +210,8
Re: RESEND: Re: Problem booting a PowerBook G4 Aluminum after commit cd08f109 with CONFIG_VMAP_STACK=y
On 02/13/2020 02:28 PM, Larry Finger wrote: On 2/11/20 1:23 PM, Christophe Leroy wrote: Can you send me a picture of that BUG Unable to handle kernel data access with all the registers values etc..., together with the matching vmlinux ? First thing is to identify where we are when that happens. That mean see what is at 0xc0013674. Can be done with 'ppc-linux-objdump -d vmlinux' (Or whatever your PPC objdump is named) and get the function code. Then we need to understand how we reach that function and why it tries to access a physical address. Another thing I'm thinking about, not necessarily related to that problem: Some buggy drivers do DMA from stack. This doesn't work anymore with CONFIG_VMAP_STACK. Most of them can be detected with CONFIG_DEBUG_VIRTUAL so you should activate it. Christophe, The previous send of this message failed because the attached vmlinux was too large. I have gone about as far as I can in debugging the problem. Setting CONFIG_DEBUG_VIRTUAL made no difference. Attached are the final screenshot, and the patches that I have applied. You already have the gzipped vmlinux. This screenshot makes more sense with the vmlinux you provided, problem at 0xc00136dc. That's in function power_save_ppc32_restore() in arch/powerpc/kernel/idle_6xx.S. c00136c0 : c00136c0: 81 2b 00 a0 lwz r9,160(r11) c00136c4: 91 2b 00 90 stw r9,144(r11) c00136c8: 39 60 00 00 li r11,0 c00136cc: 7d 30 fa a6 mfspr r9,1008 c00136d0: 75 29 00 40 andis. r9,r9,64 c00136d4: 41 82 00 18 beq c00136ec c00136d8: 3d 2b 00 7c addis r9,r11,124 >> c00136dc: 81 29 92 5c lwz r9,-28068(r9) c00136e0: 7d 36 fb a6 mtspr 1014,r9 c00136e4: 7c 00 04 ac hwsync c00136e8: 4c 00 01 2c isync c00136ec: 3d 2b 00 7c addis r9,r11,124 c00136f0: 81 29 92 60 lwz r9,-28064(r9) c00136f4: 7d 31 fb a6 mtspr 1009,r9 c00136f8: 48 00 19 c4 b c00150bc c00136fc: 00 00 00 00 .long 0x0 Can you try the change below (won't work anymore without CONFIG_VMAP_STACK, will fix it properly later when you confirm it is OK). diff --git a/arch/powerpc/kernel/idle_6xx.S b/arch/powerpc/kernel/idle_6xx.S index 0ffdd18b9f26..7be8a0f3fac8 100644 --- a/arch/powerpc/kernel/idle_6xx.S +++ b/arch/powerpc/kernel/idle_6xx.S @@ -166,7 +166,7 @@ BEGIN_FTR_SECTION mfspr r9,SPRN_HID0 andis. r9,r9,HID0_NAP@h beq 1f - addis r9,r11,(nap_save_msscr0-KERNELBASE)@ha + addis r9,r11,nap_save_msscr0@ha lwz r9,nap_save_msscr0@l(r9) mtspr SPRN_MSSCR0, r9 sync @@ -174,7 +174,7 @@ BEGIN_FTR_SECTION 1: END_FTR_SECTION_IFSET(CPU_FTR_NAP_DISABLE_L2_PR) BEGIN_FTR_SECTION - addis r9,r11,(nap_save_hid1-KERNELBASE)@ha + addis r9,r11,nap_save_hid1@ha lwz r9,nap_save_hid1@l(r9) mtspr SPRN_HID1, r9 END_FTR_SECTION_IFSET(CPU_FTR_DUAL_PLL_750FX) Thanks Christophe
Re: [PATCH] serial: cpm_uart: call cpm_muram_init before registering console
Le 13/02/2020 à 12:43, Rasmus Villemoes a écrit :
Christophe reports that powerpc 8xx silently fails to 5.6-rc1. It turns
out I was wrong about nobody relying on the lazy initialization of the
cpm/qe muram in commit b6231ea2b3c6 (soc: fsl: qe: drop broken lazy
call of cpm_muram_init()).
Rather than reinstating the somewhat dubious lazy call (initializing a
currently held spinlock, and implicitly doing a GFP_KERNEL under that
spinlock), make sure that cpm_muram_init() is called early enough - I
thought the calls from the subsys_initcalls were good enough, but when
used by console drivers, that's obviously not the
case. cpm_muram_init() is safe to call twice (there's an early return
if it is already initialized), so keep the call from cpm_init() - in
case SERIAL_CPM_CONSOLE=n.
Reported-by: Christophe Leroy
Fixes: b6231ea2b3c6 (soc: fsl: qe: drop broken lazy call of cpm_muram_init())
Signed-off-by: Rasmus Villemoes
Tested-by: Christophe Leroy
---
Christophe, can I get you to add a formal Tested-by?
I'm not sure which tree this should go through.
drivers/tty/serial/cpm_uart/cpm_uart_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/cpm_uart/cpm_uart_core.c
b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
index 19d5a4cf29a6..d4b81b06e0cb 100644
--- a/drivers/tty/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
@@ -1373,6 +1373,7 @@ static struct console cpm_scc_uart_console = {
static int __init cpm_uart_console_init(void)
{
+ cpm_muram_init();
register_console(_scc_uart_console);
return 0;
}
[PATCH] serial: cpm_uart: call cpm_muram_init before registering console
Christophe reports that powerpc 8xx silently fails to 5.6-rc1. It turns
out I was wrong about nobody relying on the lazy initialization of the
cpm/qe muram in commit b6231ea2b3c6 (soc: fsl: qe: drop broken lazy
call of cpm_muram_init()).
Rather than reinstating the somewhat dubious lazy call (initializing a
currently held spinlock, and implicitly doing a GFP_KERNEL under that
spinlock), make sure that cpm_muram_init() is called early enough - I
thought the calls from the subsys_initcalls were good enough, but when
used by console drivers, that's obviously not the
case. cpm_muram_init() is safe to call twice (there's an early return
if it is already initialized), so keep the call from cpm_init() - in
case SERIAL_CPM_CONSOLE=n.
Reported-by: Christophe Leroy
Fixes: b6231ea2b3c6 (soc: fsl: qe: drop broken lazy call of cpm_muram_init())
Signed-off-by: Rasmus Villemoes
---
Christophe, can I get you to add a formal Tested-by?
I'm not sure which tree this should go through.
drivers/tty/serial/cpm_uart/cpm_uart_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/cpm_uart/cpm_uart_core.c
b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
index 19d5a4cf29a6..d4b81b06e0cb 100644
--- a/drivers/tty/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
@@ -1373,6 +1373,7 @@ static struct console cpm_scc_uart_console = {
static int __init cpm_uart_console_init(void)
{
+ cpm_muram_init();
register_console(_scc_uart_console);
return 0;
}
--
2.23.0
Re: [PATCH v7 4/4] powerpc: Book3S 64-bit "heavyweight" KASAN support
Le 13/02/2020 à 01:47, Daniel Axtens a écrit : diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 497b7d0b2d7e..f1c54c08a88e 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -169,7 +169,9 @@ config PPC select HAVE_ARCH_HUGE_VMAP if PPC_BOOK3S_64 && PPC_RADIX_MMU select HAVE_ARCH_JUMP_LABEL select HAVE_ARCH_KASAN if PPC32 + select HAVE_ARCH_KASAN if PPC_BOOK3S_64 && PPC_RADIX_MMU That's probably detail, but as it is necessary to deeply define the HW when selecting that (I mean giving the exact amount of memory and with restrictions like having a wholeblock memory), should it also depend of EXPERT ? select HAVE_ARCH_KASAN_VMALLOC if PPC32 + select HAVE_ARCH_KASAN_VMALLOC if PPC_BOOK3S_64 && PPC_RADIX_MMU Maybe we could have - select HAVE_ARCH_KASAN_VMALLOC if PPC32 + select HAVE_ARCH_KASAN_VMALLOC if HAVE_ARCH_KASAN select HAVE_ARCH_KGDB select HAVE_ARCH_MMAP_RND_BITS select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT Christophe
[Bug 206501] Kernel 5.6-rc1 fails to boot on a PowerMac G4 3,6 with CONFIG_VMAP_STACK=y: Oops! Machine check, sig: 7 [#1]
https://bugzilla.kernel.org/show_bug.cgi?id=206501 --- Comment #8 from Erhard F. (erhar...@mailbox.org) --- (In reply to Christophe Leroy from comment #7) > Can you try version v2 of the patch, > https://patchwork.ozlabs.org/patch/1237387/ I can confirm that v2 works as intended. The G4 completes booting with VMAP_STACK enabled and without producing further stack traces. Thanks! -- You are receiving this mail because: You are watching the assignee of the bug.
Re: Problem booting a PowerBook G4 Aluminum after commit cd08f109 with CONFIG_VMAP_STACK=y
On 02/12/2020 11:02 PM, Larry Finger wrote: On 2/11/20 1:23 PM, Christophe Leroy wrote: Can you send me a picture of that BUG Unable to handle kernel data access with all the registers values etc..., together with the matching vmlinux ? The vmlinux file was too big for your mailbox. You can download it from http://www.lwfinger.com/download/vmlinux.gz Hi, Is that the vmlinux that corresponds to: BUG Unable to handle kernel data access at 0x007a84fc. The faulting instruction address was 0x00013674 Nevertheless, do you have a picture of the said BUG/Oops to see all registers ? Because here, the address 0x13674 is not a data access: c00135ec : c00135ec: 3c 60 00 00 lis r3,0 c00135f0: 3c 60 00 80 lis r3,128 c00135f4: 3c 80 c0 83 lis r4,-16253 c00135f8: 80 84 f2 80 lwz r4,-3456(r4) c00135fc: 80 84 00 0c lwz r4,12(r4) c0013600: 70 80 00 08 andi. r0,r4,8 c0013604: 41 82 00 18 beq c001361c c0013608: 3c 80 c0 84 lis r4,-16252 c001360c: 80 84 30 34 lwz r4,12340(r4) c0013610: 2c 04 00 00 cmpwi r4,0 c0013614: 41 82 00 08 beq c001361c c0013618: 3c 60 00 40 lis r3,64 c001361c: 2c 03 00 00 cmpwi r3,0 c0013620: 4d 82 00 20 beqlr c0013624: 74 60 00 40 andis. r0,r3,64 c0013628: 41 82 00 30 beq c0013658 c001362c: 7c 96 fa a6 mfspr r4,1014 c0013630: 54 84 00 3a rlwinm r4,r4,0,0,29 c0013634: 7c 00 04 ac hwsync c0013638: 7c 96 fb a6 mtspr 1014,r4 c001363c: 7c 00 04 ac hwsync c0013640: 4c 00 01 2c isync c0013644: 3c 80 c0 00 lis r4,-16384 c0013648: 7c 00 20 ac dcbf0,r4 c001364c: 7c 00 20 ac dcbf0,r4 c0013650: 7c 00 20 ac dcbf0,r4 c0013654: 7c 00 20 ac dcbf0,r4 c0013658: 3c 80 c0 7c lis r4,-16260 c001365c: 80 84 92 64 lwz r4,-28060(r4) c0013660: 2c 04 00 00 cmpwi r4,0 c0013664: 41 82 00 10 beq c0013674 c0013668: 7c 91 fa a6 mfspr r4,1009 c001366c: 64 84 00 01 orisr4,r4,1 c0013670: 7c 91 fb a6 mtspr 1009,r4 >> c0013674: 7c 90 fa a6 mfspr r4,1008 c0013678: 3c a0 00 60 lis r5,96 c001367c: 64 a5 00 80 orisr5,r5,128 c0013680: 7c 84 28 78 andcr4,r4,r5 c0013684: 7c 84 1b 78 or r4,r4,r3 c0013688: 64 84 00 10 orisr4,r4,16 c001368c: 7c 90 fb a6 mtspr 1008,r4 c0013690: 7e 00 06 6c dssall c0013694: 7c 00 04 ac hwsync c0013698: 81 02 00 04 lwz r8,4(r2) c001369c: 61 08 00 01 ori r8,r8,1 c00136a0: 91 02 00 04 stw r8,4(r2) c00136a4: 7c e0 00 a6 mfmsr r7 c00136a8: 60 e7 80 00 ori r7,r7,32768 c00136ac: 64 e7 00 04 orisr7,r7,4 c00136b0: 7c 00 04 ac hwsync c00136b4: 7c e0 01 24 mtmsr r7 c00136b8: 4c 00 01 2c isync c00136bc: 4b ff ff f4 b c00136b0 Thanks Christophe
Re: [PATCH 10/18] powerpc: Replace setup_irq() by request_irq()
Le 12/02/2020 à 09:04, afzal mohammed a écrit : request_irq() is preferred over setup_irq(). Existing callers of setup_irq() reached mostly via 'init_IRQ()' & 'time_init()', while memory allocators are ready by 'mm_init()'. 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(). Seldom remove_irq() usage has been observed coupled with setup_irq(), wherever that has been found, it too has been replaced by free_irq(). [1] https://lkml.kernel.org/r/alpine.DEB.2.20.1710191609480.1971@nanos Signed-off-by: afzal mohammed Tested-by: Christophe Leroy # for the 8xx parts --- Since cc'ing cover letter to all maintainers/reviewers would be too many, refer for cover letter, https://lkml.kernel.org/r/cover.1581478323.git.afzal.mohd...@gmail.com arch/powerpc/platforms/85xx/mpc85xx_cds.c | 10 +++- arch/powerpc/platforms/8xx/cpm1.c | 9 ++- arch/powerpc/platforms/8xx/m8xx_setup.c | 9 ++- arch/powerpc/platforms/chrp/setup.c | 14 -- arch/powerpc/platforms/powermac/pic.c | 31 ++- arch/powerpc/platforms/powermac/smp.c | 9 ++- 6 files changed, 27 insertions(+), 55 deletions(-)
Re: [Regression 5.6-rc1][Bisected b6231ea2b3c6] Powerpc 8xx doesn't boot anymore
Le 13/02/2020 à 10:37, Rasmus Villemoes a écrit :
On 12/02/2020 15.50, Christophe Leroy wrote:
On 02/12/2020 02:24 PM, Christophe Leroy wrote:
In your commit text you explain that cpm_muram_init() is called via
subsys_initcall. But console init is done before that, so it cannot work.
Do you have a fix for that ?
The following patch allows powerpc 8xx to boot again. Don't know if
that's the good place and way to do the fix though.
---
diff --git a/drivers/tty/serial/cpm_uart/cpm_uart_core.c
b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
index 4cabded8390b..341d682ec6eb 100644
--- a/drivers/tty/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
@@ -1351,6 +1351,7 @@ static int __init cpm_uart_console_setup(struct
console *co, char *options)
clrbits32(>sccp->scc_gsmrl, SCC_GSMRL_ENR | SCC_GSMRL_ENT);
}
+ cpm_muram_init();
ret = cpm_uart_allocbuf(pinfo, 1);
if (ret)
Hmm, that seems to be a somewhat random place, making it hard to see
that it is indeed early enough. Would it work to put it inside the
console_initcall that registers the cpm console? I.e.
static int __init cpm_uart_console_init(void)
{
+ cpm_muram_init();
register_console(_scc_uart_console);
return 0;
}
console_initcall(cpm_uart_console_init);
Yes that works too.
Thanks
Christophe
[Bug 206501] Kernel 5.6-rc1 fails to boot on a PowerMac G4 3,6 with CONFIG_VMAP_STACK=y: Oops! Machine check, sig: 7 [#1]
https://bugzilla.kernel.org/show_bug.cgi?id=206501 --- Comment #7 from Christophe Leroy (christophe.le...@c-s.fr) --- Can you try version v2 of the patch, https://patchwork.ozlabs.org/patch/1237387/ -- You are receiving this mail because: You are watching the assignee of the bug.
Re: [Regression 5.6-rc1][Bisected b6231ea2b3c6] Powerpc 8xx doesn't boot anymore
On 02/13/2020 07:45 AM, Rasmus Villemoes wrote:
On 12/02/2020 15.24, Christophe Leroy wrote:
Hi Rasmus,
Kernel 5.6-rc1 silently fails on boot.
I bisected the problem to commit b6231ea2b3c6 ("soc: fsl: qe: drop
broken lazy call of cpm_muram_init()")
I get a bad_page_fault() for an access at address 8 in
cpm_muram_alloc_common(), called from cpm_uart_console_setup() via
cpm_uart_allocbuf()
Sorry about that. But I'm afraid I don't see what I could have done
differently - the patch series, including b6231ea2b3c6, has been in
-next since 20191210, both you and ppc-dev were cc'ed on the entire
series (last revision sent November 28). And I've been dogfooding the
patches on both arm- and ppc-derived boards ever since (but obviously
only for a few cpus).
Yes, this patch series should have ringed a bell in my head, looks like
I'm the one who introduced this 4 years ago through commit 4d486e008379
("soc/fsl/qe: fix Oops on CPM1 (and likely CPM2)")
But I had completely forgotten that patch until I did some git blame
this morning on this lazy call.
Reverting the guilty commit on top of 5.6-rc1 is not trivial.
In your commit text you explain that cpm_muram_init() is called via
subsys_initcall. But console init is done before that, so it cannot work.
No, but neither did the code I removed seem to work - how does doing
spin_lock_init on a held spinlock, and then unlocking it, work? Is
everything-spinlock always a no-op in your configuration? And even so,
I'd think a GFP_KERNEL allocation under spin_lock_irqsave() would
trigger some splat somewhere?
Please note I'm not claiming my patch is not at fault, it clearly is, I
just want to try to understand how I could have been wrong about the
"nobody can have been relying on it" part.
It seems spin_lock_init() does just nothing.
spin_lock_irqsave() just disable IRQs and increases preempt_count.
spin_lock_irqrestore() restore IRQ state, decreace preempt_count and
call preempt_schedule if preempt_count reaches 0.
Maybe with some debugging options like DEBUG_ATOMIC_SLEEP could detect it ?
Do you have a fix for that ?
Not right now, but I'll have a look. It's true that the patch probably
doesn't revert cleanly, but it shouldn't be hard to add back those few
lines in the appropriate spot, with a big fat comment that this does
something very fishy (at least as a temporary measure if we don't find a
proper solution soonish).
Thanks
Christophe
[PATCH v2] powerpc/32s: Fix DSI and ISI exceptions for CONFIG_VMAP_STACK
hash_page() needs to read page tables from kernel memory. When entire
kernel memory is mapped by BATs, which is normally the case when
CONFIG_STRICT_KERNEL_RWX is not set, it works even if the page hosting
the page table is not referenced in the MMU hash table.
However, if the page where the page table resides is not covered by
a BAT, a DSI fault can be encountered from hash_page(), and it loops
forever. This can happen when CONFIG_STRICT_KERNEL_RWX is selected
and the alignment of the different regions is too small to allow
covering the entire memory with BATs. This also happens when
CONFIG_DEBUG_PAGEALLOC is selected or when booting with 'nobats'
flag.
Also, if the page containing the kernel stack is not present in the
MMU hash table, registers cannot be saved and a recursive DSI fault
is encountered.
To allow hash_page() to properly do its job at all time and load the
MMU hash table whenever needed, it must run with data MMU disabled.
This means it must be called before re-enabling data MMU. To allow
this, registers clobbered by hash_page() and create_hpte() have to
be saved in the thread struct together with SRR0, SSR1, DAR and DSISR.
It is also necessary to ensure that DSI prolog doesn't overwrite
regs saved by prolog of the current running exception. That means:
- DSI can only use SPRN_SPRG_SCRATCH0
- Exceptions must free SPRN_SPRG_SCRATCH0 before writing to the stack.
This also fixes the Oops reported by Erhard when create_hpte() is
called by add_hash_page().
Fixes: cd08f109e262 ("powerpc/32s: Enable CONFIG_VMAP_STACK")
Reported-by: Erhard F.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206501
Signed-off-by: Christophe Leroy
---
v2: Reworked the DSI to call hash_page() even earlier and without
cloberring what ongoing exception saved in SPRG registers and
thread struct.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/processor.h | 4 +
arch/powerpc/kernel/asm-offsets.c| 12 +++
arch/powerpc/kernel/head_32.S| 138 ++-
arch/powerpc/kernel/head_32.h| 13 ++-
arch/powerpc/mm/book3s32/hash_low.S | 52 +-
arch/powerpc/mm/book3s32/mmu.c | 7 +-
6 files changed, 189 insertions(+), 37 deletions(-)
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm/processor.h
index 8387698bd5b6..eedcbfb9a6ff 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -168,6 +168,10 @@ struct thread_struct {
unsigned long srr1;
unsigned long dar;
unsigned long dsisr;
+#ifdef CONFIG_PPC_BOOK3S_32
+ unsigned long r0, r3, r4, r5, r6, r8, r9, r11;
+ unsigned long lr, ctr;
+#endif
#endif
/* Debug Registers */
struct debug_reg debug;
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index c25e562f1cd9..fcf24a365fc0 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -132,6 +132,18 @@ int main(void)
OFFSET(SRR1, thread_struct, srr1);
OFFSET(DAR, thread_struct, dar);
OFFSET(DSISR, thread_struct, dsisr);
+#ifdef CONFIG_PPC_BOOK3S_32
+ OFFSET(THR0, thread_struct, r0);
+ OFFSET(THR3, thread_struct, r3);
+ OFFSET(THR4, thread_struct, r4);
+ OFFSET(THR5, thread_struct, r5);
+ OFFSET(THR6, thread_struct, r6);
+ OFFSET(THR8, thread_struct, r8);
+ OFFSET(THR9, thread_struct, r9);
+ OFFSET(THR11, thread_struct, r11);
+ OFFSET(THLR, thread_struct, lr);
+ OFFSET(THCTR, thread_struct, ctr);
+#endif
#endif
#ifdef CONFIG_SPE
OFFSET(THREAD_EVR0, thread_struct, evr[0]);
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index 0493fcac6409..5e1f0a796ec6 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -301,6 +301,39 @@ MachineCheck:
. = 0x300
DO_KVM 0x300
DataAccess:
+#ifdef CONFIG_VMAP_STACK
+ mtspr SPRN_SPRG_SCRATCH0,r10
+ mfspr r10, SPRN_SPRG_THREAD
+BEGIN_MMU_FTR_SECTION
+ stw r11, THR11(r10)
+ mfspr r10, SPRN_DSISR
+ mfcrr11
+#ifdef CONFIG_PPC_KUAP
+ andis. r10, r10, (DSISR_BAD_FAULT_32S | DSISR_DABRMATCH |
DSISR_PROTFAULT)@h
+#else
+ andis. r10, r10, (DSISR_BAD_FAULT_32S | DSISR_DABRMATCH)@h
+#endif
+ mfspr r10, SPRN_SPRG_THREAD
+ beq hash_page_dsi
+.Lhash_page_dsi_cont:
+ mtcrr11
+ lwz r11, THR11(r10)
+END_MMU_FTR_SECTION_IFSET(MMU_FTR_HPTE_TABLE)
+ mtspr SPRN_SPRG_SCRATCH1,r11
+ mfspr r11, SPRN_DAR
+ stw r11, DAR(r10)
+ mfspr r11, SPRN_DSISR
+ stw r11, DSISR(r10)
+ mfspr r11, SPRN_SRR0
+ stw r11, SRR0(r10)
+ mfspr r11, SPRN_SRR1 /* check whether user or kernel */
+ stw r11, SRR1(r10)
+ mfcrr10
+ andi. r11, r11, MSR_PR
+
+ EXCEPTION_PROLOG_1
+ b
[PATCH v2] powerpc/time: Replace by
The PowerPC time code is not a clock provider, and just needs to call of_clk_init(). Hence it can include instead of . Remove the #ifdef protecting the of_clk_init() call, as a stub is available for the !CONFIG_COMMON_CLK case. Signed-off-by: Geert Uytterhoeven Reviewed-by: Stephen Boyd --- v2: - Add Reviewed-by, - Remove #ifdef. --- arch/powerpc/kernel/time.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c index 1168e8b37e30696d..8ce3fa8a8c0a2d63 100644 --- a/arch/powerpc/kernel/time.c +++ b/arch/powerpc/kernel/time.c @@ -50,7 +50,7 @@ #include #include #include -#include +#include #include #include #include @@ -1158,9 +1158,7 @@ void __init time_init(void) init_decrementer_clockevent(); tick_setup_hrtimer_broadcast(); -#ifdef CONFIG_COMMON_CLK of_clk_init(NULL); -#endif } /* -- 2.17.1
Re: [Regression 5.6-rc1][Bisected b6231ea2b3c6] Powerpc 8xx doesn't boot anymore
On 12/02/2020 15.50, Christophe Leroy wrote:
>
>
> On 02/12/2020 02:24 PM, Christophe Leroy wrote:
>> In your commit text you explain that cpm_muram_init() is called via
>> subsys_initcall. But console init is done before that, so it cannot work.
>>
>> Do you have a fix for that ?
>>
>
> The following patch allows powerpc 8xx to boot again. Don't know if
> that's the good place and way to do the fix though.
>
> ---
> diff --git a/drivers/tty/serial/cpm_uart/cpm_uart_core.c
> b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
> index 4cabded8390b..341d682ec6eb 100644
> --- a/drivers/tty/serial/cpm_uart/cpm_uart_core.c
> +++ b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
> @@ -1351,6 +1351,7 @@ static int __init cpm_uart_console_setup(struct
> console *co, char *options)
> clrbits32(>sccp->scc_gsmrl, SCC_GSMRL_ENR | SCC_GSMRL_ENT);
> }
>
> + cpm_muram_init();
> ret = cpm_uart_allocbuf(pinfo, 1);
>
> if (ret)
Hmm, that seems to be a somewhat random place, making it hard to see
that it is indeed early enough. Would it work to put it inside the
console_initcall that registers the cpm console? I.e.
static int __init cpm_uart_console_init(void)
{
+ cpm_muram_init();
register_console(_scc_uart_console);
return 0;
}
console_initcall(cpm_uart_console_init);
Rasmus
Re: [PATCH v5 01/10] capabilities: introduce CAP_PERFMON to kernel and user space
On 12.02.2020 20:09, Stephen Smalley wrote:
> On 2/12/20 11:56 AM, Alexey Budankov wrote:
>>
>>
>> On 12.02.2020 18:45, Stephen Smalley wrote:
>>> On 2/12/20 10:21 AM, Stephen Smalley wrote:
On 2/12/20 8:53 AM, Alexey Budankov wrote:
> On 12.02.2020 16:32, Stephen Smalley wrote:
>> On 2/12/20 3:53 AM, Alexey Budankov wrote:
>>> Hi Stephen,
>>>
>>> On 22.01.2020 17:07, Stephen Smalley wrote:
On 1/22/20 5:45 AM, Alexey Budankov wrote:
>
> On 21.01.2020 21:27, Alexey Budankov wrote:
>>
>> On 21.01.2020 20:55, Alexei Starovoitov wrote:
>>> On Tue, Jan 21, 2020 at 9:31 AM Alexey Budankov
>>> wrote:
On 21.01.2020 17:43, Stephen Smalley wrote:
> On 1/20/20 6:23 AM, Alexey Budankov wrote:
>>
>>>
>> Introduce CAP_PERFMON capability designed to secure system
>> performance
>
> Why _noaudit()? Normally only used when a permission failure is
> non-fatal to the operation. Otherwise, we want the audit message.
>
> So far so good, I suggest using the simplest version for v6:
>
> static inline bool perfmon_capable(void)
> {
> return capable(CAP_PERFMON) || capable(CAP_SYS_ADMIN);
> }
>
> It keeps the implementation simple and readable. The implementation
> is more
> performant in the sense of calling the API - one capable() call for
> CAP_PERFMON
> privileged process.
>
> Yes, it bloats audit log for CAP_SYS_ADMIN privileged and
> unprivileged processes,
> but this bloating also advertises and leverages using more secure
> CAP_PERFMON
> based approach to use perf_event_open system call.
I can live with that. We just need to document that when you see both
a CAP_PERFMON and a CAP_SYS_ADMIN audit message for a process, try
only allowing CAP_PERFMON first and see if that resolves the issue.
We have a similar issue with CAP_DAC_READ_SEARCH versus
CAP_DAC_OVERRIDE.
>>>
>>> I am trying to reproduce this double logging with CAP_PERFMON.
>>> I am using the refpolicy version with enabled perf_event tclass [1], in
>>> permissive mode.
>>> When running perf stat -a I am observing this AVC audit messages:
>>>
>>> type=AVC msg=audit(1581496695.666:8691): avc: denied { open } for
>>> pid=2779 comm="perf" scontext=user_u:user_r:user_systemd_t
>>> tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
>>> type=AVC msg=audit(1581496695.666:8691): avc: denied { kernel } for
>>> pid=2779 comm="perf" scontext=user_u:user_r:user_systemd_t
>>> tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
>>> type=AVC msg=audit(1581496695.666:8691): avc: denied { cpu } for
>>> pid=2779 comm="perf" scontext=user_u:user_r:user_systemd_t
>>> tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
>>> type=AVC msg=audit(1581496695.666:8692): avc: denied { write } for
>>> pid=2779 comm="perf" scontext=user_u:user_r:user_systemd_t
>>> tcontext=user_u:user_r:user_systemd_t tclass=perf_event permissive=1
>>>
>>> However there is no capability related messages around. I suppose my
>>> refpolicy should
>>> be modified somehow to observe capability related AVCs.
>>>
>>> Could you please comment or clarify on how to enable caps related AVCs
>>> in order
>>> to test the concerned logging.
>>
>> The new perfmon permission has to be defined in your policy; you'll have
>> a message in dmesg about "Permission perfmon in class capability2 not
>> defined in policy.". You can either add it to the common cap2
>> definition in refpolicy/policy/flask/access_vectors and rebuild your
>> policy or extract your base module as CIL, add it there, and insert the
>> updated module.
>
> Yes, I already have it like this:
> common cap2
> {
> <-->mac_override<--># unused by SELinux
> <-->mac_admin
> <-->syslog
> <-->wake_alarm
> <-->block_suspend
> <-->audit_read
> <-->perfmon
> }
>
> dmesg stopped reporting perfmon as not defined but audit.log still
> doesn't report CAP_PERFMON denials.
> BTW, audit even doesn't report CAP_SYS_ADMIN denials, however
> perfmon_capable() does check for it.
Some denials may be silenced by dontaudit rules; semodule -DB will strip
those and semodule -B will restore them. Other possibility is that the
process doesn't have CAP_PERFMON in its effective set and therefore never
reaches SELinux at all; denied first by the capability module.
>>>
>>> Also, the fact that your denials are showing up in
