* Re: [patch V2 20/23] PCI/MSI: Move msi_lock to struct pci_dev
From: Greg Kroah-Hartman @ 2021-12-07 7:47 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-hyperv, linux-mips, Paul Mackerras, sparclinux, Wei Liu,
Ashok Raj, x86, Christian Borntraeger, Bjorn Helgaas, Megha Dey,
Jason Gunthorpe, linux-pci, xen-devel, ath11k, Kevin Tian,
Heiko Carstens, Alex Williamson, Cedric Le Goater, Kalle Valo,
Juergen Gross, Thomas Bogendoerfer, LKML, Marc Zygnier,
linuxppc-dev
In-Reply-To: <20211206210224.925241961@linutronix.de>
On Mon, Dec 06, 2021 at 11:27:56PM +0100, Thomas Gleixner wrote:
> It's only required for PCI/MSI. So no point in having it in every struct
> device.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Yes!!!
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [patch V2 21/23] PCI/MSI: Make pci_msi_domain_check_cap() static
From: Greg Kroah-Hartman @ 2021-12-07 7:47 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-hyperv, linux-mips, Paul Mackerras, sparclinux, Wei Liu,
Ashok Raj, x86, Christian Borntraeger, Bjorn Helgaas, Megha Dey,
Jason Gunthorpe, linux-pci, xen-devel, ath11k, Kevin Tian,
Heiko Carstens, Alex Williamson, Cedric Le Goater, Kalle Valo,
Juergen Gross, Thomas Bogendoerfer, LKML, Marc Zygnier,
linuxppc-dev
In-Reply-To: <20211206210224.980989243@linutronix.de>
On Mon, Dec 06, 2021 at 11:27:57PM +0100, Thomas Gleixner wrote:
> No users outside of that file.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Tested-by: Juergen Gross <jgross@suse.com>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [patch V2 22/23] genirq/msi: Handle PCI/MSI allocation fail in core code
From: Greg Kroah-Hartman @ 2021-12-07 7:48 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-hyperv, linux-mips, Paul Mackerras, sparclinux, Wei Liu,
Ashok Raj, x86, Christian Borntraeger, Bjorn Helgaas, Megha Dey,
Jason Gunthorpe, linux-pci, xen-devel, ath11k, Kevin Tian,
Heiko Carstens, Alex Williamson, Cedric Le Goater, Kalle Valo,
Juergen Gross, Thomas Bogendoerfer, LKML, Marc Zygnier,
linuxppc-dev
In-Reply-To: <20211206210225.046615302@linutronix.de>
On Mon, Dec 06, 2021 at 11:27:59PM +0100, Thomas Gleixner wrote:
> Get rid of yet another irqdomain callback and let the core code return the
> already available information of how many descriptors could be allocated.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Tested-by: Juergen Gross <jgross@suse.com>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [patch V2 23/23] PCI/MSI: Move descriptor counting on allocation fail to the legacy code
From: Greg Kroah-Hartman @ 2021-12-07 7:48 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-hyperv, linux-mips, Paul Mackerras, sparclinux, Wei Liu,
Ashok Raj, x86, Christian Borntraeger, Bjorn Helgaas, Megha Dey,
Jason Gunthorpe, linux-pci, xen-devel, ath11k, Kevin Tian,
Heiko Carstens, Alex Williamson, Cedric Le Goater, Kalle Valo,
Juergen Gross, Thomas Bogendoerfer, LKML, Marc Zygnier,
linuxppc-dev
In-Reply-To: <20211206210225.101336873@linutronix.de>
On Mon, Dec 06, 2021 at 11:28:00PM +0100, Thomas Gleixner wrote:
> The irqdomain code already returns the information. Move the loop to the
> legacy code.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Tested-by: Juergen Gross <jgross@suse.com>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH v5 5/5] powerpc/inst: Optimise copy_inst_from_kernel_nofault()
From: Christophe Leroy @ 2021-12-07 7:55 UTC (permalink / raw)
To: Nathan Chancellor
Cc: kbuild-all@lists.01.org, kernel test robot, llvm@lists.linux.dev,
Nick Desaulniers, linux-kernel@vger.kernel.org, Paul Mackerras,
Bill Wendling, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <Ya8CJacaIHLyIAuG@archlinux-ax161>
Le 07/12/2021 à 07:41, Nathan Chancellor a écrit :
> On Tue, Dec 07, 2021 at 05:45:08AM +0000, Christophe Leroy wrote:
>>
>>
>> Le 07/12/2021 à 05:48, Nathan Chancellor a écrit :
>>> On Tue, Dec 07, 2021 at 02:37:26PM +1100, Michael Ellerman wrote:
>>>> Bill Wendling <morbo@google.com> writes:
>>>>> On Tue, Nov 30, 2021 at 10:38 AM Bill Wendling <morbo@google.com> wrote:
>>>>>> On Tue, Nov 30, 2021 at 10:17 AM Nathan Chancellor <nathan@kernel.org> wrote:
>>>>>>> On Tue, Nov 30, 2021 at 10:25:43PM +1100, Michael Ellerman wrote:
>>>>>>>> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>>>>>>>>> Le 29/11/2021 à 23:55, kernel test robot a écrit :
>>>> ...
>>>>>>>>>> All warnings (new ones prefixed by >>):
>>>>>>>>>>
>>>>>>>>>> In file included from arch/powerpc/kernel/asm-offsets.c:71:
>>>>>>>>>> In file included from arch/powerpc/kernel/../xmon/xmon_bpts.h:7:
>>>>>>>>>>>> arch/powerpc/include/asm/inst.h:165:20: warning: variable 'val' is uninitialized when used here [-Wuninitialized]
>>>>>>>>>> *inst = ppc_inst(val);
>>>>>>>>>> ^~~
>>>>>>>>>> arch/powerpc/include/asm/inst.h:53:22: note: expanded from macro 'ppc_inst'
>>>>>>>>>> #define ppc_inst(x) (x)
>>>>>>>>>> ^
>>>>>>>>>> arch/powerpc/include/asm/inst.h:155:18: note: initialize the variable 'val' to silence this warning
>>>>>>>>>> unsigned int val, suffix;
>>>>>>>>>> ^
>>>>>>>>>> = 0
>>>>>>>>>
>>>>>>>>> I can't understand what's wrong here.
>>>> ...
>>>>>>>>>
>>>>>>>>> I see no possibility, no alternative path where val wouldn't be set. The
>>>>>>>>> asm clearly has *addr as an output param so it is always set.
>>>>>>>>
>>>>>>>> I guess clang can't convince itself of that?
>>>> ...
>>>>>>>
>>>>>>> It certainly looks like there is something wrong with how clang is
>>>>>>> tracking the initialization of the variable because it looks to me like
>>>>>>> val is only used in the fallthrough path, which happens after it is
>>>>>>> initialized via lwz. Perhaps something is wrong with the logic of
>>>>>>> https://reviews.llvm.org/D71314? I've added Bill to CC (LLVM issues are
>>>>>>> being migrated from Bugzilla to GitHub Issues right now so I cannot file
>>>>>>> this upstream at the moment).
>>>>>>>
>>>>>> If I remove the casts of "val" the warning doesn't appear. I suspect
>>>>>> that when I wrote that patch I forgot to remove those when checking.
>>>>>> #include "Captain_Picard_facepalm.h"
>>>>>>
>>>>>> I'll look into it.
>>>>>>
>>>>> Small retraction. It's the "*(<cast>)&val" that's the issue. (I.e. the "*&")
>>>>
>>>> I guess for now I'll just squash this in as a workaround?
>>>>
>>>>
>>>> diff --git a/arch/powerpc/include/asm/inst.h b/arch/powerpc/include/asm/inst.h
>>>> index 631436f3f5c3..5b591c51fec9 100644
>>>> --- a/arch/powerpc/include/asm/inst.h
>>>> +++ b/arch/powerpc/include/asm/inst.h
>>>> @@ -157,6 +157,9 @@ static inline int copy_inst_from_kernel_nofault(ppc_inst_t *inst, u32 *src)
>>>> if (unlikely(!is_kernel_addr((unsigned long)src)))
>>>> return -ERANGE;
>>>
>>> Could we add a version check to this and a link to our bug tracker:
>>>
>>> /* https://github.com/ClangBuiltLinux/linux/issues/1521 */
>>> #if defined(CONFIG_CC_IS_CLANG) && CONFIG_CLANG_VERSION < 140000
>>
>> The robot reported the problem on:
>>
>> compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project
>> df08b2fe8b35cb63dfb3b49738a3494b9b4e6f8e)
>>
>> Should it be CONFIG_CLANG_VERSION <= 140000 ?
>
> The robot tests clang from tip of tree, rebuilding every week or so. The
> fix is getting ready to land so it will be released in 14.0.0 final. We
> have always written tip of tree version checks with the expectation that
> if people are testing tip of tree clang, they are frequently rebuilding.
> If that is not true, they need to be using released/stable versions,
> otherwise the model is broken.
>
> If that is too problematic, we could add a version check to Kconfig
> (cannot think of a great name for the config off the top of my head)
> that checks for this issue and ifdef on that. That might be nice in
> case another instance of this crops up in the future.
>
It's fine for me. I didn't know robot was using prereleases with the
same name as the future release.
Christophe
^ permalink raw reply
* Re: [PATCH] powerpc/fixmap: Fix VM debug warning on unmap
From: Maxime Bizon @ 2021-12-07 9:07 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <b0b752f6f6ecc60653e873f385c6f0dce4e9ab6a.1638789098.git.christophe.leroy@csgroup.eu>
On Mon, 2021-12-06 at 11:11 +0000, Christophe Leroy wrote:
>
> Reported-by: Maxime Bizon <mbizon@freebox.fr>
Tested-by: Maxime Bizon <mbizon@freebox.fr>
maybe stable ? I had this on 5.15
Thanks !
--
Maxime
^ permalink raw reply
* Re: Fail to boot 5.15 on mpc8347 with either debug_pagealloc or nobats
From: Maxime Bizon @ 2021-12-07 9:04 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <a4e18c79-fff0-df8b-8d76-c2acf6e741bb@csgroup.eu>
On Tue, 2021-12-07 at 05:54 +0000, Christophe Leroy wrote:
>
> Did you check with my latest patch (v2) ?
>
yes I did, works perfectly, I just sent the Tested-By
--
Maxime
^ permalink raw reply
* Re: [PATCH v2] powerpc/32s: Fix kasan_init_region() for KASAN
From: Maxime Bizon @ 2021-12-07 9:03 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
In-Reply-To: <90826d123e3e28b840f284412b150a1e13ed62fb.1638799954.git.christophe.leroy@csgroup.eu>
On Mon, 2021-12-06 at 14:12 +0000, Christophe Leroy wrote:
Tested-by: Maxime Bizon <mbizon@freebox.fr>
--
Maxime
^ permalink raw reply
* Re: [PATCH] powerpc/603: Fix boot failure with DEBUG_PAGEALLOC and KFENCE
From: Maxime Bizon @ 2021-12-07 10:34 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
In-Reply-To: <aea33b4813a26bdb9378b5f273f00bd5d4abe240.1638857364.git.christophe.leroy@csgroup.eu>
On Tue, 2021-12-07 at 06:10 +0000, Christophe Leroy wrote:
Hello,
With the patch applied and
CONFIG_DEBUG_PAGEALLOC=y
CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT=y
CONFIG_DEBUG_VM=y
I get tons of this during boot:
[ 0.000000] Dentry cache hash table entries: 262144 (order: 8, 1048576 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] WARNING: CPU: 0 PID: 0 at arch/powerpc/mm/pgtable.c:194 set_pte_at+0x18/0x160
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.15.0+ #442
[ 0.000000] NIP: 80015ebc LR: 80016728 CTR: 800166e4
[ 0.000000] REGS: 80751dd0 TRAP: 0700 Not tainted (5.15.0+)
[ 0.000000] MSR: 00021032 <ME,IR,DR,RI> CR: 42228882 XER: 20000000
[ 0.000000]
[ 0.000000] GPR00: 800b8dc8 80751e80 806c6300 807311d8 807a1000 8ffffe84 80751ea8 00000000
[ 0.000000] GPR08: 007a1591 00000001 007a1180 00000000 42224882 00000000 3ff9c608 3fffd79c
[ 0.000000] GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 800166e4 807a2000
[ 0.000000] GPR24: 807a1fff 807311d8 807311d8 807a2000 80768804 00000000 807a1000 007a1180
[ 0.000000] NIP [80015ebc] set_pte_at+0x18/0x160
[ 0.000000] LR [80016728] set_page_attr+0x44/0xc0
[ 0.000000] Call Trace:
[ 0.000000] [80751e80] [80058570] console_unlock+0x340/0x428 (unreliable)
[ 0.000000] [80751ea0] [00000000] 0x0
[ 0.000000] [80751ec0] [800b8dc8] __apply_to_page_range+0x144/0x2a8
[ 0.000000] [80751f00] [80016918] __kernel_map_pages+0x54/0x64
[ 0.000000] [80751f10] [800cfeb0] __free_pages_ok+0x1b0/0x440
[ 0.000000] [80751f50] [805cfc8c] memblock_free_all+0x1d8/0x274
[ 0.000000] [80751f90] [805c5e0c] mem_init+0x3c/0xd0
[ 0.000000] [80751fb0] [805c0bdc] start_kernel+0x404/0x5c4
[ 0.000000] [80751ff0] [000033f0] 0x33f0
[ 0.000000] Instruction dump:
[ 0.000000] 7c630034 83e1000c 5463d97e 7c0803a6 38210010 4e800020 9421ffe0 93e1001c
[ 0.000000] 83e60000 81250000 71290001 41820014 <0fe00000> 7c0802a6 93c10018 90010024
--
Maxime
^ permalink raw reply
* [PATCH v3 1/2] powerpc: handle kdump appropriately with crash_kexec_post_notifiers option
From: Hari Bathini @ 2021-12-07 10:37 UTC (permalink / raw)
To: mpe, linuxppc-dev, npiggin
Cc: Hari Bathini, mahesh, sourabhjain, kernel test robot
Kdump can be triggered after panic_notifers since commit f06e5153f4ae2
("kernel/panic.c: add "crash_kexec_post_notifiers" option for kdump
after panic_notifers") introduced crash_kexec_post_notifiers option.
But using this option would mean smp_send_stop(), that marks all other
CPUs as offline, gets called before kdump is triggered. As a result,
kdump routines fail to save other CPUs' registers. To fix this, kdump
friendly crash_smp_send_stop() function was introduced with kernel
commit 0ee59413c967 ("x86/panic: replace smp_send_stop() with kdump
friendly version in panic path"). Override this kdump friendly weak
function to handle crash_kexec_post_notifiers option appropriately
on powerpc.
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
[Fixed signature of crash_stop_this_cpu() - reported by lkp@intel.com]
Reported-by: kernel test robot <lkp@intel.com>
---
arch/powerpc/kernel/smp.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index c23ee842c4c3..2d33c167b438 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -620,6 +620,36 @@ void crash_send_ipi(void (*crash_ipi_callback)(struct pt_regs *))
}
#endif
+#ifdef CONFIG_NMI_IPI
+static void crash_stop_this_cpu(struct pt_regs *regs)
+#else
+static void crash_stop_this_cpu(void *dummy)
+#endif
+{
+ /*
+ * Just busy wait here and avoid marking CPU as offline to ensure
+ * register data is captured appropriately.
+ */
+ while (1)
+ cpu_relax();
+}
+
+void crash_smp_send_stop(void)
+{
+ static bool stopped = false;
+
+ if (stopped)
+ return;
+
+ stopped = true;
+
+#ifdef CONFIG_NMI_IPI
+ smp_send_nmi_ipi(NMI_IPI_ALL_OTHERS, crash_stop_this_cpu, 1000000);
+#else
+ smp_call_function(crash_stop_this_cpu, NULL, 0);
+#endif /* CONFIG_NMI_IPI */
+}
+
#ifdef CONFIG_NMI_IPI
static void nmi_stop_this_cpu(struct pt_regs *regs)
{
--
2.33.1
^ permalink raw reply related
* [PATCH v3 2/2] ppc64/fadump: fix inaccurate CPU state info in vmcore generated with panic
From: Hari Bathini @ 2021-12-07 10:37 UTC (permalink / raw)
To: mpe, linuxppc-dev, npiggin; +Cc: Hari Bathini, mahesh, sourabhjain
In-Reply-To: <20211207103719.91117-1-hbathini@linux.ibm.com>
In panic path, fadump is triggered via a panic notifier function.
Before calling panic notifier functions, smp_send_stop() gets called,
which stops all CPUs except the panic'ing CPU. Commit 8389b37dffdc
("powerpc: stop_this_cpu: remove the cpu from the online map.") and
again commit bab26238bbd4 ("powerpc: Offline CPU in stop_this_cpu()")
started marking CPUs as offline while stopping them. So, if a kernel
has either of the above commits, vmcore captured with fadump via panic
path would not process register data for all CPUs except the panic'ing
CPU. Sample output of crash-utility with such vmcore:
# crash vmlinux vmcore
...
KERNEL: vmlinux
DUMPFILE: vmcore [PARTIAL DUMP]
CPUS: 1
DATE: Wed Nov 10 09:56:34 EST 2021
UPTIME: 00:00:42
LOAD AVERAGE: 2.27, 0.69, 0.24
TASKS: 183
NODENAME: XXXXXXXXX
RELEASE: 5.15.0+
VERSION: #974 SMP Wed Nov 10 04:18:19 CST 2021
MACHINE: ppc64le (2500 Mhz)
MEMORY: 8 GB
PANIC: "Kernel panic - not syncing: sysrq triggered crash"
PID: 3394
COMMAND: "bash"
TASK: c0000000150a5f80 [THREAD_INFO: c0000000150a5f80]
CPU: 1
STATE: TASK_RUNNING (PANIC)
crash> p -x __cpu_online_mask
__cpu_online_mask = $1 = {
bits = {0x2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
}
crash>
crash>
crash> p -x __cpu_active_mask
__cpu_active_mask = $2 = {
bits = {0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
}
crash>
While this has been the case since fadump was introduced, the issue
was not identified for two probable reasons:
- In general, the bulk of the vmcores analyzed were from crash
due to exception.
- The above did change since commit 8341f2f222d7 ("sysrq: Use
panic() to force a crash") started using panic() instead of
deferencing NULL pointer to force a kernel crash. But then
commit de6e5d38417e ("powerpc: smp_send_stop do not offline
stopped CPUs") stopped marking CPUs as offline till kernel
commit bab26238bbd4 ("powerpc: Offline CPU in stop_this_cpu()")
reverted that change.
To ensure post processing register data of all other CPUs happens
as intended, let panic() function take the crash friendly path (read
crash_smp_send_stop()) with the help of crash_kexec_post_notifiers
option. Also, as register data for all CPUs is captured by f/w, skip
IPI callbacks here for fadump, to avoid any complications in finding
the right backtraces.
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
---
arch/powerpc/kernel/fadump.c | 8 ++++++++
arch/powerpc/kernel/smp.c | 10 ++++++++++
2 files changed, 18 insertions(+)
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index b7ceb041743c..60f5fc14aa23 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -1641,6 +1641,14 @@ int __init setup_fadump(void)
else if (fw_dump.reserve_dump_area_size)
fw_dump.ops->fadump_init_mem_struct(&fw_dump);
+ /*
+ * In case of panic, fadump is triggered via ppc_panic_event()
+ * panic notifier. Setting crash_kexec_post_notifiers to 'true'
+ * lets panic() function take crash friendly path before panic
+ * notifiers are invoked.
+ */
+ crash_kexec_post_notifiers = true;
+
return 1;
}
subsys_initcall(setup_fadump);
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 2d33c167b438..10fb01837e6b 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -61,6 +61,7 @@
#include <asm/cpu_has_feature.h>
#include <asm/ftrace.h>
#include <asm/kup.h>
+#include <asm/fadump.h>
#ifdef DEBUG
#include <asm/udbg.h>
@@ -638,6 +639,15 @@ void crash_smp_send_stop(void)
{
static bool stopped = false;
+ /*
+ * In case of fadump, register data for all CPUs is captured by f/w
+ * on ibm,os-term rtas call. Skip IPI callbacks to other CPUs before
+ * this rtas call to avoid tricky post processing of those CPUs'
+ * backtraces.
+ */
+ if (should_fadump_crash())
+ return;
+
if (stopped)
return;
--
2.33.1
^ permalink raw reply related
* [PATCH] powerpc: platforms: cell: pervasive: fix clang -Wimplicit-fallthrough
From: Anders Roxell @ 2021-12-07 11:02 UTC (permalink / raw)
To: arnd
Cc: Anders Roxell, Naresh Kamboju, llvm, ndesaulniers, linux-kernel,
nathan, linuxppc-dev
Clang warns:
arch/powerpc/platforms/cell/pervasive.c:81:2: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case SRR1_WAKEEE:
^
arch/powerpc/platforms/cell/pervasive.c:81:2: note: insert 'break;' to avoid fall-through
case SRR1_WAKEEE:
^
break;
1 error generated.
Clang is more pedantic than GCC, which does not warn when failing
through to a case that is just break or return. Clang's version
is more in line with the kernel's own stance in deprecated.rst.
Add athe missing break to silence the warning.
Fixes: 6e83985b0f6e ("powerpc/cbe: Do not process external or decremeter interrupts from sreset")
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
arch/powerpc/platforms/cell/pervasive.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/cell/pervasive.c b/arch/powerpc/platforms/cell/pervasive.c
index 5b9a7e9f144b..dff8d5e7ab82 100644
--- a/arch/powerpc/platforms/cell/pervasive.c
+++ b/arch/powerpc/platforms/cell/pervasive.c
@@ -78,6 +78,7 @@ static int cbe_system_reset_exception(struct pt_regs *regs)
switch (regs->msr & SRR1_WAKEMASK) {
case SRR1_WAKEDEC:
set_dec(1);
+ break;
case SRR1_WAKEEE:
/*
* Handle these when interrupts get re-enabled and we take
--
2.33.0
^ permalink raw reply related
* Re: [PATCH v5 5/5] powerpc/inst: Optimise copy_inst_from_kernel_nofault()
From: Michael Ellerman @ 2021-12-07 11:19 UTC (permalink / raw)
To: Nathan Chancellor
Cc: kbuild-all, kernel test robot, llvm, Nick Desaulniers,
linux-kernel, Paul Mackerras, Bill Wendling, linuxppc-dev
In-Reply-To: <Ya7ntJ0ehZPy6HKA@archlinux-ax161>
Nathan Chancellor <nathan@kernel.org> writes:
> On Tue, Dec 07, 2021 at 02:37:26PM +1100, Michael Ellerman wrote:
>> Bill Wendling <morbo@google.com> writes:
>> > On Tue, Nov 30, 2021 at 10:38 AM Bill Wendling <morbo@google.com> wrote:
>> >> On Tue, Nov 30, 2021 at 10:17 AM Nathan Chancellor <nathan@kernel.org> wrote:
>> >> > On Tue, Nov 30, 2021 at 10:25:43PM +1100, Michael Ellerman wrote:
>> >> > > Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>> >> > > > Le 29/11/2021 à 23:55, kernel test robot a écrit :
>> ...
>> >> > > >> All warnings (new ones prefixed by >>):
>> >> > > >>
>> >> > > >> In file included from arch/powerpc/kernel/asm-offsets.c:71:
>> >> > > >> In file included from arch/powerpc/kernel/../xmon/xmon_bpts.h:7:
>> >> > > >>>> arch/powerpc/include/asm/inst.h:165:20: warning: variable 'val' is uninitialized when used here [-Wuninitialized]
>> >> > > >> *inst = ppc_inst(val);
>> >> > > >> ^~~
>> >> > > >> arch/powerpc/include/asm/inst.h:53:22: note: expanded from macro 'ppc_inst'
>> >> > > >> #define ppc_inst(x) (x)
>> >> > > >> ^
>> >> > > >> arch/powerpc/include/asm/inst.h:155:18: note: initialize the variable 'val' to silence this warning
>> >> > > >> unsigned int val, suffix;
>> >> > > >> ^
>> >> > > >> = 0
>> >> > > >
>> >> > > > I can't understand what's wrong here.
>> ...
>> >> > > >
>> >> > > > I see no possibility, no alternative path where val wouldn't be set. The
>> >> > > > asm clearly has *addr as an output param so it is always set.
>> >> > >
>> >> > > I guess clang can't convince itself of that?
>> ...
>> >> >
>> >> > It certainly looks like there is something wrong with how clang is
>> >> > tracking the initialization of the variable because it looks to me like
>> >> > val is only used in the fallthrough path, which happens after it is
>> >> > initialized via lwz. Perhaps something is wrong with the logic of
>> >> > https://reviews.llvm.org/D71314? I've added Bill to CC (LLVM issues are
>> >> > being migrated from Bugzilla to GitHub Issues right now so I cannot file
>> >> > this upstream at the moment).
>> >> >
>> >> If I remove the casts of "val" the warning doesn't appear. I suspect
>> >> that when I wrote that patch I forgot to remove those when checking.
>> >> #include "Captain_Picard_facepalm.h"
>> >>
>> >> I'll look into it.
>> >>
>> > Small retraction. It's the "*(<cast>)&val" that's the issue. (I.e. the "*&")
>>
>> I guess for now I'll just squash this in as a workaround?
>>
>>
>> diff --git a/arch/powerpc/include/asm/inst.h b/arch/powerpc/include/asm/inst.h
>> index 631436f3f5c3..5b591c51fec9 100644
>> --- a/arch/powerpc/include/asm/inst.h
>> +++ b/arch/powerpc/include/asm/inst.h
>> @@ -157,6 +157,9 @@ static inline int copy_inst_from_kernel_nofault(ppc_inst_t *inst, u32 *src)
>> if (unlikely(!is_kernel_addr((unsigned long)src)))
>> return -ERANGE;
>
> Could we add a version check to this and a link to our bug tracker:
>
> /* https://github.com/ClangBuiltLinux/linux/issues/1521 */
> #if defined(CONFIG_CC_IS_CLANG) && CONFIG_CLANG_VERSION < 140000
Yep, thanks I'll use that.
cheers
^ permalink raw reply
* Re: [patch V2 01/23] powerpc/4xx: Remove MSI support which never worked
From: Michael Ellerman @ 2021-12-07 11:36 UTC (permalink / raw)
To: Cédric Le Goater, Thomas Gleixner, LKML
Cc: linux-hyperv, Paul Mackerras, sparclinux, Wei Liu, Ashok Raj,
Marc Zygnier, x86, Christian Borntraeger, Bjorn Helgaas,
Megha Dey, Jason Gunthorpe, linux-pci, xen-devel, ath11k,
Kevin Tian, Heiko Carstens, Alex Williamson, Kalle Valo,
Juergen Gross, Thomas Bogendoerfer, Greg Kroah-Hartman,
linux-mips, linuxppc-dev
In-Reply-To: <8d1e9d2b-fbe9-2e15-6df6-03028902791a@kaod.org>
Cédric Le Goater <clg@kaod.org> writes:
> Hello Thomas,
>
> On 12/6/21 23:27, Thomas Gleixner wrote:
>> This code is broken since day one. ppc4xx_setup_msi_irqs() has the
>> following gems:
>>
>> 1) The handling of the result of msi_bitmap_alloc_hwirqs() is completely
>> broken:
>>
>> When the result is greater than or equal 0 (bitmap allocation
>> successful) then the loop terminates and the function returns 0
>> (success) despite not having installed an interrupt.
>>
>> When the result is less than 0 (bitmap allocation fails), it prints an
>> error message and continues to "work" with that error code which would
>> eventually end up in the MSI message data.
>>
>> 2) On every invocation the file global pp4xx_msi::msi_virqs bitmap is
>> allocated thereby leaking the previous one.
>>
>> IOW, this has never worked and for more than 10 years nobody cared. Remove
>> the gunk.
>>
>> Fixes: 3fb7933850fa ("powerpc/4xx: Adding PCIe MSI support")
>
> Shouldn't we remove all of it ? including the updates in the device trees
> and the Kconfig changes under :
>
> arch/powerpc/platforms/44x/Kconfig: select PPC4xx_MSI
> arch/powerpc/platforms/44x/Kconfig: select PPC4xx_MSI
> arch/powerpc/platforms/44x/Kconfig: select PPC4xx_MSI
> arch/powerpc/platforms/44x/Kconfig: select PPC4xx_MSI
> arch/powerpc/platforms/40x/Kconfig: select PPC4xx_MSI
This patch should drop those selects I guess. Can you send an
incremental diff for Thomas to squash in?
Removing all the tendrils in various device tree files will probably
require some archaeology, and it should be perfectly safe to leave those
in the tree with the driver gone. So I think we can do that as a
subsequent patch, rather than in this series.
cheers
^ permalink raw reply
* Re: [PATCH v6 17/18] powerpc/64s: Move hash MMU support code under CONFIG_PPC_64S_HASH_MMU
From: Michael Ellerman @ 2021-12-07 12:58 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20211201144153.2456614-18-npiggin@gmail.com>
Nicholas Piggin <npiggin@gmail.com> writes:
> diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h b/arch/powerpc/include/asm/book3s/64/mmu.h
> index 015d7d972d16..c480d21a146c 100644
> --- a/arch/powerpc/include/asm/book3s/64/mmu.h
> +++ b/arch/powerpc/include/asm/book3s/64/mmu.h
> @@ -239,8 +251,9 @@ static inline void setup_initial_memory_limit(phys_addr_t first_memblock_base,
> * know which translations we will pick. Hence go with hash
> * restrictions.
> */
> - return hash__setup_initial_memory_limit(first_memblock_base,
> - first_memblock_size);
> + if (!radix_enabled())
> + hash__setup_initial_memory_limit(first_memblock_base,
> + first_memblock_size);
> }
This needs to use early_radix_enabled(), it's called before jump label
patching.
With the jump label feature check debugging on you get a warning:
Booting Linux via __start() @ 0x0000000000400000 ...
[ 0.000000][ T0] Warning! mmu_has_feature() used prior to jump label init!
[ 0.000000][ T0] CPU: 0 PID: 0 Comm: swapper Not tainted 5.16.0-rc2-00167-ga2397104dbef #149
[ 0.000000][ T0] Call Trace:
[ 0.000000][ T0] [c000000002843e20] [c000000000894d40] dump_stack_lvl+0x74/0xa8 (unreliable)
[ 0.000000][ T0] [c000000002843e60] [c000000002009a28] early_init_devtree+0x164/0x554
[ 0.000000][ T0] [c000000002843f10] [c00000000200b3d4] early_setup+0xc8/0x280
[ 0.000000][ T0] [c000000002843f90] [000000000000d368] 0xd368
Or otherwise a really obscure crash :D
cheers
^ permalink raw reply
* Re: [PATCH v6 17/18] powerpc/64s: Move hash MMU support code under CONFIG_PPC_64S_HASH_MMU
From: Michael Ellerman @ 2021-12-07 13:00 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20211201144153.2456614-18-npiggin@gmail.com>
Nicholas Piggin <npiggin@gmail.com> writes:
> Compiling out hash support code when CONFIG_PPC_64S_HASH_MMU=n saves
> 128kB kernel image size (90kB text) on powernv_defconfig minus KVM,
> 350kB on pseries_defconfig minus KVM, 40kB on a tiny config.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/Kconfig | 2 +-
> arch/powerpc/include/asm/book3s/64/mmu.h | 21 ++++++++++--
> .../include/asm/book3s/64/tlbflush-hash.h | 6 ++++
> arch/powerpc/include/asm/book3s/pgtable.h | 4 +++
> arch/powerpc/include/asm/mmu_context.h | 2 ++
> arch/powerpc/include/asm/paca.h | 8 +++++
> arch/powerpc/kernel/asm-offsets.c | 2 ++
> arch/powerpc/kernel/entry_64.S | 4 +--
> arch/powerpc/kernel/exceptions-64s.S | 16 ++++++++++
> arch/powerpc/kernel/mce.c | 2 +-
> arch/powerpc/kernel/mce_power.c | 10 ++++--
> arch/powerpc/kernel/paca.c | 18 ++++-------
> arch/powerpc/kernel/process.c | 13 ++++----
> arch/powerpc/kernel/prom.c | 2 ++
> arch/powerpc/kernel/setup_64.c | 5 +++
> arch/powerpc/kexec/core_64.c | 4 +--
> arch/powerpc/kexec/ranges.c | 4 +++
> arch/powerpc/mm/book3s64/Makefile | 15 +++++----
> arch/powerpc/mm/book3s64/hugetlbpage.c | 2 ++
> arch/powerpc/mm/book3s64/mmu_context.c | 32 +++++++++++++++----
> arch/powerpc/mm/book3s64/pgtable.c | 2 +-
> arch/powerpc/mm/book3s64/radix_pgtable.c | 4 +++
> arch/powerpc/mm/copro_fault.c | 2 ++
> arch/powerpc/mm/ptdump/Makefile | 2 +-
> arch/powerpc/platforms/powernv/idle.c | 2 ++
> arch/powerpc/platforms/powernv/setup.c | 2 ++
> arch/powerpc/platforms/pseries/lpar.c | 11 +++++--
> arch/powerpc/platforms/pseries/lparcfg.c | 2 +-
> arch/powerpc/platforms/pseries/mobility.c | 6 ++++
> arch/powerpc/platforms/pseries/ras.c | 2 ++
> arch/powerpc/platforms/pseries/reconfig.c | 2 ++
> arch/powerpc/platforms/pseries/setup.c | 6 ++--
> arch/powerpc/xmon/xmon.c | 8 +++--
> drivers/misc/lkdtm/core.c | 2 +-
> 34 files changed, 173 insertions(+), 52 deletions(-)
I was able to clean up some of the ifdefs a little with the changes
below. I'll run these through some test builds and then squash them in.
cheers
diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
index 3004f3323144..21f780942911 100644
--- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h
+++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
@@ -523,8 +523,14 @@ void slb_save_contents(struct slb_entry *slb_ptr);
void slb_dump_contents(struct slb_entry *slb_ptr);
extern void slb_vmalloc_update(void);
-extern void slb_set_size(u16 size);
void preload_new_slb_context(unsigned long start, unsigned long sp);
+
+#ifdef CONFIG_PPC_64S_HASH_MMU
+void slb_set_size(u16 size);
+#else
+static inline void slb_set_size(u16 size) { }
+#endif
+
#endif /* __ASSEMBLY__ */
/*
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 2197404cdcc4..75678ff04dd7 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -231,10 +231,9 @@ static void __init check_cpu_pa_features(unsigned long node)
ibm_pa_features, ARRAY_SIZE(ibm_pa_features));
}
-#ifdef CONFIG_PPC_BOOK3S_64
+#ifdef CONFIG_PPC_64S_HASH_MMU
static void __init init_mmu_slb_size(unsigned long node)
{
-#ifdef CONFIG_PPC_64S_HASH_MMU
const __be32 *slb_size_ptr;
slb_size_ptr = of_get_flat_dt_prop(node, "slb-size", NULL) ? :
@@ -242,7 +241,6 @@ static void __init init_mmu_slb_size(unsigned long node)
if (slb_size_ptr)
mmu_slb_size = be32_to_cpup(slb_size_ptr);
-#endif
}
#else
#define init_mmu_slb_size(node) do { } while(0)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 22647bb82198..703a2e6ab08d 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -886,9 +886,7 @@ void __init setup_per_cpu_areas(void)
atom_size = SZ_1M;
} else if (radix_enabled()) {
atom_size = PAGE_SIZE;
- } else {
-#ifdef CONFIG_PPC_64S_HASH_MMU
-
+ } else if (IS_ENABLED(CONFIG_PPC_64S_HASH_MMU)) {
/*
* Linear mapping is one of 4K, 1M and 16M. For 4K, no need
* to group units. For larger mappings, use 1M atom which
@@ -898,9 +896,6 @@ void __init setup_per_cpu_areas(void)
atom_size = PAGE_SIZE;
else
atom_size = SZ_1M;
-#else
- BUILD_BUG(); // radix_enabled() should be constant true
-#endif
}
if (pcpu_chosen_fc != PCPU_FC_PAGE) {
diff --git a/arch/powerpc/kexec/ranges.c b/arch/powerpc/kexec/ranges.c
index 92d831621fa0..563e9989a5bf 100644
--- a/arch/powerpc/kexec/ranges.c
+++ b/arch/powerpc/kexec/ranges.c
@@ -296,7 +296,7 @@ int add_initrd_mem_range(struct crash_mem **mem_ranges)
return ret;
}
-#ifdef CONFIG_PPC_BOOK3S_64
+#ifdef CONFIG_PPC_64S_HASH_MMU
/**
* add_htab_mem_range - Adds htab range to the given memory ranges list,
* if it exists
@@ -306,14 +306,10 @@ int add_initrd_mem_range(struct crash_mem **mem_ranges)
*/
int add_htab_mem_range(struct crash_mem **mem_ranges)
{
-#ifdef CONFIG_PPC_64S_HASH_MMU
if (!htab_address)
return 0;
return add_mem_range(mem_ranges, __pa(htab_address), htab_size_bytes);
-#else
- return 0;
-#endif
}
#endif
diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c b/arch/powerpc/mm/book3s64/radix_pgtable.c
index 5f8cbeca8080..3c4f0ebe5df8 100644
--- a/arch/powerpc/mm/book3s64/radix_pgtable.c
+++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
@@ -333,10 +333,8 @@ static void __init radix_init_pgtable(void)
phys_addr_t start, end;
u64 i;
-#ifdef CONFIG_PPC_64S_HASH_MMU
/* We don't support slb for radix */
- mmu_slb_size = 0;
-#endif
+ slb_set_size(0);
/*
* Create the linear mapping
diff --git a/arch/powerpc/platforms/pseries/mobility.c b/arch/powerpc/platforms/pseries/mobility.c
index 21b706bcea76..85033f392c78 100644
--- a/arch/powerpc/platforms/pseries/mobility.c
+++ b/arch/powerpc/platforms/pseries/mobility.c
@@ -484,9 +484,7 @@ static int do_suspend(void)
ret = rtas_ibm_suspend_me(&status);
if (ret != 0) {
pr_err("ibm,suspend-me error: %d\n", status);
-#ifdef CONFIG_PPC_64S_HASH_MMU
slb_set_size(saved_slb_size);
-#endif
}
return ret;
diff --git a/arch/powerpc/platforms/pseries/pseries.h b/arch/powerpc/platforms/pseries/pseries.h
index 3544778e06d0..b4c63c481f33 100644
--- a/arch/powerpc/platforms/pseries/pseries.h
+++ b/arch/powerpc/platforms/pseries/pseries.h
@@ -113,6 +113,11 @@ int dlpar_workqueue_init(void);
extern u32 pseries_security_flavor;
void pseries_setup_security_mitigations(void);
+
+#ifdef CONFIG_PPC_64S_HASH_MMU
void pseries_lpar_read_hblkrm_characteristics(void);
+#else
+static inline void pseries_lpar_read_hblkrm_characteristics(void) { }
+#endif
#endif /* _PSERIES_PSERIES_H */
diff --git a/arch/powerpc/platforms/pseries/reconfig.c b/arch/powerpc/platforms/pseries/reconfig.c
index 80dae18d6621..7f7369fec46b 100644
--- a/arch/powerpc/platforms/pseries/reconfig.c
+++ b/arch/powerpc/platforms/pseries/reconfig.c
@@ -337,10 +337,8 @@ static int do_update_property(char *buf, size_t bufsize)
if (!newprop)
return -ENOMEM;
-#ifdef CONFIG_PPC_64S_HASH_MMU
if (!strcmp(name, "slb-size") || !strcmp(name, "ibm,slb-size"))
slb_set_size(*(int *)value);
-#endif
return of_update_property(np, newprop);
}
^ permalink raw reply related
* Re: [PATCH] powerpc: platforms: cell: pervasive: fix clang -Wimplicit-fallthrough
From: Arnd Bergmann @ 2021-12-07 13:00 UTC (permalink / raw)
To: Anders Roxell
Cc: Arnd Bergmann, Naresh Kamboju, llvm, Nick Desaulniers,
Linux Kernel Mailing List, Nathan Chancellor, linuxppc-dev
In-Reply-To: <20211207110228.698956-1-anders.roxell@linaro.org>
On Tue, Dec 7, 2021 at 12:02 PM Anders Roxell <anders.roxell@linaro.org> wrote:
>
> Clang warns:
>
> arch/powerpc/platforms/cell/pervasive.c:81:2: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
> case SRR1_WAKEEE:
> ^
> arch/powerpc/platforms/cell/pervasive.c:81:2: note: insert 'break;' to avoid fall-through
> case SRR1_WAKEEE:
> ^
> break;
> 1 error generated.
>
> Clang is more pedantic than GCC, which does not warn when failing
> through to a case that is just break or return. Clang's version
> is more in line with the kernel's own stance in deprecated.rst.
> Add athe missing break to silence the warning.
>
> Fixes: 6e83985b0f6e ("powerpc/cbe: Do not process external or decremeter interrupts from sreset")
> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Thanks for the fix!
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH] selftests/powerpc/spectre_v2: Return skip code when miss_percent is high
From: Thadeu Lima de Souza Cascardo @ 2021-12-07 13:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kselftest
A mis-match between reported and actual mitigation is not restricted to the
Vulnerable case. The guest might also report the mitigation as "Software
count cache flush" and the host will still mitigate with branch cache
disabled.
So, instead of skipping depending on the detected mitigation, simply skip
whenever the detected miss_percent is the expected one for a fully
mitigated system, that is, above 95%.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
---
tools/testing/selftests/powerpc/security/spectre_v2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/powerpc/security/spectre_v2.c b/tools/testing/selftests/powerpc/security/spectre_v2.c
index adc2b7294e5f..83647b8277e7 100644
--- a/tools/testing/selftests/powerpc/security/spectre_v2.c
+++ b/tools/testing/selftests/powerpc/security/spectre_v2.c
@@ -193,7 +193,7 @@ int spectre_v2_test(void)
* We are not vulnerable and reporting otherwise, so
* missing such a mismatch is safe.
*/
- if (state == VULNERABLE)
+ if (miss_percent > 95)
return 4;
return 1;
--
2.32.0
^ permalink raw reply related
* [PATCH] sound: fsl: add missing put_device() call in imx_hdmi_probe()
From: Qing Wang @ 2021-12-07 12:56 UTC (permalink / raw)
To: Nicolin Chen, Xiubo Li, Fabio Estevam, Shengjiu Wang,
Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, NXP Linux Team,
alsa-devel, linuxppc-dev, linux-arm-kernel, linux-kernel
Cc: Wang Qing
From: Wang Qing <wangqing@vivo.com>
of_find_device_by_node() takes a reference to the embedded struct device
which needs to be dropped when error return.
Signed-off-by: Wang Qing <wangqing@vivo.com>
---
sound/soc/fsl/imx-hdmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/imx-hdmi.c b/sound/soc/fsl/imx-hdmi.c
index 929f69b..89fd8ad
--- a/sound/soc/fsl/imx-hdmi.c
+++ b/sound/soc/fsl/imx-hdmi.c
@@ -125,6 +125,7 @@ static int imx_hdmi_probe(struct platform_device *pdev)
data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
if (!data) {
+ put_device(&cpu_pdev->dev);
ret = -ENOMEM;
goto fail;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH V4 0/1] powerpc/perf: Clear pending PMI in ppmu callbacks
From: Michael Ellerman @ 2021-12-07 13:27 UTC (permalink / raw)
To: mpe, Athira Rajeev; +Cc: maddy, linuxppc-dev, npiggin, rnsastry
In-Reply-To: <1626846509-1350-1-git-send-email-atrajeev@linux.vnet.ibm.com>
On Wed, 21 Jul 2021 01:48:28 -0400, Athira Rajeev wrote:
> Running perf fuzzer testsuite popped up below messages
> in the dmesg logs:
>
> "Can't find PMC that caused IRQ"
>
> This means a PMU exception happened, but none of the PMC's (Performance
> Monitor Counter) were found to be overflown. Perf interrupt handler checks
> the PMC's to see which PMC has overflown and if none of the PMCs are
> overflown ( counter value not >= 0x80000000 ), it throws warning:
> "Can't find PMC that caused IRQ".
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC
https://git.kernel.org/powerpc/c/2c9ac51b850d84ee496b0a5d832ce66d411ae552
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/32s: Fix shift-out-of-bounds in KASAN init
From: Michael Ellerman @ 2021-12-07 13:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Christophe Leroy, Paul Mackerras,
Michael Ellerman
Cc: Erhard Furtner, linuxppc-dev, linux-kernel
In-Reply-To: <15cbc3439d4ad988b225e2119ec99502a5cc6ad3.1638261744.git.christophe.leroy@csgroup.eu>
On Tue, 30 Nov 2021 09:42:37 +0100, Christophe Leroy wrote:
> ================================================================================
> UBSAN: shift-out-of-bounds in arch/powerpc/mm/kasan/book3s_32.c:22:23
> shift exponent -1 is negative
> CPU: 0 PID: 0 Comm: swapper Not tainted 5.15.5-gentoo-PowerMacG4 #9
> Call Trace:
> [c214be60] [c0ba0048] dump_stack_lvl+0x80/0xb0 (unreliable)
> [c214be80] [c0b99288] ubsan_epilogue+0x10/0x5c
> [c214be90] [c0b98fe0] __ubsan_handle_shift_out_of_bounds+0x94/0x138
> [c214bf00] [c1c0f010] kasan_init_region+0xd8/0x26c
> [c214bf30] [c1c0ed84] kasan_init+0xc0/0x198
> [c214bf70] [c1c08024] setup_arch+0x18/0x54c
> [c214bfc0] [c1c037f0] start_kernel+0x90/0x33c
> [c214bff0] [00003610] 0x3610
> ================================================================================
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/32s: Fix shift-out-of-bounds in KASAN init
https://git.kernel.org/powerpc/c/af11dee4361b3519981fa04d014873f9d9edd6ac
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: Don't bother about .data..Lubsan sections
From: Michael Ellerman @ 2021-12-07 13:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Christophe Leroy, Paul Mackerras,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <3eb14570612eef17e01bb67f14a4450136001794.1637840601.git.christophe.leroy@csgroup.eu>
On Thu, 25 Nov 2021 12:43:33 +0100, Christophe Leroy wrote:
> Since commit 9a427556fb8e ("vmlinux.lds.h: catch compound literals
> into data and BSS") .data..Lubsan sections are taken into account
> in DATA_MAIN which is included in DATA_DATA macro.
>
> No need to take care of them anymore in powerpc vmlinux.lds.S
>
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: Don't bother about .data..Lubsan sections
https://git.kernel.org/powerpc/c/57dd3a7bdf311e4a499fe0decabcdf2484e2538a
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/modules: Don't WARN on first module allocation tentative
From: Michael Ellerman @ 2021-12-07 13:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Christophe Leroy, Paul Mackerras,
Michael Ellerman
Cc: Erhard Furtner, linuxppc-dev, linux-kernel
In-Reply-To: <93c9b84d6ec76aaf7b4f03468e22433a6d308674.1638267035.git.christophe.leroy@csgroup.eu>
On Tue, 30 Nov 2021 11:10:43 +0100, Christophe Leroy wrote:
> module_alloc() first tries to allocate module text within
> 24 bits direct jump from kernel text, and tries a wider
> allocation if first one fails.
>
> When first allocation fails the following is observed in kernel logs:
>
> vmap allocation for size 2400256 failed: use vmalloc=<size> to increase size
> systemd-udevd: vmalloc error: size 2395133, vm_struct allocation failed, mode:0xcc0(GFP_KERNEL), nodemask=(null)
> CPU: 0 PID: 127 Comm: systemd-udevd Tainted: G W 5.15.5-gentoo-PowerMacG4 #9
> Call Trace:
> [e2a53a50] [c0ba0048] dump_stack_lvl+0x80/0xb0 (unreliable)
> [e2a53a70] [c0540128] warn_alloc+0x11c/0x2b4
> [e2a53b50] [c0531be8] __vmalloc_node_range+0xd8/0x64c
> [e2a53c10] [c00338c0] module_alloc+0xa0/0xac
> [e2a53c40] [c027a368] load_module+0x2ae0/0x8148
> [e2a53e30] [c027fc78] sys_finit_module+0xfc/0x130
> [e2a53f30] [c0035098] ret_from_syscall+0x0/0x28
> --- interrupt: c00 at 0x25df10
> NIP: 0025df10 LR: 00416180 CTR: 00000000
> REGS: e2a53f40 TRAP: 0c00 Tainted: G W (5.15.5-gentoo-PowerMacG4)
> MSR: 0000d032 <EE,PR,ME,IR,DR,RI> CR: 2822242c XER: 20000000
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/modules: Don't WARN on first module allocation tentative
https://git.kernel.org/powerpc/c/f1797e4de1146009c888bcf8b6bb6648d55394f1
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/powermac: Add missing lockdep_register_key()
From: Michael Ellerman @ 2021-12-07 13:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Christophe Leroy, Paul Mackerras,
Michael Ellerman
Cc: Erhard Furtner, linuxppc-dev, linux-kernel
In-Reply-To: <69e4f55565bb45ebb0843977801b245af0c666fe.1638264741.git.christophe.leroy@csgroup.eu>
On Tue, 30 Nov 2021 10:32:42 +0100, Christophe Leroy wrote:
> KeyWest i2c @0xf8001003 irq 42 /uni-n@f8000000/i2c@f8001000
> BUG: key c2d00cbc has not been registered!
> ------------[ cut here ]------------
> DEBUG_LOCKS_WARN_ON(1)
> WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:4801 lockdep_init_map_type+0x4c0/0xb4c
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.5-gentoo-PowerMacG4 #9
> NIP: c01a9428 LR: c01a9428 CTR: 00000000
> REGS: e1033cf0 TRAP: 0700 Not tainted (5.15.5-gentoo-PowerMacG4)
> MSR: 00029032 <EE,ME,IR,DR,RI> CR: 24002002 XER: 00000000
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/powermac: Add missing lockdep_register_key()
https://git.kernel.org/powerpc/c/df1f679d19edb9eeb67cc2f96b29375f21991945
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/ptdump: Fix display a BAT's size unit
From: Michael Ellerman @ 2021-12-07 13:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Christophe Leroy, Paul Mackerras,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <f16c30f5c9185a63335322cf1a8b22f189d335ef.1637922595.git.christophe.leroy@csgroup.eu>
On Fri, 26 Nov 2021 11:30:03 +0100, Christophe Leroy wrote:
> We have wrong units on BAT's sizes (G instead of M, M instead of ...)
>
> ---[ Instruction Block Address Translation ]---
> 0: 0xc0000000-0xc03fffff 0x00000000 4G Kernel x m
> 1: 0xc0400000-0xc05fffff 0x00400000 2G Kernel x m
> 2: 0xc0600000-0xc06fffff 0x00600000 1G Kernel x m
> 3: 0xc0700000-0xc077ffff 0x00700000 512M Kernel x m
> 4: 0xc0780000-0xc079ffff 0x00780000 128M Kernel x m
> 5: 0xc07a0000-0xc07bffff 0x007a0000 128M Kernel x m
> 6: -
> 7: -
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/ptdump: Fix display a BAT's size unit
https://git.kernel.org/powerpc/c/cdc81aece8041fd5437bdabde6c543cdeb2891a8
cheers
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox