Re: [PATCH 2/4] ASoC: dt-bindings: fsl,xcvr: Add two PLL clock sources
On Fri, May 10, 2024 at 10:27 AM Shengjiu Wang wrote: > > On Fri, May 10, 2024 at 1:14 AM Conor Dooley wrote: > > > > On Thu, May 09, 2024 at 10:57:38AM +0800, Shengjiu Wang wrote: > > > Add two PLL clock sources, they are the parent clocks of the root clock > > > one is for 8kHz series rates, named as 'pll8k', another one is for > > > 11kHz series rates, named as 'pll11k'. They are optional clocks, > > > if there are such clocks, then the driver can switch between them to > > > support more accurate sample rates. > > > > > > As 'pll8k' and 'pll11k' are optional, then add 'minItems: 4' for > > > clocks and clock-names properties. > > > > Despite the detail given here in the commit message, the series this is > > appearing in and one of the driver patches makes me a bit "suspicious" > > of this patch. Are these newly added clocks available on all devices, or > > just on the imx95, or? > > These newly added clocks are only available for the imx95 XCVR. > Looks like I should merge patch1 & 2 together, patch 3 & 3 together. right? Best regards Shengjiu Wang > Best regards > Shengjiu Wang > > > > Thanks, > > Conor. > > > > > > > > Signed-off-by: Shengjiu Wang > > > --- > > > Documentation/devicetree/bindings/sound/fsl,xcvr.yaml | 6 ++ > > > 1 file changed, 6 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml > > > b/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml > > > index 1c74a32def09..c4660faed404 100644 > > > --- a/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml > > > +++ b/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml > > > @@ -50,6 +50,9 @@ properties: > > >- description: PHY clock > > >- description: SPBA clock > > >- description: PLL clock > > > + - description: PLL clock source for 8kHz series > > > + - description: PLL clock source for 11kHz series > > > +minItems: 4 > > > > > >clock-names: > > > items: > > > @@ -57,6 +60,9 @@ properties: > > >- const: phy > > >- const: spba > > >- const: pll_ipg > > > + - const: pll8k > > > + - const: pll11k > > > +minItems: 4 > > > > > >dmas: > > > items: > > > -- > > > 2.34.1 > > >
Re: [PATCH 1/4] ASoC: dt-bindings: fsl,xcvr: Add compatible string for i.MX95
On Fri, May 10, 2024 at 1:11 AM Conor Dooley wrote: > > On Thu, May 09, 2024 at 10:57:37AM +0800, Shengjiu Wang wrote: > > Add compatible string "fsl,imx95-xcvr" for i.MX95 platform. > > That's apparent from the diff. Why is it not compatible with existing > devices? i.MX8MP: There is PHY and support eARC, ARC, SPDIF i.MX93: There is no PHY and support SPDIF only i.MX95: There is PHY (PHY is different with i.MX8MP), only support SPDIF. Will add such info in the commit message. Best regards Shengjiu > > Cheers, > Conor. > > > > > Signed-off-by: Shengjiu Wang > > --- > > Documentation/devicetree/bindings/sound/fsl,xcvr.yaml | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml > > b/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml > > index 0eb0c1ba8710..1c74a32def09 100644 > > --- a/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml > > +++ b/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml > > @@ -22,6 +22,7 @@ properties: > > enum: > >- fsl,imx8mp-xcvr > >- fsl,imx93-xcvr > > + - fsl,imx95-xcvr > > > >reg: > > items: > > -- > > 2.34.1 > >
Re: [PATCH 2/4] ASoC: dt-bindings: fsl,xcvr: Add two PLL clock sources
On Fri, May 10, 2024 at 1:14 AM Conor Dooley wrote: > > On Thu, May 09, 2024 at 10:57:38AM +0800, Shengjiu Wang wrote: > > Add two PLL clock sources, they are the parent clocks of the root clock > > one is for 8kHz series rates, named as 'pll8k', another one is for > > 11kHz series rates, named as 'pll11k'. They are optional clocks, > > if there are such clocks, then the driver can switch between them to > > support more accurate sample rates. > > > > As 'pll8k' and 'pll11k' are optional, then add 'minItems: 4' for > > clocks and clock-names properties. > > Despite the detail given here in the commit message, the series this is > appearing in and one of the driver patches makes me a bit "suspicious" > of this patch. Are these newly added clocks available on all devices, or > just on the imx95, or? These newly added clocks are only available for the imx95 XCVR. Best regards Shengjiu Wang > > Thanks, > Conor. > > > > > Signed-off-by: Shengjiu Wang > > --- > > Documentation/devicetree/bindings/sound/fsl,xcvr.yaml | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml > > b/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml > > index 1c74a32def09..c4660faed404 100644 > > --- a/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml > > +++ b/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml > > @@ -50,6 +50,9 @@ properties: > >- description: PHY clock > >- description: SPBA clock > >- description: PLL clock > > + - description: PLL clock source for 8kHz series > > + - description: PLL clock source for 11kHz series > > +minItems: 4 > > > >clock-names: > > items: > > @@ -57,6 +60,9 @@ properties: > >- const: phy > >- const: spba > >- const: pll_ipg > > + - const: pll8k > > + - const: pll11k > > +minItems: 4 > > > >dmas: > > items: > > -- > > 2.34.1 > >
[Patch v2] mm/memblock: discard .text/.data if CONFIG_ARCH_KEEP_MEMBLOCK not set
When CONFIG_ARCH_KEEP_MEMBLOCK not set, we expect to discard related
code and data. But it doesn't until CONFIG_MEMORY_HOTPLUG not set
neither.
This patch puts memblock's .text/.data into its own section, so that it
only depends on CONFIG_ARCH_KEEP_MEMBLOCK to discard related code and
data.
After this, from the log message in mem_init_print_info(), init size
increase from 2420K to 2432K on arch x86.
Signed-off-by: Wei Yang
---
v2: fix orphan section for powerpc
---
arch/powerpc/kernel/vmlinux.lds.S | 1 +
include/asm-generic/vmlinux.lds.h | 14 +-
include/linux/memblock.h | 8
3 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S
b/arch/powerpc/kernel/vmlinux.lds.S
index f420df7888a7..d6d33bec597a 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -125,6 +125,7 @@ SECTIONS
*(.text.asan.* .text.tsan.*)
MEM_KEEP(init.text)
MEM_KEEP(exit.text)
+ MEMBLOCK_KEEP(init.text)
} :text
. = ALIGN(PAGE_SIZE);
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index f7749d0f2562..775c5eedb9e6 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -147,6 +147,14 @@
#define MEM_DISCARD(sec) *(.mem##sec)
#endif
+#if defined(CONFIG_ARCH_KEEP_MEMBLOCK)
+#define MEMBLOCK_KEEP(sec)*(.mb##sec)
+#define MEMBLOCK_DISCARD(sec)
+#else
+#define MEMBLOCK_KEEP(sec)
+#define MEMBLOCK_DISCARD(sec) *(.mb##sec)
+#endif
+
#ifndef CONFIG_HAVE_DYNAMIC_FTRACE_NO_PATCHABLE
#define KEEP_PATCHABLE KEEP(*(__patchable_function_entries))
#define PATCHABLE_DISCARDS
@@ -356,6 +364,7 @@
*(.ref.data)\
*(.data..shared_aligned) /* percpu related */ \
MEM_KEEP(init.data*)\
+ MEMBLOCK_KEEP(init.data*) \
*(.data.unlikely) \
__start_once = .; \
*(.data.once) \
@@ -573,6 +582,7 @@
*(.ref.text)\
*(.text.asan.* .text.tsan.*)\
MEM_KEEP(init.text*)\
+ MEMBLOCK_KEEP(init.text*) \
/* sched.text is aling to function alignment to secure we have same
@@ -680,6 +690,7 @@
KEEP(*(SORT(___kentry+*))) \
*(.init.data .init.data.*) \
MEM_DISCARD(init.data*) \
+ MEMBLOCK_DISCARD(init.data*)\
KERNEL_CTORS() \
MCOUNT_REC()\
*(.init.rodata .init.rodata.*) \
@@ -706,7 +717,8 @@
#define INIT_TEXT \
*(.init.text .init.text.*) \
*(.text.startup)\
- MEM_DISCARD(init.text*)
+ MEM_DISCARD(init.text*) \
+ MEMBLOCK_DISCARD(init.text*)
#define EXIT_DATA \
*(.exit.data .exit.data.*) \
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index e2082240586d..3e1f1d42dde7 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -100,13 +100,13 @@ struct memblock {
extern struct memblock memblock;
+#define __init_memblock__section(".mbinit.text") __cold notrace \
+ __latent_entropy
+#define __initdata_memblock__section(".mbinit.data")
+
#ifndef CONFIG_ARCH_KEEP_MEMBLOCK
-#define __init_memblock __meminit
-#define __initdata_memblock __meminitdata
void memblock_discard(void);
#else
-#define __init_memblock
-#define __initdata_memblock
static inline void memblock_discard(void) {}
#endif
--
2.34.1
[PATCH] macintosh/mac_hid: add MODULE_DESCRIPTION()
Fix the make W=1 warning:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/macintosh/mac_hid.o
Signed-off-by: Jeff Johnson
---
drivers/macintosh/mac_hid.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/macintosh/mac_hid.c b/drivers/macintosh/mac_hid.c
index 1ae3539beff5..eb7a173da071 100644
--- a/drivers/macintosh/mac_hid.c
+++ b/drivers/macintosh/mac_hid.c
@@ -16,6 +16,7 @@
#include
#include
+MODULE_DESCRIPTION("Macintosh mouse button 2+3 emulation");
MODULE_LICENSE("GPL");
static int mouse_emulate_buttons;
---
base-commit: dd5a440a31fae6e459c0d627162825505361
change-id: 20240509-mac_hid-md-7df0c349753c
[PATCH v4 44/66] selftests/powerpc: Drop define _GNU_SOURCE
_GNU_SOURCE is provided by lib.mk, so it should be dropped to prevent redefinition warnings. Signed-off-by: Edward Liaw --- tools/testing/selftests/powerpc/benchmarks/context_switch.c| 2 -- tools/testing/selftests/powerpc/benchmarks/exec_target.c | 2 -- tools/testing/selftests/powerpc/benchmarks/fork.c | 2 -- tools/testing/selftests/powerpc/benchmarks/futex_bench.c | 3 --- tools/testing/selftests/powerpc/dexcr/hashchk_test.c | 3 --- tools/testing/selftests/powerpc/dscr/dscr_default_test.c | 3 --- tools/testing/selftests/powerpc/dscr/dscr_explicit_test.c | 3 --- tools/testing/selftests/powerpc/dscr/dscr_sysfs_thread_test.c | 1 - tools/testing/selftests/powerpc/mm/exec_prot.c | 2 -- tools/testing/selftests/powerpc/mm/pkey_exec_prot.c| 2 -- tools/testing/selftests/powerpc/mm/pkey_siginfo.c | 2 -- tools/testing/selftests/powerpc/mm/tlbie_test.c| 2 -- tools/testing/selftests/powerpc/papr_vpd/papr_vpd.c| 1 - tools/testing/selftests/powerpc/pmu/count_instructions.c | 3 --- tools/testing/selftests/powerpc/pmu/count_stcx_fail.c | 3 --- tools/testing/selftests/powerpc/pmu/ebb/ebb.c | 3 --- .../testing/selftests/powerpc/pmu/ebb/instruction_count_test.c | 3 --- tools/testing/selftests/powerpc/pmu/event.c| 2 -- tools/testing/selftests/powerpc/pmu/lib.c | 3 --- tools/testing/selftests/powerpc/pmu/per_event_excludes.c | 3 --- tools/testing/selftests/powerpc/ptrace/perf-hwbreak.c | 3 --- tools/testing/selftests/powerpc/ptrace/ptrace-syscall.c| 2 -- tools/testing/selftests/powerpc/signal/sig_sc_double_restart.c | 1 - tools/testing/selftests/powerpc/signal/sigreturn_kernel.c | 3 --- tools/testing/selftests/powerpc/signal/sigreturn_vdso.c| 3 --- tools/testing/selftests/powerpc/syscalls/ipc_unmuxed.c | 2 -- tools/testing/selftests/powerpc/tm/tm-exec.c | 2 -- tools/testing/selftests/powerpc/tm/tm-poison.c | 2 -- .../testing/selftests/powerpc/tm/tm-signal-context-force-tm.c | 2 -- tools/testing/selftests/powerpc/tm/tm-signal-sigreturn-nt.c| 2 -- tools/testing/selftests/powerpc/tm/tm-tmspr.c | 2 -- tools/testing/selftests/powerpc/tm/tm-trap.c | 2 -- tools/testing/selftests/powerpc/tm/tm-unavailable.c| 2 -- tools/testing/selftests/powerpc/utils.c| 3 --- 34 files changed, 79 deletions(-) diff --git a/tools/testing/selftests/powerpc/benchmarks/context_switch.c b/tools/testing/selftests/powerpc/benchmarks/context_switch.c index 96554e2794d1..0b245572bd45 100644 --- a/tools/testing/selftests/powerpc/benchmarks/context_switch.c +++ b/tools/testing/selftests/powerpc/benchmarks/context_switch.c @@ -4,8 +4,6 @@ * * Copyright (C) 2015 Anton Blanchard , IBM */ - -#define _GNU_SOURCE #include #include #include diff --git a/tools/testing/selftests/powerpc/benchmarks/exec_target.c b/tools/testing/selftests/powerpc/benchmarks/exec_target.c index c14b0fc1edde..8646540037d8 100644 --- a/tools/testing/selftests/powerpc/benchmarks/exec_target.c +++ b/tools/testing/selftests/powerpc/benchmarks/exec_target.c @@ -5,8 +5,6 @@ * * Copyright 2018, Anton Blanchard, IBM Corp. */ - -#define _GNU_SOURCE #include #include diff --git a/tools/testing/selftests/powerpc/benchmarks/fork.c b/tools/testing/selftests/powerpc/benchmarks/fork.c index d312e638cb37..327231646a2a 100644 --- a/tools/testing/selftests/powerpc/benchmarks/fork.c +++ b/tools/testing/selftests/powerpc/benchmarks/fork.c @@ -5,8 +5,6 @@ * * Copyright 2018, Anton Blanchard, IBM Corp. */ - -#define _GNU_SOURCE #include #include #include diff --git a/tools/testing/selftests/powerpc/benchmarks/futex_bench.c b/tools/testing/selftests/powerpc/benchmarks/futex_bench.c index 017057090490..0483a13c88f9 100644 --- a/tools/testing/selftests/powerpc/benchmarks/futex_bench.c +++ b/tools/testing/selftests/powerpc/benchmarks/futex_bench.c @@ -2,9 +2,6 @@ /* * Copyright 2016, Anton Blanchard, Michael Ellerman, IBM Corp. */ - -#define _GNU_SOURCE - #include #include #include diff --git a/tools/testing/selftests/powerpc/dexcr/hashchk_test.c b/tools/testing/selftests/powerpc/dexcr/hashchk_test.c index 645224bdc142..2499ab7fe563 100644 --- a/tools/testing/selftests/powerpc/dexcr/hashchk_test.c +++ b/tools/testing/selftests/powerpc/dexcr/hashchk_test.c @@ -1,7 +1,4 @@ // SPDX-License-Identifier: GPL-2.0+ - -#define _GNU_SOURCE - #include #include #include diff --git a/tools/testing/selftests/powerpc/dscr/dscr_default_test.c b/tools/testing/selftests/powerpc/dscr/dscr_default_test.c index 60ab02525b79..fe6aff1e5dad 100644 --- a/tools/testing/selftests/powerpc/dscr/dscr_default_test.c +++ b/tools/testing/selftests/powerpc/dscr/dscr_default_test.c @@ -9,9 +9,6 @@ * Copyright
Re: [PATCH 3/4] ASoC: fsl_xcvr: Support reparent pll clocks for phy_clk
Hi Shengjiu, kernel test robot noticed the following build errors: [auto build test ERROR on broonie-sound/for-next] [also build test ERROR on linus/master v6.9-rc7 next-20240509] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Shengjiu-Wang/ASoC-dt-bindings-fsl-xcvr-Add-compatible-string-for-i-MX95/20240509-112112 base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next patch link: https://lore.kernel.org/r/1715223460-32662-4-git-send-email-shengjiu.wang%40nxp.com patch subject: [PATCH 3/4] ASoC: fsl_xcvr: Support reparent pll clocks for phy_clk config: x86_64-randconfig-103-20240509 (https://download.01.org/0day-ci/archive/20240510/202405100658.d0kxax8b-...@intel.com/config) compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project 617a15a9eac96088ae5e9134248d8236e34b91b1) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240510/202405100658.d0kxax8b-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202405100658.d0kxax8b-...@intel.com/ All errors (new ones prefixed by >>, old ones prefixed by <<): WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nfs/nfsv2.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nfs/nfsv4.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nls/nls_cp437.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nls/nls_cp855.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nls/nls_cp860.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nls/nls_cp865.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nls/nls_cp866.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nls/nls_cp950.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nls/nls_iso8859-7.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nls/nls_koi8-r.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nls/nls_koi8-u.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nls/nls_koi8-ru.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nls/mac-cyrillic.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nls/mac-greek.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/nls/mac-roman.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/unicode/utf8-selftest.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/binfmt_misc.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/jbd2/jbd2.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/sysv/sysv.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/autofs/autofs4.o WARNING: modpost: missing MODULE_DESCRIPTION() in fs/btrfs/btrfs.o WARNING: modpost: missing MODULE_DESCRIPTION() in security/keys/trusted-keys/trusted.o WARNING: modpost: missing MODULE_DESCRIPTION() in crypto/af_alg.o WARNING: modpost: missing MODULE_DESCRIPTION() in crypto/algif_hash.o WARNING: modpost: missing MODULE_DESCRIPTION() in crypto/curve25519-generic.o WARNING: modpost: missing MODULE_DESCRIPTION() in lib/math/prime_numbers.o WARNING: modpost: missing MODULE_DESCRIPTION() in lib/crypto/libarc4.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pinctrl/pinctrl-mcp23s08_i2c.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpio/gpio-pcf857x.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pci/pci-stub.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/video/backlight/rt4831-backlight.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/video/fbdev/matrox/matroxfb_accel.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/video/fbdev/matrox/matroxfb_DAC1064.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/video/fbdev/matrox/matroxfb_Ti3026.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/video/fbdev/macmodes.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/video/fbdev/via/viafb.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/video/fbdev/kyro/kyrofb.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/acpi/acpi_tad.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/acpi/platform_profile.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/dma/qcom/hdma_mgmt.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/dma/qcom/hdma.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/dma/dmatest.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/regulator/max20411-regulator.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/regulator/rt4831-regulator.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/char/agp/amd64-agp.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/char/agp/via-a
Re: [PATCH 1/1] arch/fault: don't print logs for simulated poison errors
On Thu, May 9, 2024 at 2:05 PM Peter Xu wrote:
>
> On Thu, May 09, 2024 at 01:39:07PM -0700, Axel Rasmussen wrote:
> > For real MCEs, various architectures print log messages when poisoned
> > memory is accessed (which results in a SIGBUS). These messages can be
> > important for users to understand the issue.
> >
> > On the other hand, we have the userfaultfd UFFDIO_POISON operation,
> > which can "simulate" memory poisoning. That particular process will get
>
> It also coveres swapin errors as we talked before, so not always SIM.
>
> I was thinking we should also do that report for swapin errors, however
> then I noticed it wasn't reported before the replacement of pte markers,
> in commit 15520a3f04, since 2022:
>
> @@ -3727,8 +3731,6 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
> put_page(vmf->page);
> } else if (is_hwpoison_entry(entry)) {
> ret = VM_FAULT_HWPOISON;
> - } else if (is_swapin_error_entry(entry)) {
> - ret = VM_FAULT_SIGBUS;
> } else if (is_pte_marker_entry(entry)) {
> ret = handle_pte_marker(vmf);
> } else {
>
> So I am guessing it could be fine to just turn this report off to syslog.
> There will be a back-and-forth on this behavior, but hopefully this is even
> rarer than hwpoison so nobody will notice.
>
> With that, the idea looks valid to me, but perhaps a rename is needed.
> Maybe _QUIESCE or _SILENT?
Ah, I had forgotten about the swapin error case.
I think it still makes sense to silence the log in that case; if we
consider a scenario like disk error, it could seem weird to get an MCE
message for that, since the physical memory is fine and it wouldn't
show up in mcelog or similar.
I like _SILENT, I'll do the rename and update my comments to better
explain in v2.
>
> > SIGBUS on access to the memory, but this effect is tied to an MM, rather
> > than being global like a real poison event. So, we don't want to log
> > about this case to the global kernel log; instead, let the process
> > itself log or whatever else it wants to do. This avoids spamming the
> > kernel log, and avoids e.g. drowning out real events with simulated
> > ones.
> >
> > To identify this situation, add a new VM_FAULT_HWPOISON_SIM flag. This
> > is expected to be set *in addition to* one of the existing
> > VM_FAULT_HWPOISON or VM_FAULT_HWPOISON_LARGE flags (which are mutually
> > exclusive).
> >
> > Signed-off-by: Axel Rasmussen
> > ---
> > arch/parisc/mm/fault.c | 7 +--
> > arch/powerpc/mm/fault.c | 6 --
> > arch/x86/mm/fault.c | 6 --
> > include/linux/mm_types.h | 5 +
> > mm/hugetlb.c | 3 ++-
> > mm/memory.c | 2 +-
> > 6 files changed, 21 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/parisc/mm/fault.c b/arch/parisc/mm/fault.c
> > index c39de84e98b0..e5370bcadf27 100644
> > --- a/arch/parisc/mm/fault.c
> > +++ b/arch/parisc/mm/fault.c
> > @@ -400,9 +400,12 @@ void do_page_fault(struct pt_regs *regs, unsigned long
> > code,
> > #ifdef CONFIG_MEMORY_FAILURE
> > if (fault & (VM_FAULT_HWPOISON|VM_FAULT_HWPOISON_LARGE)) {
> > unsigned int lsb = 0;
> > - printk(KERN_ERR
> > +
> > + if (!(fault & VM_FAULT_HWPOISON_SIM)) {
> > + pr_err(
> > "MCE: Killing %s:%d due to hardware memory corruption fault at
> > %08lx\n",
> > - tsk->comm, tsk->pid, address);
> > + tsk->comm, tsk->pid, address);
> > + }
> > /*
> >* Either small page or large page may be poisoned.
> >* In other words, VM_FAULT_HWPOISON_LARGE and
> > diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> > index 53335ae21a40..ac5e8a3c7fba 100644
> > --- a/arch/powerpc/mm/fault.c
> > +++ b/arch/powerpc/mm/fault.c
> > @@ -140,8 +140,10 @@ static int do_sigbus(struct pt_regs *regs, unsigned
> > long address,
> > if (fault & (VM_FAULT_HWPOISON|VM_FAULT_HWPOISON_LARGE)) {
> > unsigned int lsb = 0; /* shutup gcc */
> >
> > - pr_err("MCE: Killing %s:%d due to hardware memory corruption
> > fault at %lx\n",
> > - current->comm, current->pid, address);
> > + if (!(fault & VM_FAULT_HWPOISON_SIM)) {
> > + pr_err("MCE: Killing %s:%d due to hardware memory
> > corruption fault at %lx\n",
> > + current->comm, current->pid, address);
> > + }
> >
> > if (fault & VM_FAULT_HWPOISON_LARGE)
> > lsb =
> > hstate_index_to_shift(VM_FAULT_GET_HINDEX(fault));
> > diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> > index e4f3c7721f45..16d077a3ad14 100644
> > --- a/arch/x86/mm/fault.c
> > +++ b/arch/x86/mm/fault.c
> > @@ -928,9
Re: [PATCH 1/1] arch/fault: don't print logs for simulated poison errors
On Thu, May 9, 2024 at 2:30 PM John Hubbard wrote:
>
> On 5/9/24 1:39 PM, Axel Rasmussen wrote:
> > For real MCEs, various architectures print log messages when poisoned
> > memory is accessed (which results in a SIGBUS). These messages can be
> > important for users to understand the issue.
> >
> > On the other hand, we have the userfaultfd UFFDIO_POISON operation,
> > which can "simulate" memory poisoning. That particular process will get
> > SIGBUS on access to the memory, but this effect is tied to an MM, rather
> > than being global like a real poison event. So, we don't want to log
> > about this case to the global kernel log; instead, let the process
> > itself log or whatever else it wants to do. This avoids spamming the
> > kernel log, and avoids e.g. drowning out real events with simulated
> > ones.
> >
> > To identify this situation, add a new VM_FAULT_HWPOISON_SIM flag. This
> > is expected to be set *in addition to* one of the existing
> > VM_FAULT_HWPOISON or VM_FAULT_HWPOISON_LARGE flags (which are mutually
> > exclusive).
> >
> > Signed-off-by: Axel Rasmussen
> > ---
> > arch/parisc/mm/fault.c | 7 +--
> > arch/powerpc/mm/fault.c | 6 --
> > arch/x86/mm/fault.c | 6 --
> > include/linux/mm_types.h | 5 +
> > mm/hugetlb.c | 3 ++-
> > mm/memory.c | 2 +-
> > 6 files changed, 21 insertions(+), 8 deletions(-)
> >
>
> This completely fixes the uffd-unit-test behavior, I just did a quick
> test run to be sure as well.
>
> Reviewed-by: John Hubbard
Thanks John!
And, no problem about the other patch, they aren't functionally
dependent, I just hoped to save Andrew dealing with the small merge
conflict. :) I'll base a v2 on mm-unstable directly and that should
clear everything up.
>
> thanks,
> --
> John Hubbard
> NVIDIA
>
>
> > diff --git a/arch/parisc/mm/fault.c b/arch/parisc/mm/fault.c
> > index c39de84e98b0..e5370bcadf27 100644
> > --- a/arch/parisc/mm/fault.c
> > +++ b/arch/parisc/mm/fault.c
> > @@ -400,9 +400,12 @@ void do_page_fault(struct pt_regs *regs, unsigned long
> > code,
> > #ifdef CONFIG_MEMORY_FAILURE
> > if (fault & (VM_FAULT_HWPOISON|VM_FAULT_HWPOISON_LARGE)) {
> > unsigned int lsb = 0;
> > - printk(KERN_ERR
> > +
> > + if (!(fault & VM_FAULT_HWPOISON_SIM)) {
> > + pr_err(
> > "MCE: Killing %s:%d due to hardware memory corruption fault at
> > %08lx\n",
> > - tsk->comm, tsk->pid, address);
> > + tsk->comm, tsk->pid, address);
> > + }
> > /*
> >* Either small page or large page may be poisoned.
> >* In other words, VM_FAULT_HWPOISON_LARGE and
> > diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> > index 53335ae21a40..ac5e8a3c7fba 100644
> > --- a/arch/powerpc/mm/fault.c
> > +++ b/arch/powerpc/mm/fault.c
> > @@ -140,8 +140,10 @@ static int do_sigbus(struct pt_regs *regs, unsigned
> > long address,
> > if (fault & (VM_FAULT_HWPOISON|VM_FAULT_HWPOISON_LARGE)) {
> > unsigned int lsb = 0; /* shutup gcc */
> >
> > - pr_err("MCE: Killing %s:%d due to hardware memory corruption
> > fault at %lx\n",
> > - current->comm, current->pid, address);
> > + if (!(fault & VM_FAULT_HWPOISON_SIM)) {
> > + pr_err("MCE: Killing %s:%d due to hardware memory
> > corruption fault at %lx\n",
> > + current->comm, current->pid, address);
> > + }
> >
> > if (fault & VM_FAULT_HWPOISON_LARGE)
> > lsb =
> > hstate_index_to_shift(VM_FAULT_GET_HINDEX(fault));
> > diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> > index e4f3c7721f45..16d077a3ad14 100644
> > --- a/arch/x86/mm/fault.c
> > +++ b/arch/x86/mm/fault.c
> > @@ -928,9 +928,11 @@ do_sigbus(struct pt_regs *regs, unsigned long
> > error_code, unsigned long address,
> > struct task_struct *tsk = current;
> > unsigned lsb = 0;
> >
> > - pr_err_ratelimited(
> > + if (!(fault & VM_FAULT_HWPOISON_SIM)) {
> > + pr_err_ratelimited(
> > "MCE: Killing %s:%d due to hardware memory corruption fault at %lx\n",
> > - tsk->comm, tsk->pid, address);
> > + tsk->comm, tsk->pid, address);
> > + }
> > if (fault & VM_FAULT_HWPOISON_LARGE)
> > lsb =
> > hstate_index_to_shift(VM_FAULT_GET_HINDEX(fault));
> > if (fault & VM_FAULT_HWPOISON)
> > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > index 5240bd7bca33..7f8fc3efc5b2 100644
> > --- a/include/linux/mm_types.h
> > +++ b/include/linux/mm_types.h
> > @@ -1226,6 +1226,9 @@ typedef __bitwise unsigned int vm_fault_t;
> >*
Re: [PATCH 1/1] [RFC] ethernet: Convert from tasklet to BH workqueue
Paolo, > On Wed, 2024-05-08 at 21:16 +0100, Simon Horman wrote: > > * As this patch seems to involve many non-trivial changes > > it seems to me that it would be best to break it up somehow. > > To allow proper review. > > I would like to stress this latest point: it looks like the changes to > all the drivers are completely independent. If so, you have to break > the series on a per driver basis. Since the total number of patch will > be higher then 15 (maximum size allowed on netdev) you will have to > split this in several smaller series. > Right, it's a valid point. Per-driver might not work. Depending on the driver and changes, I will try and make it an independent series. > Beyond making the change reviewable, it will allow eventually reverting > the changes individually, should that cause any regressions. > Thank you, I understand the concern here. Will work on it in v2. Thank you very much for your time and suggestions. - Allen
Re: [PATCH 1/1] [RFC] ethernet: Convert from tasklet to BH workqueue
> > > On Tue, May 07, 2024 at 07:01:11PM +, Allen Pais wrote: > > > > The only generic interface to execute asynchronously in the BH context > > > > is > > > > tasklet; however, it's marked deprecated and has some design flaws. To > > > > replace tasklets, BH workqueue support was recently added. A BH > > > > workqueue > > > > behaves similarly to regular workqueues except that the queued work > > > > items > > > > are executed in the BH context. > > > > > > > > This patch converts drivers/ethernet/* from tasklet to BH workqueue. > > > > > > I doubt you're going to get many comments on this patch, being so large > > > and spread across all drivers. I'm not going to bother trying to edit > > > this down to something more sensible, I'll just plonk my comment here. > > > > > > For the mvpp2 driver, you're only updating a comment - and looking at > > > it, the comment no longer reflects the code. It doesn't make use of > > > tasklets at all. That makes the comment wrong whether or not it's > > > updated. So I suggest rather than doing a search and replace for > > > "tasklet" to "BH blahblah" (sorry, I don't remember what you replaced > > > it with) just get rid of that bit of the comment. > > > > > > > Thank you Russell. > > > > I will get rid of the comment. If it helps, I can create a patch for each > > driver. We did that in the past, with this series, I thought it would be > > easier to apply one patch. > > Hi Allen and Russell, > > My 2c worth: > > * In general non bug-fix patches for networking code should be targeted at > net-next. This means that they should include net-next in the subject, > and be based on that tree. > > Subject: [PATCH net-next] ... > > * This series does not appear to apply to net-next > > * This series appears to depend on code which is not present in net-next. > f.e. disable_work_sync > > * The Infiniband patches should probably be submitted separately > to the relevant maintainers > > * As this patch seems to involve many non-trivial changes > it seems to me that it would be best to break it up somehow. > To allow proper review. > > * Patch-sets for net-next should be limited to 15 patches, > so perhaps multiple sequential batches would be a way forwards. > > Link: https://docs.kernel.org/process/maintainer-netdev.html Thank you very much for taking the time to write back. Since the patches that are necessary for this series are not in net-next, I could not target net-next. I will wait for the patches to land in net-next, and the v2 will be broken into multiple smaller sets(per driver). Thanks. Allen
Re: [PATCH 1/1] arch/fault: don't print logs for simulated poison errors
On 5/9/24 1:39 PM, Axel Rasmussen wrote:
For real MCEs, various architectures print log messages when poisoned
memory is accessed (which results in a SIGBUS). These messages can be
important for users to understand the issue.
On the other hand, we have the userfaultfd UFFDIO_POISON operation,
which can "simulate" memory poisoning. That particular process will get
SIGBUS on access to the memory, but this effect is tied to an MM, rather
than being global like a real poison event. So, we don't want to log
about this case to the global kernel log; instead, let the process
itself log or whatever else it wants to do. This avoids spamming the
kernel log, and avoids e.g. drowning out real events with simulated
ones.
To identify this situation, add a new VM_FAULT_HWPOISON_SIM flag. This
is expected to be set *in addition to* one of the existing
VM_FAULT_HWPOISON or VM_FAULT_HWPOISON_LARGE flags (which are mutually
exclusive).
Signed-off-by: Axel Rasmussen
---
arch/parisc/mm/fault.c | 7 +--
arch/powerpc/mm/fault.c | 6 --
arch/x86/mm/fault.c | 6 --
include/linux/mm_types.h | 5 +
mm/hugetlb.c | 3 ++-
mm/memory.c | 2 +-
6 files changed, 21 insertions(+), 8 deletions(-)
This completely fixes the uffd-unit-test behavior, I just did a quick
test run to be sure as well.
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
diff --git a/arch/parisc/mm/fault.c b/arch/parisc/mm/fault.c
index c39de84e98b0..e5370bcadf27 100644
--- a/arch/parisc/mm/fault.c
+++ b/arch/parisc/mm/fault.c
@@ -400,9 +400,12 @@ void do_page_fault(struct pt_regs *regs, unsigned long
code,
#ifdef CONFIG_MEMORY_FAILURE
if (fault & (VM_FAULT_HWPOISON|VM_FAULT_HWPOISON_LARGE)) {
unsigned int lsb = 0;
- printk(KERN_ERR
+
+ if (!(fault & VM_FAULT_HWPOISON_SIM)) {
+ pr_err(
"MCE: Killing %s:%d due to hardware memory corruption fault at %08lx\n",
- tsk->comm, tsk->pid, address);
+ tsk->comm, tsk->pid, address);
+ }
/*
* Either small page or large page may be poisoned.
* In other words, VM_FAULT_HWPOISON_LARGE and
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 53335ae21a40..ac5e8a3c7fba 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -140,8 +140,10 @@ static int do_sigbus(struct pt_regs *regs, unsigned long
address,
if (fault & (VM_FAULT_HWPOISON|VM_FAULT_HWPOISON_LARGE)) {
unsigned int lsb = 0; /* shutup gcc */
- pr_err("MCE: Killing %s:%d due to hardware memory corruption fault at %lx\n",
- current->comm, current->pid, address);
+ if (!(fault & VM_FAULT_HWPOISON_SIM)) {
+ pr_err("MCE: Killing %s:%d due to hardware memory corruption
fault at %lx\n",
+ current->comm, current->pid, address);
+ }
if (fault & VM_FAULT_HWPOISON_LARGE)
lsb = hstate_index_to_shift(VM_FAULT_GET_HINDEX(fault));
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index e4f3c7721f45..16d077a3ad14 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -928,9 +928,11 @@ do_sigbus(struct pt_regs *regs, unsigned long error_code,
unsigned long address,
struct task_struct *tsk = current;
unsigned lsb = 0;
- pr_err_ratelimited(
+ if (!(fault & VM_FAULT_HWPOISON_SIM)) {
+ pr_err_ratelimited(
"MCE: Killing %s:%d due to hardware memory corruption fault at %lx\n",
- tsk->comm, tsk->pid, address);
+ tsk->comm, tsk->pid, address);
+ }
if (fault & VM_FAULT_HWPOISON_LARGE)
lsb = hstate_index_to_shift(VM_FAULT_GET_HINDEX(fault));
if (fault & VM_FAULT_HWPOISON)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 5240bd7bca33..7f8fc3efc5b2 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -1226,6 +1226,9 @@ typedef __bitwise unsigned int vm_fault_t;
* @VM_FAULT_HWPOISON_LARGE: Hit poisoned large page. Index encoded
*in upper bits
* @VM_FAULT_SIGSEGV: segmentation fault
+ * @VM_FAULT_HWPOISON_SIM Hit poisoned, PTE marker; this indicates a
+ * simulated poison (e.g. via usefaultfd's
+ * UFFDIO_POISON), not a "real" hwerror.
* @VM_FAULT_NOPAGE: ->fault installed the pte, not return page
* @VM_FAULT_LOCKED: ->fault locked the returned page
* @VM_FAULT_RETRY: ->fault blocked, must retry
@@ -1245,6 +1248,7 @@ enum vm_fault_reason {
VM_FAULT_HWPOISON =
Re: [PATCH 0/1] arch/fault: don't print logs for simulated poison errors
On 5/9/24 1:39 PM, Axel Rasmussen wrote: This patch expects to be applied on top of both of the following related fixes: - x86/fault: speed up uffd-unit-test by 10x: rate-limit "MCE: Killing" logs https://lore.kernel.org/r/20240507022939.236896-1-jhubb...@nvidia.com This got mostly effectively nacked. I disagree with that but do not intend to "appeal". :) - [0/2] Minor fixups for hugetlb fault path https://lore.kernel.org/r/20240509100148.22384-1-osalva...@suse.de The latter is in mm-unstable currently, but the former is not (yet?). It would need to be taken before this patch for it to apply cleanly. Axel Rasmussen (1): arch/fault: don't print logs for simulated poison errors arch/parisc/mm/fault.c | 7 +-- arch/powerpc/mm/fault.c | 6 -- arch/x86/mm/fault.c | 6 -- include/linux/mm_types.h | 5 + mm/hugetlb.c | 3 ++- mm/memory.c | 2 +- 6 files changed, 21 insertions(+), 8 deletions(-) -- 2.45.0.118.g7fe29c98d7-goog thanks, -- John Hubbard NVIDIA
Re: [PATCH 1/1] arch/fault: don't print logs for simulated poison errors
On Thu, May 09, 2024 at 01:39:07PM -0700, Axel Rasmussen wrote:
> For real MCEs, various architectures print log messages when poisoned
> memory is accessed (which results in a SIGBUS). These messages can be
> important for users to understand the issue.
>
> On the other hand, we have the userfaultfd UFFDIO_POISON operation,
> which can "simulate" memory poisoning. That particular process will get
It also coveres swapin errors as we talked before, so not always SIM.
I was thinking we should also do that report for swapin errors, however
then I noticed it wasn't reported before the replacement of pte markers,
in commit 15520a3f04, since 2022:
@@ -3727,8 +3731,6 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
put_page(vmf->page);
} else if (is_hwpoison_entry(entry)) {
ret = VM_FAULT_HWPOISON;
- } else if (is_swapin_error_entry(entry)) {
- ret = VM_FAULT_SIGBUS;
} else if (is_pte_marker_entry(entry)) {
ret = handle_pte_marker(vmf);
} else {
So I am guessing it could be fine to just turn this report off to syslog.
There will be a back-and-forth on this behavior, but hopefully this is even
rarer than hwpoison so nobody will notice.
With that, the idea looks valid to me, but perhaps a rename is needed.
Maybe _QUIESCE or _SILENT?
> SIGBUS on access to the memory, but this effect is tied to an MM, rather
> than being global like a real poison event. So, we don't want to log
> about this case to the global kernel log; instead, let the process
> itself log or whatever else it wants to do. This avoids spamming the
> kernel log, and avoids e.g. drowning out real events with simulated
> ones.
>
> To identify this situation, add a new VM_FAULT_HWPOISON_SIM flag. This
> is expected to be set *in addition to* one of the existing
> VM_FAULT_HWPOISON or VM_FAULT_HWPOISON_LARGE flags (which are mutually
> exclusive).
>
> Signed-off-by: Axel Rasmussen
> ---
> arch/parisc/mm/fault.c | 7 +--
> arch/powerpc/mm/fault.c | 6 --
> arch/x86/mm/fault.c | 6 --
> include/linux/mm_types.h | 5 +
> mm/hugetlb.c | 3 ++-
> mm/memory.c | 2 +-
> 6 files changed, 21 insertions(+), 8 deletions(-)
>
> diff --git a/arch/parisc/mm/fault.c b/arch/parisc/mm/fault.c
> index c39de84e98b0..e5370bcadf27 100644
> --- a/arch/parisc/mm/fault.c
> +++ b/arch/parisc/mm/fault.c
> @@ -400,9 +400,12 @@ void do_page_fault(struct pt_regs *regs, unsigned long
> code,
> #ifdef CONFIG_MEMORY_FAILURE
> if (fault & (VM_FAULT_HWPOISON|VM_FAULT_HWPOISON_LARGE)) {
> unsigned int lsb = 0;
> - printk(KERN_ERR
> +
> + if (!(fault & VM_FAULT_HWPOISON_SIM)) {
> + pr_err(
> "MCE: Killing %s:%d due to hardware memory corruption fault at %08lx\n",
> - tsk->comm, tsk->pid, address);
> + tsk->comm, tsk->pid, address);
> + }
> /*
>* Either small page or large page may be poisoned.
>* In other words, VM_FAULT_HWPOISON_LARGE and
> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> index 53335ae21a40..ac5e8a3c7fba 100644
> --- a/arch/powerpc/mm/fault.c
> +++ b/arch/powerpc/mm/fault.c
> @@ -140,8 +140,10 @@ static int do_sigbus(struct pt_regs *regs, unsigned long
> address,
> if (fault & (VM_FAULT_HWPOISON|VM_FAULT_HWPOISON_LARGE)) {
> unsigned int lsb = 0; /* shutup gcc */
>
> - pr_err("MCE: Killing %s:%d due to hardware memory corruption
> fault at %lx\n",
> - current->comm, current->pid, address);
> + if (!(fault & VM_FAULT_HWPOISON_SIM)) {
> + pr_err("MCE: Killing %s:%d due to hardware memory
> corruption fault at %lx\n",
> + current->comm, current->pid, address);
> + }
>
> if (fault & VM_FAULT_HWPOISON_LARGE)
> lsb = hstate_index_to_shift(VM_FAULT_GET_HINDEX(fault));
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index e4f3c7721f45..16d077a3ad14 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -928,9 +928,11 @@ do_sigbus(struct pt_regs *regs, unsigned long
> error_code, unsigned long address,
> struct task_struct *tsk = current;
> unsigned lsb = 0;
>
> - pr_err_ratelimited(
> + if (!(fault & VM_FAULT_HWPOISON_SIM)) {
> + pr_err_ratelimited(
> "MCE: Killing %s:%d due to hardware memory corruption fault at %lx\n",
> - tsk->comm, tsk->pid, address);
> + tsk->comm, tsk->pid, address);
> + }
> if (fault & VM_FAULT_HWPOISON_LARGE)
> lsb =
Re: [PATCH V2 4/9] tools/perf: Add support to capture and parse raw instruction in objdump
On Thu, May 9, 2024 at 10:27 AM Athira Rajeev
wrote:
>
>
>
> > On 7 May 2024, at 3:05 PM, Christophe Leroy
> > wrote:
> >
> >
> >
> > Le 06/05/2024 à 14:19, Athira Rajeev a écrit :
> >> Add support to capture and parse raw instruction in objdump.
> >
> > What's the purpose of using 'objdump' for reading raw instructions ?
> > Can't they be read directly without invoking 'objdump' ? It looks odd to
> > me to use objdump to provide readable text and then parse it back.
>
> Hi Christophe,
>
> Thanks for your review comments.
>
> Current implementation for data type profiling on X86 uses "objdump" tool to
> get the disassembled code.
> And then the objdump result lines are parsed to get the instruction name and
> register fields. The initial patchset I posted to enable the data type
> profiling feature in powerpc was using the same way by getting disassembled
> code from objdump and parsing the disassembled lines. But in V2, we are
> introducing change for powerpc to use "raw instruction" and fetch opcode, reg
> fields from the raw instruction.
>
> I tried to explain below that current objdump uses option
> "--no-show-raw-insn" which doesn't capture raw instruction. So to capture
> raw instruction, V2 patchset has changes to use default option
> "--show-raw-insn" and get the raw instruction [ for powerpc ] along with
> human readable annotation [ which is used by other archs ]. Since perf tool
> already has objdump implementation in place, I went in the direction to
> enhance it to use "--show-raw-insn" for powerpc purpose.
>
> But as you mentioned, we can directly read raw instruction without using
> "objdump" tool.
> perf has support to read object code. The dso open/read utilities and helper
> functions are already present in "util/dso.c" And "dso__data_read_offset"
> function reads data from dso file offset. We can use these functions and I
> can make changes to directly read binary instruction without using objdump.
>
> Namhyung, Arnaldo, Christophe
> Looking for your valuable feedback on this approach. Please suggest if this
> approach looks fine
Looks like you want to implement instruction decoding
like in arch/x86/lib/{insn,inat}.c. I think it's ok to do that
but you need to decide which way is more convenient.
Also it works on the struct disasm_line so you need to
fill in the necessary info when not using objdump. As
long as it produces the same output I don't care much
if you use objdump or not. Actually it uses libcapstone
to disassemble x86 instructions if possible. Maybe you
can use that on powerpc too.
Thanks,
Namhyung
>
>
> Thanks
> Athira
> >
> >> Currently, the perf tool infrastructure uses "--no-show-raw-insn" option
> >> with "objdump" while disassemble. Example from powerpc with this option
> >> for an instruction address is:
> >
> > Yes and that makes sense because the purpose of objdump is to provide
> > human readable annotations, not to perform automated analysis. Am I
> > missing something ?
> >
> >>
> >> Snippet from:
> >> objdump --start-address= --stop-address= -d
> >> --no-show-raw-insn -C
> >>
> >> c10224b4: lwz r10,0(r9)
> >>
> >> This line "lwz r10,0(r9)" is parsed to extract instruction name,
> >> registers names and offset. Also to find whether there is a memory
> >> reference in the operands, "memory_ref_char" field of objdump is used.
> >> For x86, "(" is used as memory_ref_char to tackle instructions of the
> >> form "mov (%rax), %rcx".
> >>
> >> In case of powerpc, not all instructions using "(" are the only memory
> >> instructions. Example, above instruction can also be of extended form (X
> >> form) "lwzx r10,0,r19". Inorder to easy identify the instruction category
> >> and extract the source/target registers, patch adds support to use raw
> >> instruction. With raw instruction, macros are added to extract opcode
> >> and register fields.
> >>
> >> "struct ins_operands" and "struct ins" is updated to carry opcode and
> >> raw instruction binary code (raw_insn). Function "disasm_line__parse"
> >> is updated to fill the raw instruction hex value and opcode in newly
> >> added fields. There is no changes in existing code paths, which parses
> >> the disassembled code. The architecture using the instruction name and
> >> present approach is not altered. Since this approach targets powerpc,
> >> the macro implementation is added for powerpc as of now.
> >>
> >> Example:
> >> representation using --show-raw-insn in objdump gives result:
> >>
> >> 38 01 81 e8 ld r4,312(r1)
> >>
> >> Here "38 01 81 e8" is the raw instruction representation. In powerpc,
> >> this translates to instruction form: "ld RT,DS(RA)" and binary code
> >> as:
> >> _
> >> | 58 | RT | RA | DS | |
> >> -
> >> 06 1116 30 31
> >>
> >> Function "disasm_line__parse" is updated to capture:
> >>
> >> line:38 01 81 e8 ld r4,312(r1)
> >>
[PATCH 1/1] arch/fault: don't print logs for simulated poison errors
For real MCEs, various architectures print log messages when poisoned
memory is accessed (which results in a SIGBUS). These messages can be
important for users to understand the issue.
On the other hand, we have the userfaultfd UFFDIO_POISON operation,
which can "simulate" memory poisoning. That particular process will get
SIGBUS on access to the memory, but this effect is tied to an MM, rather
than being global like a real poison event. So, we don't want to log
about this case to the global kernel log; instead, let the process
itself log or whatever else it wants to do. This avoids spamming the
kernel log, and avoids e.g. drowning out real events with simulated
ones.
To identify this situation, add a new VM_FAULT_HWPOISON_SIM flag. This
is expected to be set *in addition to* one of the existing
VM_FAULT_HWPOISON or VM_FAULT_HWPOISON_LARGE flags (which are mutually
exclusive).
Signed-off-by: Axel Rasmussen
---
arch/parisc/mm/fault.c | 7 +--
arch/powerpc/mm/fault.c | 6 --
arch/x86/mm/fault.c | 6 --
include/linux/mm_types.h | 5 +
mm/hugetlb.c | 3 ++-
mm/memory.c | 2 +-
6 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/arch/parisc/mm/fault.c b/arch/parisc/mm/fault.c
index c39de84e98b0..e5370bcadf27 100644
--- a/arch/parisc/mm/fault.c
+++ b/arch/parisc/mm/fault.c
@@ -400,9 +400,12 @@ void do_page_fault(struct pt_regs *regs, unsigned long
code,
#ifdef CONFIG_MEMORY_FAILURE
if (fault & (VM_FAULT_HWPOISON|VM_FAULT_HWPOISON_LARGE)) {
unsigned int lsb = 0;
- printk(KERN_ERR
+
+ if (!(fault & VM_FAULT_HWPOISON_SIM)) {
+ pr_err(
"MCE: Killing %s:%d due to hardware memory corruption fault at %08lx\n",
- tsk->comm, tsk->pid, address);
+ tsk->comm, tsk->pid, address);
+ }
/*
* Either small page or large page may be poisoned.
* In other words, VM_FAULT_HWPOISON_LARGE and
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 53335ae21a40..ac5e8a3c7fba 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -140,8 +140,10 @@ static int do_sigbus(struct pt_regs *regs, unsigned long
address,
if (fault & (VM_FAULT_HWPOISON|VM_FAULT_HWPOISON_LARGE)) {
unsigned int lsb = 0; /* shutup gcc */
- pr_err("MCE: Killing %s:%d due to hardware memory corruption
fault at %lx\n",
- current->comm, current->pid, address);
+ if (!(fault & VM_FAULT_HWPOISON_SIM)) {
+ pr_err("MCE: Killing %s:%d due to hardware memory
corruption fault at %lx\n",
+ current->comm, current->pid, address);
+ }
if (fault & VM_FAULT_HWPOISON_LARGE)
lsb = hstate_index_to_shift(VM_FAULT_GET_HINDEX(fault));
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index e4f3c7721f45..16d077a3ad14 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -928,9 +928,11 @@ do_sigbus(struct pt_regs *regs, unsigned long error_code,
unsigned long address,
struct task_struct *tsk = current;
unsigned lsb = 0;
- pr_err_ratelimited(
+ if (!(fault & VM_FAULT_HWPOISON_SIM)) {
+ pr_err_ratelimited(
"MCE: Killing %s:%d due to hardware memory corruption fault at %lx\n",
- tsk->comm, tsk->pid, address);
+ tsk->comm, tsk->pid, address);
+ }
if (fault & VM_FAULT_HWPOISON_LARGE)
lsb = hstate_index_to_shift(VM_FAULT_GET_HINDEX(fault));
if (fault & VM_FAULT_HWPOISON)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 5240bd7bca33..7f8fc3efc5b2 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -1226,6 +1226,9 @@ typedef __bitwise unsigned int vm_fault_t;
* @VM_FAULT_HWPOISON_LARGE: Hit poisoned large page. Index encoded
* in upper bits
* @VM_FAULT_SIGSEGV: segmentation fault
+ * @VM_FAULT_HWPOISON_SIM Hit poisoned, PTE marker; this indicates a
+ * simulated poison (e.g. via usefaultfd's
+ * UFFDIO_POISON), not a "real" hwerror.
* @VM_FAULT_NOPAGE: ->fault installed the pte, not return page
* @VM_FAULT_LOCKED: ->fault locked the returned page
* @VM_FAULT_RETRY:->fault blocked, must retry
@@ -1245,6 +1248,7 @@ enum vm_fault_reason {
VM_FAULT_HWPOISON = (__force vm_fault_t)0x10,
VM_FAULT_HWPOISON_LARGE = (__force vm_fault_t)0x20,
VM_FAULT_SIGSEGV= (__force vm_fault_t)0x40,
+
[PATCH 0/1] arch/fault: don't print logs for simulated poison errors
This patch expects to be applied on top of both of the following related fixes: - x86/fault: speed up uffd-unit-test by 10x: rate-limit "MCE: Killing" logs https://lore.kernel.org/r/20240507022939.236896-1-jhubb...@nvidia.com - [0/2] Minor fixups for hugetlb fault path https://lore.kernel.org/r/20240509100148.22384-1-osalva...@suse.de The latter is in mm-unstable currently, but the former is not (yet?). It would need to be taken before this patch for it to apply cleanly. Axel Rasmussen (1): arch/fault: don't print logs for simulated poison errors arch/parisc/mm/fault.c | 7 +-- arch/powerpc/mm/fault.c | 6 -- arch/x86/mm/fault.c | 6 -- include/linux/mm_types.h | 5 + mm/hugetlb.c | 3 ++- mm/memory.c | 2 +- 6 files changed, 21 insertions(+), 8 deletions(-) -- 2.45.0.118.g7fe29c98d7-goog
Re: [PATCH V2 4/9] tools/perf: Add support to capture and parse raw instruction in objdump
> On 7 May 2024, at 3:05 PM, Christophe Leroy
> wrote:
>
>
>
> Le 06/05/2024 à 14:19, Athira Rajeev a écrit :
>> Add support to capture and parse raw instruction in objdump.
>
> What's the purpose of using 'objdump' for reading raw instructions ?
> Can't they be read directly without invoking 'objdump' ? It looks odd to
> me to use objdump to provide readable text and then parse it back.
Hi Christophe,
Thanks for your review comments.
Current implementation for data type profiling on X86 uses "objdump" tool to
get the disassembled code.
And then the objdump result lines are parsed to get the instruction name and
register fields. The initial patchset I posted to enable the data type
profiling feature in powerpc was using the same way by getting disassembled
code from objdump and parsing the disassembled lines. But in V2, we are
introducing change for powerpc to use "raw instruction" and fetch opcode, reg
fields from the raw instruction.
I tried to explain below that current objdump uses option "--no-show-raw-insn"
which doesn't capture raw instruction. So to capture raw instruction, V2
patchset has changes to use default option "--show-raw-insn" and get the raw
instruction [ for powerpc ] along with human readable annotation [ which is
used by other archs ]. Since perf tool already has objdump implementation in
place, I went in the direction to enhance it to use "--show-raw-insn" for
powerpc purpose.
But as you mentioned, we can directly read raw instruction without using
"objdump" tool.
perf has support to read object code. The dso open/read utilities and helper
functions are already present in "util/dso.c" And "dso__data_read_offset"
function reads data from dso file offset. We can use these functions and I can
make changes to directly read binary instruction without using objdump.
Namhyung, Arnaldo, Christophe
Looking for your valuable feedback on this approach. Please suggest if this
approach looks fine
Thanks
Athira
>
>> Currently, the perf tool infrastructure uses "--no-show-raw-insn" option
>> with "objdump" while disassemble. Example from powerpc with this option
>> for an instruction address is:
>
> Yes and that makes sense because the purpose of objdump is to provide
> human readable annotations, not to perform automated analysis. Am I
> missing something ?
>
>>
>> Snippet from:
>> objdump --start-address= --stop-address= -d
>> --no-show-raw-insn -C
>>
>> c10224b4: lwz r10,0(r9)
>>
>> This line "lwz r10,0(r9)" is parsed to extract instruction name,
>> registers names and offset. Also to find whether there is a memory
>> reference in the operands, "memory_ref_char" field of objdump is used.
>> For x86, "(" is used as memory_ref_char to tackle instructions of the
>> form "mov (%rax), %rcx".
>>
>> In case of powerpc, not all instructions using "(" are the only memory
>> instructions. Example, above instruction can also be of extended form (X
>> form) "lwzx r10,0,r19". Inorder to easy identify the instruction category
>> and extract the source/target registers, patch adds support to use raw
>> instruction. With raw instruction, macros are added to extract opcode
>> and register fields.
>>
>> "struct ins_operands" and "struct ins" is updated to carry opcode and
>> raw instruction binary code (raw_insn). Function "disasm_line__parse"
>> is updated to fill the raw instruction hex value and opcode in newly
>> added fields. There is no changes in existing code paths, which parses
>> the disassembled code. The architecture using the instruction name and
>> present approach is not altered. Since this approach targets powerpc,
>> the macro implementation is added for powerpc as of now.
>>
>> Example:
>> representation using --show-raw-insn in objdump gives result:
>>
>> 38 01 81 e8 ld r4,312(r1)
>>
>> Here "38 01 81 e8" is the raw instruction representation. In powerpc,
>> this translates to instruction form: "ld RT,DS(RA)" and binary code
>> as:
>> _
>> | 58 | RT | RA | DS | |
>> -
>> 06 1116 30 31
>>
>> Function "disasm_line__parse" is updated to capture:
>>
>> line:38 01 81 e8 ld r4,312(r1)
>> opcode and raw instruction "38 01 81 e8"
>> Raw instruction is used later to extract the reg/offset fields.
>>
>> Signed-off-by: Athira Rajeev
>> ---
Re: [PATCH 2/4] ASoC: dt-bindings: fsl,xcvr: Add two PLL clock sources
On Thu, May 09, 2024 at 10:57:38AM +0800, Shengjiu Wang wrote: > Add two PLL clock sources, they are the parent clocks of the root clock > one is for 8kHz series rates, named as 'pll8k', another one is for > 11kHz series rates, named as 'pll11k'. They are optional clocks, > if there are such clocks, then the driver can switch between them to > support more accurate sample rates. > > As 'pll8k' and 'pll11k' are optional, then add 'minItems: 4' for > clocks and clock-names properties. Despite the detail given here in the commit message, the series this is appearing in and one of the driver patches makes me a bit "suspicious" of this patch. Are these newly added clocks available on all devices, or just on the imx95, or? Thanks, Conor. > > Signed-off-by: Shengjiu Wang > --- > Documentation/devicetree/bindings/sound/fsl,xcvr.yaml | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml > b/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml > index 1c74a32def09..c4660faed404 100644 > --- a/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml > +++ b/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml > @@ -50,6 +50,9 @@ properties: >- description: PHY clock >- description: SPBA clock >- description: PLL clock > + - description: PLL clock source for 8kHz series > + - description: PLL clock source for 11kHz series > +minItems: 4 > >clock-names: > items: > @@ -57,6 +60,9 @@ properties: >- const: phy >- const: spba >- const: pll_ipg > + - const: pll8k > + - const: pll11k > +minItems: 4 > >dmas: > items: > -- > 2.34.1 > signature.asc Description: PGP signature
Re: [PATCH 1/4] ASoC: dt-bindings: fsl,xcvr: Add compatible string for i.MX95
On Thu, May 09, 2024 at 10:57:37AM +0800, Shengjiu Wang wrote: > Add compatible string "fsl,imx95-xcvr" for i.MX95 platform. That's apparent from the diff. Why is it not compatible with existing devices? Cheers, Conor. > > Signed-off-by: Shengjiu Wang > --- > Documentation/devicetree/bindings/sound/fsl,xcvr.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml > b/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml > index 0eb0c1ba8710..1c74a32def09 100644 > --- a/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml > +++ b/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml > @@ -22,6 +22,7 @@ properties: > enum: >- fsl,imx8mp-xcvr >- fsl,imx93-xcvr > + - fsl,imx95-xcvr > >reg: > items: > -- > 2.34.1 > signature.asc Description: PGP signature
Re: [PATCH 3/3] powerpc: Check only single values are passed to CPU/MMU feature checks
On Thu, May 09, 2024 at 10:12:48PM +1000, Michael Ellerman wrote: > cpu_has_feature()/mmu_has_feature() are only able to check a single > feature at a time, but there is no enforcement of that. > > In fact, as fixed in the previous commit, there was code that was > passing multiple values to cpu_has_feature(). > > So add a check that only a single feature is passed using popcount. > > Note that the test allows 0 or 1 bits to be set, because some code > relies on cpu_has_feature(0) being false, the check with > CPU_FTRS_POSSIBLE ensures that. See for example CPU_FTR_PPC_LE. This btw is exactly BUILD_BUG_ON(feature & (feature - 1)); but the popcount is more readable :-) Segher
[powerpc:next] BUILD SUCCESS 98ec6d38ee57a734123c6f5d42640804034024ef
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next branch HEAD: 98ec6d38ee57a734123c6f5d42640804034024ef selftests/powerpc/dexcr: Fix spelling mistake "predicition" -> "prediction" elapsed time: 1455m configs tested: 194 configs skipped: 6 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc alphaallyesconfig gcc alpha defconfig gcc arc allmodconfig gcc arc allnoconfig gcc arc allyesconfig gcc arc defconfig gcc arc randconfig-001-20240509 gcc arc randconfig-002-20240509 gcc arcvdk_hs38_smp_defconfig gcc arm allmodconfig gcc arm allnoconfig clang arm allyesconfig gcc arm defconfig clang arm randconfig-001-20240509 gcc arm randconfig-002-20240509 clang arm randconfig-003-20240509 clang arm randconfig-004-20240509 clang arm s3c6400_defconfig gcc arm sama5_defconfig gcc arm tegra_defconfig gcc arm64alldefconfig gcc arm64allmodconfig clang arm64 allnoconfig gcc arm64allyesconfig clang arm64 defconfig gcc arm64 randconfig-001-20240509 clang arm64 randconfig-002-20240509 clang arm64 randconfig-003-20240509 gcc arm64 randconfig-004-20240509 clang csky allmodconfig gcc csky allnoconfig gcc csky allyesconfig gcc cskydefconfig gcc csky randconfig-001-20240509 gcc csky randconfig-002-20240509 gcc hexagon allmodconfig clang hexagon allnoconfig clang hexagon allyesconfig clang hexagon defconfig clang hexagon randconfig-001-20240509 clang hexagon randconfig-002-20240509 clang i386 allmodconfig gcc i386 allnoconfig gcc i386 allyesconfig gcc i386 buildonly-randconfig-001-20240509 gcc i386 buildonly-randconfig-002-20240509 gcc i386 buildonly-randconfig-003-20240509 clang i386 buildonly-randconfig-004-20240509 clang i386 buildonly-randconfig-005-20240509 gcc i386 buildonly-randconfig-006-20240509 gcc i386defconfig clang i386 randconfig-001-20240509 clang i386 randconfig-002-20240509 clang i386 randconfig-003-20240509 clang i386 randconfig-004-20240509 gcc i386 randconfig-005-20240509 clang i386 randconfig-006-20240509 gcc i386 randconfig-011-20240509 clang i386 randconfig-012-20240509 gcc i386 randconfig-013-20240509 clang i386 randconfig-014-20240509 gcc i386 randconfig-015-20240509 gcc i386 randconfig-016-20240509 gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarchallyesconfig gcc loongarch defconfig gcc loongarch randconfig-001-20240509 gcc loongarch randconfig-002-20240509 gcc m68k allmodconfig gcc m68k allnoconfig gcc m68k allyesconfig gcc m68kdefconfig gcc m68km5307c3_defconfig gcc m68kstmark2_defconfig gcc microblaze allmodconfig gcc microblazeallnoconfig gcc microblaze allyesconfig gcc microblaze defconfig gcc mips allmodconfig gcc mips allnoconfig gcc mips allyesconfig gcc mips cu1000-neo_defconfig gcc mips loongson1c_
[powerpc:merge] BUILD SUCCESS 128a9d4079079ea33e2ef44999901ec0ef3afdbf
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge branch HEAD: 128a9d4079079ea33e2ef4401ec0ef3afdbf Automatic merge of 'next' into merge (2024-05-08 22:44) elapsed time: 1452m configs tested: 158 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc alphaallyesconfig gcc alpha defconfig gcc arc allmodconfig gcc arc allnoconfig gcc arc allyesconfig gcc arc defconfig gcc arc randconfig-001-20240509 gcc arc randconfig-002-20240509 gcc arm allmodconfig gcc arm allnoconfig clang arm allyesconfig gcc arm defconfig clang arm randconfig-001-20240509 gcc arm randconfig-002-20240509 clang arm randconfig-003-20240509 clang arm randconfig-004-20240509 clang arm64allmodconfig clang arm64 allnoconfig gcc arm64 defconfig gcc arm64 randconfig-001-20240509 clang arm64 randconfig-002-20240509 clang arm64 randconfig-003-20240509 gcc arm64 randconfig-004-20240509 clang csky allmodconfig gcc csky allnoconfig gcc csky allyesconfig gcc cskydefconfig gcc csky randconfig-001-20240509 gcc csky randconfig-002-20240509 gcc hexagon allmodconfig clang hexagon allnoconfig clang hexagon allyesconfig clang hexagon defconfig clang hexagon randconfig-001-20240509 clang hexagon randconfig-002-20240509 clang i386 allmodconfig gcc i386 allnoconfig gcc i386 allyesconfig gcc i386 buildonly-randconfig-001-20240509 gcc i386 buildonly-randconfig-002-20240509 gcc i386 buildonly-randconfig-003-20240509 clang i386 buildonly-randconfig-004-20240509 clang i386 buildonly-randconfig-005-20240509 gcc i386 buildonly-randconfig-006-20240509 gcc i386defconfig clang i386 randconfig-001-20240509 clang i386 randconfig-002-20240509 clang i386 randconfig-003-20240509 clang i386 randconfig-004-20240509 gcc i386 randconfig-005-20240509 clang i386 randconfig-006-20240509 gcc i386 randconfig-011-20240509 clang i386 randconfig-012-20240509 gcc i386 randconfig-013-20240509 clang i386 randconfig-014-20240509 gcc i386 randconfig-015-20240509 gcc i386 randconfig-016-20240509 gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarch defconfig gcc loongarch randconfig-001-20240509 gcc loongarch randconfig-002-20240509 gcc m68k allmodconfig gcc m68k allnoconfig gcc m68k allyesconfig gcc m68kdefconfig gcc microblaze allmodconfig gcc microblazeallnoconfig gcc microblaze allyesconfig gcc microblaze defconfig gcc mips allnoconfig gcc mips allyesconfig gcc nios2allmodconfig gcc nios2 allnoconfig gcc nios2allyesconfig gcc nios2 defconfig gcc nios2 randconfig-001-20240509 gcc nios2 randconfig-002-20240509 gcc openrisc allnoconfig gcc openrisc allyesconfig gcc openriscdefconfig gcc pariscallnoconfig gcc parisc allyesconfig gcc parisc defconfig gcc parisc
[PATCH 1/3] powerpc: Drop clang workaround for builtin constant checks
The CPU/MMU feature code has build-time checks that the feature value is
a builtin constant.
Back when the code was added clang wasn't able to compile the
checks, so an ifdef was added to avoid the checks for clang builds.
See b5fa0f7f88ed ("powerpc: Fix build failure with clang due to
BUILD_BUG_ON()")
These days clang 13 and later are able to build the checks successfully,
so drop the workaround.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/cpu_has_feature.h | 2 --
arch/powerpc/include/asm/mmu.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/arch/powerpc/include/asm/cpu_has_feature.h
b/arch/powerpc/include/asm/cpu_has_feature.h
index 0efabccd820c..92e24e979954 100644
--- a/arch/powerpc/include/asm/cpu_has_feature.h
+++ b/arch/powerpc/include/asm/cpu_has_feature.h
@@ -24,9 +24,7 @@ static __always_inline bool cpu_has_feature(unsigned long
feature)
{
int i;
-#ifndef __clang__ /* clang can't cope with this */
BUILD_BUG_ON(!__builtin_constant_p(feature));
-#endif
#ifdef CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG
if (!static_key_feature_checks_initialized) {
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index 24f830cf9bb4..4ab9a630d943 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -246,9 +246,7 @@ static __always_inline bool mmu_has_feature(unsigned long
feature)
{
int i;
-#ifndef __clang__ /* clang can't cope with this */
BUILD_BUG_ON(!__builtin_constant_p(feature));
-#endif
#ifdef CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG
if (!static_key_feature_checks_initialized) {
--
2.45.0
[PATCH 3/3] powerpc: Check only single values are passed to CPU/MMU feature checks
cpu_has_feature()/mmu_has_feature() are only able to check a single
feature at a time, but there is no enforcement of that.
In fact, as fixed in the previous commit, there was code that was
passing multiple values to cpu_has_feature().
So add a check that only a single feature is passed using popcount.
Note that the test allows 0 or 1 bits to be set, because some code
relies on cpu_has_feature(0) being false, the check with
CPU_FTRS_POSSIBLE ensures that. See for example CPU_FTR_PPC_LE.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/cpu_has_feature.h | 1 +
arch/powerpc/include/asm/mmu.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/powerpc/include/asm/cpu_has_feature.h
b/arch/powerpc/include/asm/cpu_has_feature.h
index 92e24e979954..bf8a228229fa 100644
--- a/arch/powerpc/include/asm/cpu_has_feature.h
+++ b/arch/powerpc/include/asm/cpu_has_feature.h
@@ -25,6 +25,7 @@ static __always_inline bool cpu_has_feature(unsigned long
feature)
int i;
BUILD_BUG_ON(!__builtin_constant_p(feature));
+ BUILD_BUG_ON(__builtin_popcountl(feature) > 1);
#ifdef CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG
if (!static_key_feature_checks_initialized) {
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index 4ab9a630d943..eb3065692055 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -247,6 +247,7 @@ static __always_inline bool mmu_has_feature(unsigned long
feature)
int i;
BUILD_BUG_ON(!__builtin_constant_p(feature));
+ BUILD_BUG_ON(__builtin_popcountl(feature) > 1);
#ifdef CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG
if (!static_key_feature_checks_initialized) {
--
2.45.0
[PATCH 2/3] powerpc/xmon: Fix disassembly CPU feature checks
In the xmon disassembly code there are several CPU feature checks to
determine what dialects should be passed to the disassembler. The
dialect controls which instructions the disassembler will recognise.
Unfortunately the checks are incorrect, because instead of passing a
single CPU feature they are passing a mask of feature bits.
For example the code:
if (cpu_has_feature(CPU_FTRS_POWER5))
dialect |= PPC_OPCODE_POWER5;
Is trying to check if the system is running on a Power5 CPU. But
CPU_FTRS_POWER5 is a mask of *all* the feature bits that are enabled on
a Power5.
In practice the test will always return true for any 64-bit CPU, because
at least one bit in the mask will be present in the CPU_FTRS_ALWAYS
mask.
Similarly for all the other checks against CPU_FTRS_xx masks.
Rather than trying to match the disassembly behaviour exactly to the
current CPU, just differentiate between 32-bit and 64-bit, and Altivec,
VSX and HTM.
That will cause some instructions to be shown in disassembly even
on a CPU that doesn't support them, but that's OK, objdump -d output
has the same behaviour, and if anything it's less confusing than some
instructions not being disassembled.
Fixes: 897f112bb42e ("[POWERPC] Import updated version of ppc disassembly code
for xmon")
Signed-off-by: Michael Ellerman
---
arch/powerpc/xmon/ppc-dis.c | 33 +++--
1 file changed, 11 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/xmon/ppc-dis.c b/arch/powerpc/xmon/ppc-dis.c
index 75fa98221d48..af105e1bc3fc 100644
--- a/arch/powerpc/xmon/ppc-dis.c
+++ b/arch/powerpc/xmon/ppc-dis.c
@@ -122,32 +122,21 @@ int print_insn_powerpc (unsigned long insn, unsigned long
memaddr)
bool insn_is_short;
ppc_cpu_t dialect;
- dialect = PPC_OPCODE_PPC | PPC_OPCODE_COMMON
-| PPC_OPCODE_64 | PPC_OPCODE_POWER4 | PPC_OPCODE_ALTIVEC;
+ dialect = PPC_OPCODE_PPC | PPC_OPCODE_COMMON;
- if (cpu_has_feature(CPU_FTRS_POWER5))
-dialect |= PPC_OPCODE_POWER5;
+ if (IS_ENABLED(CONFIG_PPC64))
+dialect |= PPC_OPCODE_64 | PPC_OPCODE_POWER4 | PPC_OPCODE_CELL |
+ PPC_OPCODE_POWER5 | PPC_OPCODE_POWER6 | PPC_OPCODE_POWER7 |
PPC_OPCODE_POWER8 |
+ PPC_OPCODE_POWER9;
- if (cpu_has_feature(CPU_FTRS_CELL))
-dialect |= (PPC_OPCODE_CELL | PPC_OPCODE_ALTIVEC);
+ if (cpu_has_feature(CPU_FTR_TM))
+dialect |= PPC_OPCODE_HTM;
- if (cpu_has_feature(CPU_FTRS_POWER6))
-dialect |= (PPC_OPCODE_POWER5 | PPC_OPCODE_POWER6 | PPC_OPCODE_ALTIVEC);
+ if (cpu_has_feature(CPU_FTR_ALTIVEC))
+dialect |= PPC_OPCODE_ALTIVEC | PPC_OPCODE_ALTIVEC2;
- if (cpu_has_feature(CPU_FTRS_POWER7))
-dialect |= (PPC_OPCODE_POWER5 | PPC_OPCODE_POWER6 | PPC_OPCODE_POWER7
-| PPC_OPCODE_ALTIVEC | PPC_OPCODE_VSX);
-
- if (cpu_has_feature(CPU_FTRS_POWER8))
-dialect |= (PPC_OPCODE_POWER5 | PPC_OPCODE_POWER6 | PPC_OPCODE_POWER7
- | PPC_OPCODE_POWER8 | PPC_OPCODE_HTM
- | PPC_OPCODE_ALTIVEC | PPC_OPCODE_ALTIVEC2 | PPC_OPCODE_VSX);
-
- if (cpu_has_feature(CPU_FTRS_POWER9))
-dialect |= (PPC_OPCODE_POWER5 | PPC_OPCODE_POWER6 | PPC_OPCODE_POWER7
- | PPC_OPCODE_POWER8 | PPC_OPCODE_POWER9 | PPC_OPCODE_HTM
- | PPC_OPCODE_ALTIVEC | PPC_OPCODE_ALTIVEC2
- | PPC_OPCODE_VSX | PPC_OPCODE_VSX3);
+ if (cpu_has_feature(CPU_FTR_VSX))
+dialect |= PPC_OPCODE_VSX | PPC_OPCODE_VSX3;
/* Get the major opcode of the insn. */
opcode = NULL;
--
2.45.0
[PATCH 2/2] arch/powerpc: hotplug driver bridge support
There is an issue with the hotplug operation when it's done on the bridge/switch slot. The bridge-port and devices behind the bridge, which become offline by hot-unplug operation, don't get hot-plugged/enabled by doing hot-plug operation on that slot. Only the first port of the bridge gets enabled and the remaining port/devices remain unplugged. The hot plug/unplug operation is done by the hotplug driver (drivers/pci/hotplug/pnv_php.c). Root Cause Analysis: This behavior is due to missing code for the DPC switch/bridge. The existing driver depends on pci_hp_add_devices() function for device enablement. This function calls pci_scan_slot() on only one device-node/port of the bridge, not on all the siblings' device-node/port. The missing code needs to be added which will find all the sibling device-nodes/bridge-ports and will run explicit pci_scan_slot() on those. A new function has been added for this purpose which gets invoked from pci_hp_add_devices(). This new function pci_traverse_sibling_nodes_and_scan_slot() gets all the sibling bridge-ports by traversal and explicitly invokes pci_scan_slot on them. Signed-off-by: Krishna Kumar --- Command for reproducing the issue : For hot unplug/disable - echo 0 > /sys/bus/pci/slots/C5/power For hot plug/enable -echo 1 > /sys/bus/pci/slots/C5/power where C5 is slot associated with bridge. Scenario/Tests: Output of lspci -nn before test is given below. This snippet contains devices used for testing on Powernv machine. 0004:02:00.0 PCI bridge [0604]: PMC-Sierra Inc. Device [11f8:4052] 0004:02:01.0 PCI bridge [0604]: PMC-Sierra Inc. Device [11f8:4052] 0004:02:02.0 PCI bridge [0604]: PMC-Sierra Inc. Device [11f8:4052] 0004:02:03.0 PCI bridge [0604]: PMC-Sierra Inc. Device [11f8:4052] 0004:08:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3216 PCI-Express Fusion-MPT SAS-3 [1000:00c9] (rev 01) 0004:09:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3216 PCI-Express Fusion-MPT SAS-3 [1000:00c9] (rev 01) Output of lspci -tv before test is as follows: # lspci -tv +-[0004:00]---00.0-[01-0e]--+-00.0-[02-0e]--+-00.0-[03-07]-- | | +-01.0-[08]00.0 Broadcom / LSI SAS3216 PCI-Express Fusion-MPT SAS-3 | | +-02.0-[09]00.0 Broadcom / LSI SAS3216 PCI-Express Fusion-MPT SAS-3 | | \-03.0-[0a-0e]-- | \-00.1 PMC-Sierra Inc. Device 4052 C5(bridge) and C6(End Point) slot address are as below: # cat /sys/bus/pci/slots/C5/address 0004:02:00 # cat /sys/bus/pci/slots/C6/address 0004:09:00 Hot-unplug operation on slot associated with bridge: # echo 0 > /sys/bus/pci/slots/C5/power # lspci -tv +-[0004:00]---00.0-[01-0e]--+-00.0-[02-0e]-- | \-00.1 PMC-Sierra Inc. Device 4052 >From the above lspci -tv output, it can be observed that hot unplug operation has removed all the PMC-Sierra bridge ports like: 00.0-[03-07], 01.0-[08], 02.0-[09], 03.0-[0a-0e] and the SAS devices behind the bridge-port. Without the fix, when the hot plug operation is done on the same slot, it adds only the first bridge port and doesn't restore all the bridge-ports and devices that it unplugged earlier. Below snippet shows this. Hot-plug operation on the bridge slot without the fix: # echo 1 > /sys/bus/pci/slots/C5/power # lspci -tv +-[0004:00]---00.0-[01-0e]--+-00.0-[02-0e]--+-00.0-[03-07]-- | \-00.1 PMC-Sierra Inc. Device 4052 After the fix, it restores all the devices in the same manner how it unplugged them earlier during the hot unplug operation. The below snippet shows the same. Hot-plug operation on bridge slot with the fix: # echo 1 > /sys/bus/pci/slots/C5/power # lspci -tv +-[0004:00]---00.0-[01-0e]--+-00.0-[02-0e]--+-00.0-[03-07]-- | | +-01.0-[08]00.0 Broadcom / LSI SAS3216 PCI-Express Fusion-MPT SAS-3 | | +-02.0-[09]00.0 Broadcom / LSI SAS3216 PCI-Express Fusion-MPT SAS-3 | | \-03.0-[0a-0e]-- | \-00.1 PMC-Sierra Inc. Device 4052 Removal of End point device behind bridge are also intact and behaving correctly. Hot-unplug operation on Endpoint device C6: # echo 0 > /sys/bus/pci/slots/C6/power # lspci -tv +-[0004:00]---00.0-[01-0e]--+-00.0-[02-0e]--+-00.0-[03-07]-- | | +-01.0-[08]00.0 Broadcom / LSI SAS3216 PCI-Express Fusion-MPT SAS-3 | | +-02.0-[09]-- | | \-03.0-[0a-0e]-- | \-00.1 PMC-Sierra Inc. Device 4052 Hot-plug operation on Endpoint device C6: # echo 1 > /sys/bus/pci/slots/C6/power # lspci -tv +-[0004:00]---00.0-[01-0e]--+-00.0-[02-0e]--+-00.0-[03-07]-- | | +-01.0-[08]00.0
[PATCH 1/2] pci/hotplug/pnv_php: Fix hotplug driver crash on Powernv
Description of the problem: The hotplug driver for powerpc
(pci/hotplug/pnv_php.c) gives kernel crash when we try to
hot-unplug/disable the PCIe switch/bridge from the PHB.
Root Cause of Crash: The crash is due to the reason that, though the msi
data structure has been released during disable/hot-unplug path and it
has been assigned with NULL, still during unregistartion the code was
again trying to explicitly disable the msi which causes the Null pointer
dereference and kernel crash.
Proposed Fix : The fix is to correct the check during unregistration path
so that the code should not try to invoke pci_disable_msi/msix() if its
data structure is already freed.
Signed-off-by: Krishna Kumar
---
Command used for reproducing the bug:
echo 0 > /sys/bus/pci/slots/C5/power
where C5 is slot associated with bridge.
Snippet of Crash:
Kernel attempted to read user page (10) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x0010
Faulting instruction address: 0xc0fad7d4
Oops: Kernel access of bad area, sig: 11 [#1]
Hardware name: 5105-22E POWER9 0x4e1203 opal:v7.0-39-g4660e63a PowerNV
NIP [c0fad7d4] mutex_lock+0x34/0x88
LR [c0fad7c8] mutex_lock+0x28/0x88
Call Trace:
[c0017075f940] [c0fad7c8] mutex_lock+0x28/0x88 (unreliable)
[c0017075f970] [c0214464] msi_lock_descs+0x28/0x3c
[c0017075f990] [c08e8be8] pci_disable_msi+0x68/0xa8
[c0017075f9c0] [c090f0a4] pnv_php_disable_irq+0x2a0/0x2b0
[c0017075fab0] [c090f128] pnv_php_free_slot+0x74/0xc4
[c0017075fb30] [c0912184] pnv_php_disable_slot.part.0+0x1b8/0x24c
[c0017075fc00] [c0902df0] power_write_file+0xf8/0x18c
[c0017075fc80] [c08f84d8] pci_slot_attr_store+0x40/0x5c
[c0017075fca0] [c06b4834] sysfs_kf_write+0x64/0x78
[c0017075fcc0] [c06b3300] kernfs_fop_write_iter+0x1b8/0x2dc
[c0017075fd10] [c05b3eb0] vfs_write+0x224/0x4e8
[c0017075fdc0] [c05b44b0] ksys_write+0x88/0x150
[c0017075fe10] [c0030864] system_call_exception+0x124/0x320
[c0017075fe50] [c000cedc] system_call_vectored_common+0x15c/0x2ec
--- interrupt: 3000 at 0x7fffb9748774
Root-Cause: Its safe to call pci_disable_msi() if its associated data structre
are
not freed (during bailout path). But when the driver code disables the
bridge during hot-unplug operation, its msi data structure becomes NULL
(php_slot->pdev->dev.msi.data:). This happens before
unregistration and during disable path in function
msi_device_data_release(). In this case, its not safe to explicitly call
pci_disable_msi/msix() due to NULL pointer dereference. But since the
current code does so, the crash is happening at the line
mutex_lock(>msi.data->mutex).
FIX: In the current code, there are two paths to invoke
pci_disable_msi/msix(). In the error/bailout path, first argument of the
check - if(disable_device || irq > 0), i.e. disable_device is true, so
it will always invoke pci_disable_msi/msix(), it will never depend on
second argument. In this path it's fine to call pci_disable_msi/msix().
During the slot releasing/disable/hot-unpug path the disable_device is
false, irq is having old value which is making the overall check true
and causing the crash. Of course, we should not choose the old/stale
value of irq but should choose php_slot->irq for check. Also, since
php_slot->irq value is always 0 before the check, so it does not matter
if it will not be included into the check. So, the check can be formed
with only one argument i.e. disable_device. Based on its value
pci_disable_msi/msix() will be invoked and this is the fix for the
crash. During the bailout path its value will be true and during the
hot-unplug operation on the bridge slot, its value will be false.
drivers/pci/hotplug/pnv_php.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/pci/hotplug/pnv_php.c b/drivers/pci/hotplug/pnv_php.c
index 694349be9d0a..573a41869c15 100644
--- a/drivers/pci/hotplug/pnv_php.c
+++ b/drivers/pci/hotplug/pnv_php.c
@@ -40,7 +40,6 @@ static void pnv_php_disable_irq(struct pnv_php_slot *php_slot,
bool disable_device)
{
struct pci_dev *pdev = php_slot->pdev;
- int irq = php_slot->irq;
u16 ctrl;
if (php_slot->irq > 0) {
@@ -59,7 +58,7 @@ static void pnv_php_disable_irq(struct pnv_php_slot *php_slot,
php_slot->wq = NULL;
}
- if (disable_device || irq > 0) {
+ if (disable_device) {
if (pdev->msix_enabled)
pci_disable_msix(pdev);
else if (pdev->msi_enabled)
--
2.44.0
[PATCH 0/2] PCI hotplug driver fixes
The fix of Powerpc hotplug driver (drivers/pci/hotplug/pnv_php.c) addresses below two issues. 1. Kernel Crash during hot unplug of bridge/switch slot. 2. DPC-Support Enablement - Previously, when we do a hot-unplug operation on a bridge slot, all the ports and devices behind the bridge-ports would be hot-unplugged/offline, but when we do a hot-plug operation on the same bridge slot, all the ports and devices behind the bridge would not get hot-plugged/online. In this case, Only the first port of the bridge gets enabled and the remaining port/devices remain unplugged/offline. After the fix, The hot-unplug and hot-plug operations on the slot associated with the bridge started behaving correctly and became in sync. Now, after the hot plug operation on the same slot, all the bridge ports and devices behind the bridge become hot-plugged/online/restored in the same manner as it was before the hot-unplug operation. Krishna Kumar (2): pci/hotplug/pnv_php: Fix hotplug driver crash on Powernv arch/powerpc: hotplug driver bridge support arch/powerpc/include/asm/ppc-pci.h | 4 +++ arch/powerpc/kernel/pci-hotplug.c | 5 ++-- arch/powerpc/kernel/pci_dn.c | 42 ++ drivers/pci/hotplug/pnv_php.c | 3 +-- 4 files changed, 49 insertions(+), 5 deletions(-) -- 2.44.0
[PATCH v2 3/3] powerpc/fadump: pass additional parameters when fadump is active
Append the additional parameters passed/set in the dedicated parameter
area (RTAS_FADUMP_PARAM_AREA) to bootargs in fadump capture kernel.
Signed-off-by: Hari Bathini
---
arch/powerpc/include/asm/fadump.h | 2 ++
arch/powerpc/kernel/fadump.c | 35 +++
arch/powerpc/kernel/prom.c| 3 +++
3 files changed, 40 insertions(+)
diff --git a/arch/powerpc/include/asm/fadump.h
b/arch/powerpc/include/asm/fadump.h
index 526a6a647312..ef40c9b6972a 100644
--- a/arch/powerpc/include/asm/fadump.h
+++ b/arch/powerpc/include/asm/fadump.h
@@ -19,12 +19,14 @@ extern int is_fadump_active(void);
extern int should_fadump_crash(void);
extern void crash_fadump(struct pt_regs *, const char *);
extern void fadump_cleanup(void);
+extern void fadump_append_bootargs(void);
#else /* CONFIG_FA_DUMP */
static inline int is_fadump_active(void) { return 0; }
static inline int should_fadump_crash(void) { return 0; }
static inline void crash_fadump(struct pt_regs *regs, const char *str) { }
static inline void fadump_cleanup(void) { }
+static inline void fadump_append_bootargs(void) { }
#endif /* !CONFIG_FA_DUMP */
#if defined(CONFIG_FA_DUMP) || defined(CONFIG_PRESERVE_FA_DUMP)
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 6d35b09d6f3a..2276bacc4170 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -131,6 +131,41 @@ static int __init fadump_cma_init(void)
static int __init fadump_cma_init(void) { return 1; }
#endif /* CONFIG_CMA */
+/*
+ * Additional parameters meant for capture kernel are placed in a dedicated
area.
+ * If this is capture kernel boot, append these parameters to bootargs.
+ */
+void __init fadump_append_bootargs(void)
+{
+ char *append_args;
+ size_t len;
+
+ if (!fw_dump.dump_active || !fw_dump.param_area_supported ||
!fw_dump.param_area)
+ return;
+
+ if (fw_dump.param_area >= fw_dump.boot_mem_top) {
+ if (memblock_reserve(fw_dump.param_area, COMMAND_LINE_SIZE)) {
+ pr_warn("WARNING: Can't use additional parameters
area!\n");
+ fw_dump.param_area = 0;
+ return;
+ }
+ }
+
+ append_args = (char *)fw_dump.param_area;
+ len = strlen(boot_command_line);
+
+ /*
+* Too late to fail even if cmdline size exceeds. Truncate additional
parameters
+* to cmdline size and proceed anyway.
+*/
+ if (len + strlen(append_args) >= COMMAND_LINE_SIZE - 1)
+ pr_warn("WARNING: Appending parameters exceeds cmdline size.
Truncating!\n");
+
+ pr_debug("Cmdline: %s\n", boot_command_line);
+ snprintf(boot_command_line + len, COMMAND_LINE_SIZE - len, " %s",
append_args);
+ pr_info("Updated cmdline: %s\n", boot_command_line);
+}
+
/* Scan the Firmware Assisted dump configuration details. */
int __init early_init_dt_scan_fw_dump(unsigned long node, const char *uname,
int depth, void *data)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index eb140ea6b6ff..60819751e55e 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -813,6 +813,9 @@ void __init early_init_devtree(void *params)
*/
of_scan_flat_dt(early_init_dt_scan_chosen_ppc, boot_command_line);
+ /* Append additional parameters passed for fadump capture kernel */
+ fadump_append_bootargs();
+
/* Scan memory nodes and rebuild MEMBLOCKs */
early_init_dt_scan_root();
early_init_dt_scan_memory_ppc();
--
2.45.0
[PATCH v2 2/3] powerpc/fadump: setup additional parameters for dump capture kernel
For fadump case, passing additional parameters to dump capture kernel
helps in minimizing the memory footprint for it and also provides the
flexibility to disable components/modules, like hugepages, that are
hindering the boot process of the special dump capture environment.
Set up a dedicated parameter area to be passed to the capture kernel.
This area type is defined as RTAS_FADUMP_PARAM_AREA. Sysfs attribute
'/sys/kernel/fadump/bootargs_append' is exported to the userspace to
specify the additional parameters to be passed to the capture kernel
Signed-off-by: Hari Bathini
---
arch/powerpc/include/asm/fadump-internal.h | 3 +
arch/powerpc/kernel/fadump.c | 87
arch/powerpc/platforms/powernv/opal-fadump.c | 6 +-
arch/powerpc/platforms/pseries/rtas-fadump.c | 35 +++-
arch/powerpc/platforms/pseries/rtas-fadump.h | 11 ++-
5 files changed, 133 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/include/asm/fadump-internal.h
b/arch/powerpc/include/asm/fadump-internal.h
index 35787fa1ac60..e83869a4eb6a 100644
--- a/arch/powerpc/include/asm/fadump-internal.h
+++ b/arch/powerpc/include/asm/fadump-internal.h
@@ -124,6 +124,8 @@ struct fw_dump {
unsigned long cpu_notes_buf_vaddr;
unsigned long cpu_notes_buf_size;
+ unsigned long param_area;
+
/*
* Maximum size supported by firmware to copy from source to
* destination address per entry.
@@ -138,6 +140,7 @@ struct fw_dump {
unsigned long dump_active:1;
unsigned long dump_registered:1;
unsigned long nocma:1;
+ unsigned long param_area_supported:1;
struct fadump_ops *ops;
};
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index fe6be00451b9..6d35b09d6f3a 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -1431,6 +1431,43 @@ static ssize_t registered_show(struct kobject *kobj,
return sprintf(buf, "%d\n", fw_dump.dump_registered);
}
+static ssize_t bootargs_append_show(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%s\n", (char *)__va(fw_dump.param_area));
+}
+
+static ssize_t bootargs_append_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buf, size_t count)
+{
+ char *params;
+
+ if (!fw_dump.fadump_enabled || fw_dump.dump_active)
+ return -EPERM;
+
+ if (count >= COMMAND_LINE_SIZE)
+ return -EINVAL;
+
+ /*
+* Fail here instead of handling this scenario with
+* some silly workaround in capture kernel.
+*/
+ if (saved_command_line_len + count >= COMMAND_LINE_SIZE) {
+ pr_err("Appending parameters exceeds cmdline size!\n");
+ return -ENOSPC;
+ }
+
+ params = __va(fw_dump.param_area);
+ strscpy_pad(params, buf, COMMAND_LINE_SIZE);
+ /* Remove newline character at the end. */
+ if (params[count-1] == '\n')
+ params[count-1] = '\0';
+
+ return count;
+}
+
static ssize_t registered_store(struct kobject *kobj,
struct kobj_attribute *attr,
const char *buf, size_t count)
@@ -1490,6 +1527,7 @@ static struct kobj_attribute enable_attr =
__ATTR_RO(enabled);
static struct kobj_attribute register_attr = __ATTR_RW(registered);
static struct kobj_attribute mem_reserved_attr = __ATTR_RO(mem_reserved);
static struct kobj_attribute hotplug_ready_attr = __ATTR_RO(hotplug_ready);
+static struct kobj_attribute bootargs_append_attr = __ATTR_RW(bootargs_append);
static struct attribute *fadump_attrs[] = {
_attr.attr,
@@ -1663,6 +1701,54 @@ static void __init fadump_process(void)
fadump_invalidate_release_mem();
}
+/*
+ * Reserve memory to store additional parameters to be passed
+ * for fadump/capture kernel.
+ */
+static void fadump_setup_param_area(void)
+{
+ phys_addr_t range_start, range_end;
+
+ if (!fw_dump.param_area_supported || fw_dump.dump_active)
+ return;
+
+ /* This memory can't be used by PFW or bootloader as it is shared
across kernels */
+ if (radix_enabled()) {
+ /*
+* Anywhere in the upper half should be good enough as all
memory
+* is accessible in real mode.
+*/
+ range_start = memblock_end_of_DRAM() / 2;
+ range_end = memblock_end_of_DRAM();
+ } else {
+ /*
+* Passing additional parameters is supported for hash MMU only
+* if the first memory block size is 768MB or higher.
+*/
+ if (ppc64_rma_size < 0x3000)
+ return;
+
+ /*
+*
[PATCH v2 1/3] powerpc/pseries/fadump: add support for multiple boot memory regions
Currently, fadump on pseries assumes a single boot memory region even
though f/w supports more than one boot memory region. Add support for
more boot memory regions to make the implementation flexible for any
enhancements that introduce other region types. For this, rtas memory
structure for fadump is updated to have multiple boot memory regions
instead of just one. Additionally, methods responsible for creating
the fadump memory structure during both the first and second kernel
boot have been modified to take these multiple boot memory regions
into account. Also, a new callback has been added to the fadump_ops
structure to get the maximum boot memory regions supported by the
platform.
Signed-off-by: Sourabh Jain
Signed-off-by: Hari Bathini
---
arch/powerpc/include/asm/fadump-internal.h | 2 +-
arch/powerpc/kernel/fadump.c | 27 +-
arch/powerpc/platforms/powernv/opal-fadump.c | 7 +
arch/powerpc/platforms/pseries/rtas-fadump.c | 255 +--
arch/powerpc/platforms/pseries/rtas-fadump.h | 26 +-
5 files changed, 197 insertions(+), 120 deletions(-)
diff --git a/arch/powerpc/include/asm/fadump-internal.h
b/arch/powerpc/include/asm/fadump-internal.h
index 5d706a7acc8a..35787fa1ac60 100644
--- a/arch/powerpc/include/asm/fadump-internal.h
+++ b/arch/powerpc/include/asm/fadump-internal.h
@@ -156,6 +156,7 @@ struct fadump_ops {
struct seq_file *m);
void(*fadump_trigger)(struct fadump_crash_info_header *fdh,
const char *msg);
+ int (*fadump_max_boot_mem_rgns)(void);
};
/* Helper functions */
@@ -163,7 +164,6 @@ s32 __init fadump_setup_cpu_notes_buf(u32 num_cpus);
void fadump_free_cpu_notes_buf(void);
u32 *__init fadump_regs_to_elf_notes(u32 *buf, struct pt_regs *regs);
void __init fadump_update_elfcore_header(char *bufp);
-bool is_fadump_boot_mem_contiguous(void);
bool is_fadump_reserved_mem_contiguous(void);
#else /* !CONFIG_PRESERVE_FA_DUMP */
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 0b849563393e..fe6be00451b9 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -220,28 +220,6 @@ static bool is_fadump_mem_area_contiguous(u64 d_start, u64
d_end)
return ret;
}
-/*
- * Returns true, if there are no holes in boot memory area,
- * false otherwise.
- */
-bool is_fadump_boot_mem_contiguous(void)
-{
- unsigned long d_start, d_end;
- bool ret = false;
- int i;
-
- for (i = 0; i < fw_dump.boot_mem_regs_cnt; i++) {
- d_start = fw_dump.boot_mem_addr[i];
- d_end = d_start + fw_dump.boot_mem_sz[i];
-
- ret = is_fadump_mem_area_contiguous(d_start, d_end);
- if (!ret)
- break;
- }
-
- return ret;
-}
-
/*
* Returns true, if there are no holes in reserved memory area,
* false otherwise.
@@ -381,10 +359,11 @@ static unsigned long __init get_fadump_area_size(void)
static int __init add_boot_mem_region(unsigned long rstart,
unsigned long rsize)
{
+ int max_boot_mem_rgns = fw_dump.ops->fadump_max_boot_mem_rgns();
int i = fw_dump.boot_mem_regs_cnt++;
- if (fw_dump.boot_mem_regs_cnt > FADUMP_MAX_MEM_REGS) {
- fw_dump.boot_mem_regs_cnt = FADUMP_MAX_MEM_REGS;
+ if (fw_dump.boot_mem_regs_cnt > max_boot_mem_rgns) {
+ fw_dump.boot_mem_regs_cnt = max_boot_mem_rgns;
return 0;
}
diff --git a/arch/powerpc/platforms/powernv/opal-fadump.c
b/arch/powerpc/platforms/powernv/opal-fadump.c
index 767a6b19e42a..5a88d7efb48a 100644
--- a/arch/powerpc/platforms/powernv/opal-fadump.c
+++ b/arch/powerpc/platforms/powernv/opal-fadump.c
@@ -599,6 +599,12 @@ static void opal_fadump_trigger(struct
fadump_crash_info_header *fdh,
pr_emerg("No backend support for MPIPL!\n");
}
+/* FADUMP_MAX_MEM_REGS or lower */
+static int opal_fadump_max_boot_mem_rgns(void)
+{
+ return FADUMP_MAX_MEM_REGS;
+}
+
static struct fadump_ops opal_fadump_ops = {
.fadump_init_mem_struct = opal_fadump_init_mem_struct,
.fadump_get_metadata_size = opal_fadump_get_metadata_size,
@@ -611,6 +617,7 @@ static struct fadump_ops opal_fadump_ops = {
.fadump_process = opal_fadump_process,
.fadump_region_show = opal_fadump_region_show,
.fadump_trigger = opal_fadump_trigger,
+ .fadump_max_boot_mem_rgns = opal_fadump_max_boot_mem_rgns,
};
void __init opal_fadump_dt_scan(struct fw_dump *fadump_conf, u64 node)
diff --git a/arch/powerpc/platforms/pseries/rtas-fadump.c
b/arch/powerpc/platforms/pseries/rtas-fadump.c
index 214f37788b2d..4db78b2bb2a8 100644
--- a/arch/powerpc/platforms/pseries/rtas-fadump.c
+++ b/arch/powerpc/platforms/pseries/rtas-fadump.c
@@ -29,9 +29,6 @@ static const struct
[PATCH v2 0/3] powerpc/fadump: pass additional args to dump capture kernel
While fadump is a more reliable alternative to kdump dump capturing method, it doesn't support passing additional parameters. Having such support is desirable for two major reasons: 1. It helps minimize the memory consumption of fadump dump capture kernel by disabling features that consume considerable amount of memory but have little significance for dump capture environment (eg. numa, cma, cgroup, etc.) 2. It helps disable such features/components in dump capture kernel that are unstable and/or are being debugged. This patch series is a follow-up to [1]. Adds support for passing additional parameters to fadump capture kernel to make it more desirable. For this, a dedicated area is passed between production kernel and capture kerenl to pass these additional parameters. This support is enabled only on pseries as of now. The dedicated area is referred to as RTAS_FADUMP_PARAM_AREA. In radix MMU mode, this dedicated area can be anywhere but in case of hash MMU, it can only be in the first memory block to be accessible during early boot. Enabling this feature support in both radix and hash MMU modes but in hash MMU only when RMA size is 768MB or more to avoid complex memory real estate with FW components. The first patch adds support for multiple boot memory regions to make addition of any new region types simpler. The second patch sets up the parameter (dedicated) area to be passed to the capture kernel. /sys/kernel/fadump/bootargs_append is exported to the userspace to specify the additional parameters to be passed to the capture kernel. The last patch appends the parameters to bootargs during capture kernel boot. Changes in v2: * RFC tag removed. * Moved variable declaration out of switch case. * Zero'ed the parameter area while setting up. * Reserving the parameter area only when needed. [1] https://lore.kernel.org/linuxppc-dev/20231205201835.388030-1-hbath...@linux.ibm.com/ Hari Bathini (3): powerpc/pseries/fadump: add support for multiple boot memory regions powerpc/fadump: setup additional parameters for dump capture kernel powerpc/fadump: pass additional parameters when fadump is active arch/powerpc/include/asm/fadump-internal.h | 5 +- arch/powerpc/include/asm/fadump.h| 2 + arch/powerpc/kernel/fadump.c | 149 -- arch/powerpc/kernel/prom.c | 3 + arch/powerpc/platforms/powernv/opal-fadump.c | 13 +- arch/powerpc/platforms/pseries/rtas-fadump.c | 290 +-- arch/powerpc/platforms/pseries/rtas-fadump.h | 29 +- 7 files changed, 366 insertions(+), 125 deletions(-) -- 2.45.0
Re: [PATCH v15 00/16] Add audio support in v4l2 framework
On 09. 05. 24 12:44, Shengjiu Wang wrote: mem2mem is just like the decoder in the compress pipeline. which is one of the components in the pipeline. I was thinking of loopback with endpoints using compress streams, without physical endpoint, something like: compress playback (to feed data from userspace) -> DSP (processing) -> compress capture (send data back to userspace) Unless I'm missing something, you should be able to process data as fast as you can feed it and consume it in such case. Actually in the beginning I tried this, but it did not work well. ALSA needs time control for playback and capture, playback and capture needs to synchronize. Usually the playback and capture pipeline is independent in ALSA design, but in this case, the playback and capture should synchronize, they are not independent. The core compress API core no strict timing constraints. You can eventually0 have two half-duplex compress devices, if you like to have really independent mechanism. If something is missing in API, you can extend this API (like to inform the user space that it's a producer/consumer processing without any relation to the real time). I like this idea. Jaroslav -- Jaroslav Kysela Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
Re: [PATCH v15 00/16] Add audio support in v4l2 framework
On Thu, May 9, 2024 at 6:28 PM Amadeusz Sławiński wrote: > > On 5/9/2024 12:12 PM, Shengjiu Wang wrote: > > On Thu, May 9, 2024 at 5:50 PM Amadeusz Sławiński > > wrote: > >> > >> On 5/9/2024 11:36 AM, Shengjiu Wang wrote: > >>> On Wed, May 8, 2024 at 4:14 PM Amadeusz Sławiński > >>> wrote: > > On 5/8/2024 10:00 AM, Hans Verkuil wrote: > > On 06/05/2024 10:49, Shengjiu Wang wrote: > >> On Fri, May 3, 2024 at 4:42 PM Mauro Carvalho Chehab > >> wrote: > >>> > >>> Em Fri, 3 May 2024 10:47:19 +0900 > >>> Mark Brown escreveu: > >>> > On Thu, May 02, 2024 at 10:26:43AM +0100, Mauro Carvalho Chehab > wrote: > > Mauro Carvalho Chehab escreveu: > > >> There are still time control associated with it, as audio and video > >> needs to be in sync. This is done by controlling the buffers size > >> and could be fine-tuned by checking when the buffer transfer is > >> done. > > ... > > > Just complementing: on media, we do this per video buffer (or > > per half video buffer). A typical use case on cameras is to have > > buffers transferred 30 times per second, if the video was streamed > > at 30 frames per second. > > IIRC some big use case for this hardware was transcoding so there > was a > desire to just go at whatever rate the hardware could support as > there > is no interactive user consuming the output as it is generated. > >>> > >>> Indeed, codecs could be used to just do transcoding, but I would > >>> expect it to be a border use case. See, as the chipsets implementing > >>> codecs are typically the ones used on mobiles, I would expect that > >>> the major use cases to be to watch audio and video and to participate > >>> on audio/video conferences. > >>> > >>> Going further, the codec API may end supporting not only transcoding > >>> (which is something that CPU can usually handle without too much > >>> processing) but also audio processing that may require more > >>> complex algorithms - even deep learning ones - like background noise > >>> removal, echo detection/removal, volume auto-gain, audio enhancement > >>> and such. > >>> > >>> On other words, the typical use cases will either have input > >>> or output being a physical hardware (microphone or speaker). > >>> > >> > >> All, thanks for spending time to discuss, it seems we go back to > >> the start point of this topic again. > >> > >> Our main request is that there is a hardware sample rate converter > >> on the chip, so users can use it in user space as a component like > >> software sample rate converter. It mostly may run as a gstreamer > >> plugin. > >> so it is a memory to memory component. > >> > >> I didn't find such API in ALSA for such purpose, the best option for > >> this > >> in the kernel is the V4L2 memory to memory framework I found. > >> As Hans said it is well designed for memory to memory. > >> > >> And I think audio is one of 'media'. As I can see that part of Radio > >> function is in ALSA, part of Radio function is in V4L2. part of HDMI > >> function is in DRM, part of HDMI function is in ALSA... > >> So using V4L2 for audio is not new from this point of view. > >> > >> Even now I still think V4L2 is the best option, but it looks like there > >> are a lot of rejects. If develop a new ALSA-mem2mem, it is also > >> a duplication of code (bigger duplication that just add audio support > >> in V4L2 I think). > > > > After reading this thread I still believe that the mem2mem framework is > > a reasonable option, unless someone can come up with a method that is > > easy to implement in the alsa subsystem. From what I can tell from this > > discussion no such method exists. > > > > Hi, > > my main question would be how is mem2mem use case different from > loopback exposing playback and capture frontends in user space with DSP > (or other piece of HW) in the middle? > > >>> I think loopback has a timing control, user need to feed data to > >>> playback at a > >>> fixed time and get data from capture at a fixed time. Otherwise there > >>> is xrun in > >>> playback and capture. > >>> > >>> mem2mem case: there is no such timing control, user feeds data to it > >>> then it generates output, if user doesn't feed data, there is no xrun. > >>> but mem2mem is just one of the components in the playback or capture > >>> pipeline, overall there is time control for whole pipeline, > >>> > >> > >> Have you looked at compress streams? If I remember correctly they are > >> not tied to time due to the fact that they can pass data in arbitrary > >> formats? > >> > >> From: > >>
Re: [PATCH v15 00/16] Add audio support in v4l2 framework
On 5/9/2024 12:12 PM, Shengjiu Wang wrote: On Thu, May 9, 2024 at 5:50 PM Amadeusz Sławiński wrote: On 5/9/2024 11:36 AM, Shengjiu Wang wrote: On Wed, May 8, 2024 at 4:14 PM Amadeusz Sławiński wrote: On 5/8/2024 10:00 AM, Hans Verkuil wrote: On 06/05/2024 10:49, Shengjiu Wang wrote: On Fri, May 3, 2024 at 4:42 PM Mauro Carvalho Chehab wrote: Em Fri, 3 May 2024 10:47:19 +0900 Mark Brown escreveu: On Thu, May 02, 2024 at 10:26:43AM +0100, Mauro Carvalho Chehab wrote: Mauro Carvalho Chehab escreveu: There are still time control associated with it, as audio and video needs to be in sync. This is done by controlling the buffers size and could be fine-tuned by checking when the buffer transfer is done. ... Just complementing: on media, we do this per video buffer (or per half video buffer). A typical use case on cameras is to have buffers transferred 30 times per second, if the video was streamed at 30 frames per second. IIRC some big use case for this hardware was transcoding so there was a desire to just go at whatever rate the hardware could support as there is no interactive user consuming the output as it is generated. Indeed, codecs could be used to just do transcoding, but I would expect it to be a border use case. See, as the chipsets implementing codecs are typically the ones used on mobiles, I would expect that the major use cases to be to watch audio and video and to participate on audio/video conferences. Going further, the codec API may end supporting not only transcoding (which is something that CPU can usually handle without too much processing) but also audio processing that may require more complex algorithms - even deep learning ones - like background noise removal, echo detection/removal, volume auto-gain, audio enhancement and such. On other words, the typical use cases will either have input or output being a physical hardware (microphone or speaker). All, thanks for spending time to discuss, it seems we go back to the start point of this topic again. Our main request is that there is a hardware sample rate converter on the chip, so users can use it in user space as a component like software sample rate converter. It mostly may run as a gstreamer plugin. so it is a memory to memory component. I didn't find such API in ALSA for such purpose, the best option for this in the kernel is the V4L2 memory to memory framework I found. As Hans said it is well designed for memory to memory. And I think audio is one of 'media'. As I can see that part of Radio function is in ALSA, part of Radio function is in V4L2. part of HDMI function is in DRM, part of HDMI function is in ALSA... So using V4L2 for audio is not new from this point of view. Even now I still think V4L2 is the best option, but it looks like there are a lot of rejects. If develop a new ALSA-mem2mem, it is also a duplication of code (bigger duplication that just add audio support in V4L2 I think). After reading this thread I still believe that the mem2mem framework is a reasonable option, unless someone can come up with a method that is easy to implement in the alsa subsystem. From what I can tell from this discussion no such method exists. Hi, my main question would be how is mem2mem use case different from loopback exposing playback and capture frontends in user space with DSP (or other piece of HW) in the middle? I think loopback has a timing control, user need to feed data to playback at a fixed time and get data from capture at a fixed time. Otherwise there is xrun in playback and capture. mem2mem case: there is no such timing control, user feeds data to it then it generates output, if user doesn't feed data, there is no xrun. but mem2mem is just one of the components in the playback or capture pipeline, overall there is time control for whole pipeline, Have you looked at compress streams? If I remember correctly they are not tied to time due to the fact that they can pass data in arbitrary formats? From: https://docs.kernel.org/sound/designs/compress-offload.html "No notion of underrun/overrun. Since the bytes written are compressed in nature and data written/read doesn’t translate directly to rendered output in time, this does not deal with underrun/overrun and maybe dealt in user-library" I checked the compress stream. mem2mem case is different with compress-offload case compress-offload case is a full pipeline, the user sends a compress stream to it, then DSP decodes it and renders it to the speaker in real time. mem2mem is just like the decoder in the compress pipeline. which is one of the components in the pipeline. I was thinking of loopback with endpoints using compress streams, without physical endpoint, something like: compress playback (to feed data from userspace) -> DSP (processing) -> compress capture (send data back to userspace) Unless I'm missing something, you should be able to process data as fast as you can feed it and consume it in such case.
Re: [PATCH v15 00/16] Add audio support in v4l2 framework
On Thu, May 9, 2024 at 5:50 PM Amadeusz Sławiński wrote: > > On 5/9/2024 11:36 AM, Shengjiu Wang wrote: > > On Wed, May 8, 2024 at 4:14 PM Amadeusz Sławiński > > wrote: > >> > >> On 5/8/2024 10:00 AM, Hans Verkuil wrote: > >>> On 06/05/2024 10:49, Shengjiu Wang wrote: > On Fri, May 3, 2024 at 4:42 PM Mauro Carvalho Chehab > wrote: > > > > Em Fri, 3 May 2024 10:47:19 +0900 > > Mark Brown escreveu: > > > >> On Thu, May 02, 2024 at 10:26:43AM +0100, Mauro Carvalho Chehab wrote: > >>> Mauro Carvalho Chehab escreveu: > >> > There are still time control associated with it, as audio and video > needs to be in sync. This is done by controlling the buffers size > and could be fine-tuned by checking when the buffer transfer is done. > >> > >> ... > >> > >>> Just complementing: on media, we do this per video buffer (or > >>> per half video buffer). A typical use case on cameras is to have > >>> buffers transferred 30 times per second, if the video was streamed > >>> at 30 frames per second. > >> > >> IIRC some big use case for this hardware was transcoding so there was a > >> desire to just go at whatever rate the hardware could support as there > >> is no interactive user consuming the output as it is generated. > > > > Indeed, codecs could be used to just do transcoding, but I would > > expect it to be a border use case. See, as the chipsets implementing > > codecs are typically the ones used on mobiles, I would expect that > > the major use cases to be to watch audio and video and to participate > > on audio/video conferences. > > > > Going further, the codec API may end supporting not only transcoding > > (which is something that CPU can usually handle without too much > > processing) but also audio processing that may require more > > complex algorithms - even deep learning ones - like background noise > > removal, echo detection/removal, volume auto-gain, audio enhancement > > and such. > > > > On other words, the typical use cases will either have input > > or output being a physical hardware (microphone or speaker). > > > > All, thanks for spending time to discuss, it seems we go back to > the start point of this topic again. > > Our main request is that there is a hardware sample rate converter > on the chip, so users can use it in user space as a component like > software sample rate converter. It mostly may run as a gstreamer plugin. > so it is a memory to memory component. > > I didn't find such API in ALSA for such purpose, the best option for this > in the kernel is the V4L2 memory to memory framework I found. > As Hans said it is well designed for memory to memory. > > And I think audio is one of 'media'. As I can see that part of Radio > function is in ALSA, part of Radio function is in V4L2. part of HDMI > function is in DRM, part of HDMI function is in ALSA... > So using V4L2 for audio is not new from this point of view. > > Even now I still think V4L2 is the best option, but it looks like there > are a lot of rejects. If develop a new ALSA-mem2mem, it is also > a duplication of code (bigger duplication that just add audio support > in V4L2 I think). > >>> > >>> After reading this thread I still believe that the mem2mem framework is > >>> a reasonable option, unless someone can come up with a method that is > >>> easy to implement in the alsa subsystem. From what I can tell from this > >>> discussion no such method exists. > >>> > >> > >> Hi, > >> > >> my main question would be how is mem2mem use case different from > >> loopback exposing playback and capture frontends in user space with DSP > >> (or other piece of HW) in the middle? > >> > > I think loopback has a timing control, user need to feed data to playback > > at a > > fixed time and get data from capture at a fixed time. Otherwise there > > is xrun in > > playback and capture. > > > > mem2mem case: there is no such timing control, user feeds data to it > > then it generates output, if user doesn't feed data, there is no xrun. > > but mem2mem is just one of the components in the playback or capture > > pipeline, overall there is time control for whole pipeline, > > > > Have you looked at compress streams? If I remember correctly they are > not tied to time due to the fact that they can pass data in arbitrary > formats? > > From: > https://docs.kernel.org/sound/designs/compress-offload.html > > "No notion of underrun/overrun. Since the bytes written are compressed > in nature and data written/read doesn’t translate directly to rendered > output in time, this does not deal with underrun/overrun and maybe dealt > in user-library" I checked the compress stream. mem2mem case is different with compress-offload case compress-offload case is a full
Re: [PATCH v15 00/16] Add audio support in v4l2 framework
On 5/9/2024 11:36 AM, Shengjiu Wang wrote: On Wed, May 8, 2024 at 4:14 PM Amadeusz Sławiński wrote: On 5/8/2024 10:00 AM, Hans Verkuil wrote: On 06/05/2024 10:49, Shengjiu Wang wrote: On Fri, May 3, 2024 at 4:42 PM Mauro Carvalho Chehab wrote: Em Fri, 3 May 2024 10:47:19 +0900 Mark Brown escreveu: On Thu, May 02, 2024 at 10:26:43AM +0100, Mauro Carvalho Chehab wrote: Mauro Carvalho Chehab escreveu: There are still time control associated with it, as audio and video needs to be in sync. This is done by controlling the buffers size and could be fine-tuned by checking when the buffer transfer is done. ... Just complementing: on media, we do this per video buffer (or per half video buffer). A typical use case on cameras is to have buffers transferred 30 times per second, if the video was streamed at 30 frames per second. IIRC some big use case for this hardware was transcoding so there was a desire to just go at whatever rate the hardware could support as there is no interactive user consuming the output as it is generated. Indeed, codecs could be used to just do transcoding, but I would expect it to be a border use case. See, as the chipsets implementing codecs are typically the ones used on mobiles, I would expect that the major use cases to be to watch audio and video and to participate on audio/video conferences. Going further, the codec API may end supporting not only transcoding (which is something that CPU can usually handle without too much processing) but also audio processing that may require more complex algorithms - even deep learning ones - like background noise removal, echo detection/removal, volume auto-gain, audio enhancement and such. On other words, the typical use cases will either have input or output being a physical hardware (microphone or speaker). All, thanks for spending time to discuss, it seems we go back to the start point of this topic again. Our main request is that there is a hardware sample rate converter on the chip, so users can use it in user space as a component like software sample rate converter. It mostly may run as a gstreamer plugin. so it is a memory to memory component. I didn't find such API in ALSA for such purpose, the best option for this in the kernel is the V4L2 memory to memory framework I found. As Hans said it is well designed for memory to memory. And I think audio is one of 'media'. As I can see that part of Radio function is in ALSA, part of Radio function is in V4L2. part of HDMI function is in DRM, part of HDMI function is in ALSA... So using V4L2 for audio is not new from this point of view. Even now I still think V4L2 is the best option, but it looks like there are a lot of rejects. If develop a new ALSA-mem2mem, it is also a duplication of code (bigger duplication that just add audio support in V4L2 I think). After reading this thread I still believe that the mem2mem framework is a reasonable option, unless someone can come up with a method that is easy to implement in the alsa subsystem. From what I can tell from this discussion no such method exists. Hi, my main question would be how is mem2mem use case different from loopback exposing playback and capture frontends in user space with DSP (or other piece of HW) in the middle? I think loopback has a timing control, user need to feed data to playback at a fixed time and get data from capture at a fixed time. Otherwise there is xrun in playback and capture. mem2mem case: there is no such timing control, user feeds data to it then it generates output, if user doesn't feed data, there is no xrun. but mem2mem is just one of the components in the playback or capture pipeline, overall there is time control for whole pipeline, Have you looked at compress streams? If I remember correctly they are not tied to time due to the fact that they can pass data in arbitrary formats? From: https://docs.kernel.org/sound/designs/compress-offload.html "No notion of underrun/overrun. Since the bytes written are compressed in nature and data written/read doesn’t translate directly to rendered output in time, this does not deal with underrun/overrun and maybe dealt in user-library" Amadeusz
Re: [PATCH v15 00/16] Add audio support in v4l2 framework
On Wed, May 8, 2024 at 4:14 PM Amadeusz Sławiński wrote: > > On 5/8/2024 10:00 AM, Hans Verkuil wrote: > > On 06/05/2024 10:49, Shengjiu Wang wrote: > >> On Fri, May 3, 2024 at 4:42 PM Mauro Carvalho Chehab > >> wrote: > >>> > >>> Em Fri, 3 May 2024 10:47:19 +0900 > >>> Mark Brown escreveu: > >>> > On Thu, May 02, 2024 at 10:26:43AM +0100, Mauro Carvalho Chehab wrote: > > Mauro Carvalho Chehab escreveu: > > >> There are still time control associated with it, as audio and video > >> needs to be in sync. This is done by controlling the buffers size > >> and could be fine-tuned by checking when the buffer transfer is done. > > ... > > > Just complementing: on media, we do this per video buffer (or > > per half video buffer). A typical use case on cameras is to have > > buffers transferred 30 times per second, if the video was streamed > > at 30 frames per second. > > IIRC some big use case for this hardware was transcoding so there was a > desire to just go at whatever rate the hardware could support as there > is no interactive user consuming the output as it is generated. > >>> > >>> Indeed, codecs could be used to just do transcoding, but I would > >>> expect it to be a border use case. See, as the chipsets implementing > >>> codecs are typically the ones used on mobiles, I would expect that > >>> the major use cases to be to watch audio and video and to participate > >>> on audio/video conferences. > >>> > >>> Going further, the codec API may end supporting not only transcoding > >>> (which is something that CPU can usually handle without too much > >>> processing) but also audio processing that may require more > >>> complex algorithms - even deep learning ones - like background noise > >>> removal, echo detection/removal, volume auto-gain, audio enhancement > >>> and such. > >>> > >>> On other words, the typical use cases will either have input > >>> or output being a physical hardware (microphone or speaker). > >>> > >> > >> All, thanks for spending time to discuss, it seems we go back to > >> the start point of this topic again. > >> > >> Our main request is that there is a hardware sample rate converter > >> on the chip, so users can use it in user space as a component like > >> software sample rate converter. It mostly may run as a gstreamer plugin. > >> so it is a memory to memory component. > >> > >> I didn't find such API in ALSA for such purpose, the best option for this > >> in the kernel is the V4L2 memory to memory framework I found. > >> As Hans said it is well designed for memory to memory. > >> > >> And I think audio is one of 'media'. As I can see that part of Radio > >> function is in ALSA, part of Radio function is in V4L2. part of HDMI > >> function is in DRM, part of HDMI function is in ALSA... > >> So using V4L2 for audio is not new from this point of view. > >> > >> Even now I still think V4L2 is the best option, but it looks like there > >> are a lot of rejects. If develop a new ALSA-mem2mem, it is also > >> a duplication of code (bigger duplication that just add audio support > >> in V4L2 I think). > > > > After reading this thread I still believe that the mem2mem framework is > > a reasonable option, unless someone can come up with a method that is > > easy to implement in the alsa subsystem. From what I can tell from this > > discussion no such method exists. > > > > Hi, > > my main question would be how is mem2mem use case different from > loopback exposing playback and capture frontends in user space with DSP > (or other piece of HW) in the middle? > I think loopback has a timing control, user need to feed data to playback at a fixed time and get data from capture at a fixed time. Otherwise there is xrun in playback and capture. mem2mem case: there is no such timing control, user feeds data to it then it generates output, if user doesn't feed data, there is no xrun. but mem2mem is just one of the components in the playback or capture pipeline, overall there is time control for whole pipeline, Best regards Shengjiu Wang > Amadeusz >
[PATCH v4 3/3] PCI/AER: Clear UNCOR_STATUS bits that might be ANFE
When processing an ANFE, ideally both correctable error(CE) status and
uncorrectable error(UE) status should be cleared. However, there is no
way to fully identify the UE associated with ANFE. Even worse, Non-Fatal
Error(NFE) may set the same UE status bit as ANFE. Treating an ANFE as
NFE will bring some issues, i.e., breaking softwore probing; treating
NFE as ANFE will make us ignoring some UEs which need active recover
operation. To avoid clearing UEs that are not ANFE by accident, the
most conservative route is taken here: If any of the NFE Detected bits
is set in Device Status, do not touch UE status, they should be cleared
later by the UE handler. Otherwise, a specific set of UEs that may be
raised as ANFE according to the PCIe specification will be cleared if
their corresponding severity is Non-Fatal.
For instance, previously when kernel receives an ANFE with Poisoned TLP
in OS native AER mode, only status of CE will be reported and cleared:
AER: Correctable error message received from :b7:02.0
PCIe Bus Error: severity=Correctable, type=Transaction Layer, (Receiver ID)
device [8086:0db0] error status/mask=2000/
[13] NonFatalErr
If the kernel receives a Malformed TLP after that, two UEs will be
reported, which is unexpected. Malformed TLP Header is lost since
the previous ANFE gated the TLP header logs:
PCIe Bus Error: severity="Uncorrectable (Fatal), type=Transaction Layer,
(Receiver ID)
device [8086:0db0] error status/mask=00041000/00180020
[12] TLP(First)
[18] MalfTLP
Now, for the same scenario, both CE status and related UE status will be
reported and cleared after ANFE:
AER: Correctable error message received from :b7:02.0
PCIe Bus Error: severity=Correctable, type=Transaction Layer, (Receiver ID)
device [8086:0db0] error status/mask=2000/
[13] NonFatalErr
Uncorrectable errors that may cause Advisory Non-Fatal:
[18] TLP
Tested-by: Yudong Wang
Co-developed-by: "Wang, Qingshun"
Signed-off-by: "Wang, Qingshun"
Signed-off-by: Zhenzhong Duan
---
drivers/pci/pcie/aer.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index ed435f09ac27..6a6a3a40569a 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -1115,9 +1115,14 @@ static void pci_aer_handle_error(struct pci_dev *dev,
struct aer_err_info *info)
* Correctable error does not need software intervention.
* No need to go through error recovery process.
*/
- if (aer)
+ if (aer) {
pci_write_config_dword(dev, aer + PCI_ERR_COR_STATUS,
info->status);
+ if (info->anfe_status)
+ pci_write_config_dword(dev,
+ aer +
PCI_ERR_UNCOR_STATUS,
+ info->anfe_status);
+ }
if (pcie_aer_is_native(dev)) {
struct pci_driver *pdrv = dev->driver;
--
2.34.1
[PATCH v4 2/3] PCI/AER: Print UNCOR_STATUS bits that might be ANFE
When an Advisory Non-Fatal error(ANFE) triggers, both correctable error(CE)
status and ANFE related uncorrectable error(UE) status will be printed:
AER: Correctable error message received from :b7:02.0
PCIe Bus Error: severity=Correctable, type=Transaction Layer, (Receiver ID)
device [8086:0db0] error status/mask=2000/
[13] NonFatalErr
Uncorrectable errors that may cause Advisory Non-Fatal:
[18] TLP
Tested-by: Yudong Wang
Co-developed-by: "Wang, Qingshun"
Signed-off-by: "Wang, Qingshun"
Signed-off-by: Zhenzhong Duan
---
drivers/pci/pcie/aer.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index f2839b51321a..ed435f09ac27 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -681,6 +681,7 @@ static void __aer_print_error(struct pci_dev *dev,
{
const char **strings;
unsigned long status = info->status & ~info->mask;
+ unsigned long anfe_status = info->anfe_status;
const char *level, *errmsg;
int i;
@@ -701,6 +702,20 @@ static void __aer_print_error(struct pci_dev *dev,
info->first_error == i ? " (First)" : "");
}
pci_dev_aer_stats_incr(dev, info);
+
+ if (!anfe_status)
+ return;
+
+ strings = aer_uncorrectable_error_string;
+ pci_printk(level, dev, "Uncorrectable errors that may cause Advisory
Non-Fatal:\n");
+
+ for_each_set_bit(i, _status, 32) {
+ errmsg = strings[i];
+ if (!errmsg)
+ errmsg = "Unknown Error Bit";
+
+ pci_printk(level, dev, " [%2d] %s\n", i, errmsg);
+ }
}
void aer_print_error(struct pci_dev *dev, struct aer_err_info *info)
--
2.34.1
[PATCH v4 1/3] PCI/AER: Store UNCOR_STATUS bits that might be ANFE in aer_err_info
In some cases the detector of a Non-Fatal Error(NFE) is not the most
appropriate agent to determine the type of the error. For example,
when software performs a configuration read from a non-existent
device or Function, completer will send an ERR_NONFATAL Message.
On some platforms, ERR_NONFATAL results in a System Error, which
breaks normal software probing.
Advisory Non-Fatal Error(ANFE) is a special case that can be used
in above scenario. It is predominantly determined by the role of the
detecting agent (Requester, Completer, or Receiver) and the specific
error. In such cases, an agent with AER signals the NFE (if enabled)
by sending an ERR_COR Message as an advisory to software, instead of
sending ERR_NONFATAL.
When processing an ANFE, ideally both correctable error(CE) status and
uncorrectable error(UE) status should be cleared. However, there is no
way to fully identify the UE associated with ANFE. Even worse, Non-Fatal
Error(NFE) may set the same UE status bit as ANFE. Treating an ANFE as
NFE will reproduce above mentioned issue, i.e., breaking softwore probing;
treating NFE as ANFE will make us ignoring some UEs which need active
recover operation. To avoid clearing UEs that are not ANFE by accident,
the most conservative route is taken here: If any of the NFE Detected
bits is set in Device Status, do not touch UE status, they should be
cleared later by the UE handler. Otherwise, a specific set of UEs that
may be raised as ANFE according to the PCIe specification will be cleared
if their corresponding severity is Non-Fatal.
To achieve above purpose, store UNCOR_STATUS bits that might be ANFE
in aer_err_info.anfe_status. So that those bits could be printed and
processed later.
Tested-by: Yudong Wang
Co-developed-by: "Wang, Qingshun"
Signed-off-by: "Wang, Qingshun"
Signed-off-by: Zhenzhong Duan
---
drivers/pci/pci.h | 1 +
drivers/pci/pcie/aer.c | 53 ++
2 files changed, 54 insertions(+)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 17fed1846847..3f9eb807f9fd 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -412,6 +412,7 @@ struct aer_err_info {
unsigned int status;/* COR/UNCOR Error Status */
unsigned int mask; /* COR/UNCOR Error Mask */
+ unsigned int anfe_status; /* UNCOR Error Status for ANFE */
struct pcie_tlp_log tlp;/* TLP Header */
};
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index ac6293c24976..f2839b51321a 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -107,6 +107,12 @@ struct aer_stats {
PCI_ERR_ROOT_MULTI_COR_RCV |\
PCI_ERR_ROOT_MULTI_UNCOR_RCV)
+#define AER_ERR_ANFE_UNC_MASK (PCI_ERR_UNC_POISON_TLP | \
+ PCI_ERR_UNC_COMP_TIME | \
+ PCI_ERR_UNC_COMP_ABORT |\
+ PCI_ERR_UNC_UNX_COMP | \
+ PCI_ERR_UNC_UNSUP)
+
static int pcie_aer_disable;
static pci_ers_result_t aer_root_reset(struct pci_dev *dev);
@@ -1196,6 +1202,49 @@ void aer_recover_queue(int domain, unsigned int bus,
unsigned int devfn,
EXPORT_SYMBOL_GPL(aer_recover_queue);
#endif
+static void anfe_get_uc_status(struct pci_dev *dev, struct aer_err_info *info)
+{
+ u32 uncor_mask, uncor_status, anfe_status;
+ u16 device_status;
+ int aer = dev->aer_cap;
+
+ pci_read_config_dword(dev, aer + PCI_ERR_UNCOR_STATUS, _status);
+ pci_read_config_dword(dev, aer + PCI_ERR_UNCOR_MASK, _mask);
+ /*
+* According to PCIe Base Specification Revision 6.1,
+* Section 6.2.3.2.4, if an UNCOR error is raised as
+* Advisory Non-Fatal error, it will match the following
+* conditions:
+* a. The severity of the error is Non-Fatal.
+* b. The error is one of the following:
+* 1. Poisoned TLP (Section 6.2.3.2.4.3)
+* 2. Completion Timeout (Section 6.2.3.2.4.4)
+* 3. Completer Abort(Section 6.2.3.2.4.1)
+* 4. Unexpected Completion (Section 6.2.3.2.4.5)
+* 5. Unsupported Request(Section 6.2.3.2.4.1)
+*/
+ anfe_status = uncor_status & ~uncor_mask & ~info->severity &
+ AER_ERR_ANFE_UNC_MASK;
+
+ if (pcie_capability_read_word(dev, PCI_EXP_DEVSTA, _status))
+ return;
+ /*
+* Take the most conservative route here. If there are Non-Fatal errors
+* detected, do not assume any bit in uncor_status is set by ANFE.
+*/
+ if (device_status & PCI_EXP_DEVSTA_NFED)
+ return;
+
+ /*
+* If there is another ANFE between reading uncor_status and clearing
+*
[PATCH v4 0/3] PCI/AER: Handle Advisory Non-Fatal error
Hi, This is a relay work of Qingshun's v2 [1], but changed to focus on ANFE processing as subject suggests and drops trace-event for now. I think it's a bit heavy to do extra IOes to get PCIe registers only for trace purpose and not see it a community request for now. According to PCIe Base Specification Revision 6.1, Sections 6.2.3.2.4 and 6.2.4.3, certain uncorrectable errors will signal ERR_COR instead of ERR_NONFATAL, logged as Advisory Non-Fatal Error(ANFE), and set bits in both Correctable Error(CE) Status register and Uncorrectable Error(UE) Status register. Currently, when handling AER events the kernel will only look at CE status or UE status, but never both. In the ANFE case, bits set in the UE status register will not be reported and cleared until the next FE/NFE arrives. For instance, previously, when the kernel receives an ANFE with Poisoned TLP in OS native AER mode, only the status of CE will be reported and cleared: AER: Correctable error message received from :b7:02.0 PCIe Bus Error: severity=Correctable, type=Transaction Layer, (Receiver ID) device [8086:0db0] error status/mask=2000/ [13] NonFatalErr If the kernel receives a Malformed TLP after that, two UEs will be reported, which is unexpected. The Malformed TLP Header is lost since the previous ANFE gated the TLP header logs: PCIe Bus Error: severity="Uncorrectable (Fatal), type=Transaction Layer, (Receiver ID) device [8086:0db0] error status/mask=00041000/00180020 [12] TLP(First) [18] MalfTLP To handle this case properly, calculate potential ANFE related status bits and save in aer_err_info. Use this information to determine the status bits that need to be cleared. Now, for the previous scenario, both CE status and related UE status will be reported and cleared after ANFE: AER: Correctable error message received from :b7:02.0 PCIe Bus Error: severity=Correctable, type=Transaction Layer, (Receiver ID) device [8086:0db0] error status/mask=2000/ [13] NonFatalErr Uncorrectable errors that may cause Advisory Non-Fatal: [18] TLP Note: checkpatch.pl will produce following warnings on PATCH2/3: WARNING: 'UE' may be misspelled - perhaps 'USE'? #22: uncorrectable error(UE) status should be cleared. However, there is no ...similar warnings omitted... This is a false-positive, so not fixed. WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?) #10: PCIe Bus Error: severity=Correctable, type=Transaction Layer, (Receiver ID) ...similar warnings omitted... For readability reasons, these warnings are not fixed. [1] https://lore.kernel.org/linux-pci/20240125062802.50819-1-qingshun.w...@linux.intel.com Thanks Qingshun, Zhenzhong Changelog: v4: - Fix a race in anfe_get_uc_status() (Jonathan) - Add a comment to explain side effect of processing ANFE as NFE (Jonathan) - Drop the check for PCI_EXP_DEVSTA_NFED v3: - Split ANFE print and processing to two patches (Bjorn) - Simplify ANFE handling, drop trace event - Polish comments and patch description - Add Tested-by v2: - Reference to the latest PCIe Specification in both commit messages and comments, as suggested by Bjorn Helgaas. - Describe the reason for storing additional information in aer_err_info in the commit message of PATCH 1, as suggested by Bjorn Helgaas. - Add more details of behavior changes in the commit message of PATCH 2, as suggested by Bjorn Helgaas. v3: https://lore.kernel.org/lkml/20240417061407.1491361-1-zhenzhong.d...@intel.com v2: https://lore.kernel.org/linux-pci/20240125062802.50819-1-qingshun.w...@linux.intel.com v1: https://lore.kernel.org/linux-pci/20240111073227.31488-1-qingshun.w...@linux.intel.com Zhenzhong Duan (3): PCI/AER: Store UNCOR_STATUS bits that might be ANFE in aer_err_info PCI/AER: Print UNCOR_STATUS bits that might be ANFE PCI/AER: Clear UNCOR_STATUS bits that might be ANFE drivers/pci/pci.h | 1 + drivers/pci/pcie/aer.c | 75 +- 2 files changed, 75 insertions(+), 1 deletion(-) -- 2.34.1
Re: [PATCH 1/2] powerpc/kexec_file: fix extra size calculation for kexec FDT
Hi Sourabh,
kernel test robot noticed the following build warnings:
[auto build test WARNING on next-20240508]
[cannot apply to powerpc/next powerpc/fixes linus/master v6.9-rc7 v6.9-rc6
v6.9-rc5 v6.9-rc7]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Sourabh-Jain/powerpc-kexec_file-fix-extra-size-calculation-for-kexec-FDT/20240508-211003
base: next-20240508
patch link:
https://lore.kernel.org/r/20240508130558.1939304-2-sourabhjain%40linux.ibm.com
patch subject: [PATCH 1/2] powerpc/kexec_file: fix extra size calculation for
kexec FDT
config: powerpc64-randconfig-002-20240509
(https://download.01.org/0day-ci/archive/20240509/202405091617.irrntyre-...@intel.com/config)
compiler: powerpc64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240509/202405091617.irrntyre-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202405091617.irrntyre-...@intel.com/
All warnings (new ones prefixed by >>):
>> arch/powerpc/kexec/file_load_64.c:852: warning: Function parameter or struct
>> member 'rmem' not described in 'kexec_extra_fdt_size_ppc64'
vim +852 arch/powerpc/kexec/file_load_64.c
2377c92e37fe97 Hari Bathini 2021-02-04 843
33f2cc0a2e90f7 Hari Bathini 2024-02-26 844 /**
33f2cc0a2e90f7 Hari Bathini 2024-02-26 845 * kexec_extra_fdt_size_ppc64 -
Return the estimated additional size needed to
33f2cc0a2e90f7 Hari Bathini 2024-02-26 846 *
setup FDT for kexec/kdump kernel.
33f2cc0a2e90f7 Hari Bathini 2024-02-26 847 * @image:
kexec image being loaded.
33f2cc0a2e90f7 Hari Bathini 2024-02-26 848 *
33f2cc0a2e90f7 Hari Bathini 2024-02-26 849 * Returns the estimated extra
size needed for kexec/kdump kernel FDT.
33f2cc0a2e90f7 Hari Bathini 2024-02-26 850 */
f2c160891d3206 Sourabh Jain 2024-05-08 851 unsigned int
kexec_extra_fdt_size_ppc64(struct kimage *image, struct crash_mem *rmem)
33f2cc0a2e90f7 Hari Bathini 2024-02-26 @852 {
f2c160891d3206 Sourabh Jain 2024-05-08 853 struct device_node *dn;
f2c160891d3206 Sourabh Jain 2024-05-08 854 unsigned int cpu_nodes,
extra_size = 0;
33f2cc0a2e90f7 Hari Bathini 2024-02-26 855
33f2cc0a2e90f7 Hari Bathini 2024-02-26 856 // Budget some space for the
password blob. There's already extra space
33f2cc0a2e90f7 Hari Bathini 2024-02-26 857 // for the key name
33f2cc0a2e90f7 Hari Bathini 2024-02-26 858 if (plpks_is_available())
33f2cc0a2e90f7 Hari Bathini 2024-02-26 859 extra_size += (unsigned
int)plpks_get_passwordlen();
33f2cc0a2e90f7 Hari Bathini 2024-02-26 860
f2c160891d3206 Sourabh Jain 2024-05-08 861 /* Get the number of CPU nodes
in the current device tree */
f2c160891d3206 Sourabh Jain 2024-05-08 862 for_each_node_by_type(dn,
"cpu") {
f2c160891d3206 Sourabh Jain 2024-05-08 863 cpu_nodes++;
f2c160891d3206 Sourabh Jain 2024-05-08 864 }
f2c160891d3206 Sourabh Jain 2024-05-08 865
f2c160891d3206 Sourabh Jain 2024-05-08 866 /* Consider extra space for CPU
nodes added since the boot time */
f2c160891d3206 Sourabh Jain 2024-05-08 867 if (cpu_nodes >
boot_cpu_node_count)
f2c160891d3206 Sourabh Jain 2024-05-08 868 extra_size +=
(cpu_nodes - boot_cpu_node_count) * cpu_node_size();
f2c160891d3206 Sourabh Jain 2024-05-08 869
f2c160891d3206 Sourabh Jain 2024-05-08 870 /* Consider extra space for
reserved memory ranges if any */
f2c160891d3206 Sourabh Jain 2024-05-08 871 if (rmem->nr_ranges > 0)
f2c160891d3206 Sourabh Jain 2024-05-08 872 extra_size +=
sizeof(struct fdt_reserve_entry) * rmem->nr_ranges;
f2c160891d3206 Sourabh Jain 2024-05-08 873
f2c160891d3206 Sourabh Jain 2024-05-08 874 return extra_size +
kdump_extra_fdt_size_ppc64(image, cpu_nodes);
33f2cc0a2e90f7 Hari Bathini 2024-02-26 875 }
33f2cc0a2e90f7 Hari Bathini 2024-02-26 876
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: [PATCH 1/1] [RFC] ethernet: Convert from tasklet to BH workqueue
On Wed, 2024-05-08 at 21:16 +0100, Simon Horman wrote: > * As this patch seems to involve many non-trivial changes > it seems to me that it would be best to break it up somehow. > To allow proper review. I would like to stress this latest point: it looks like the changes to all the drivers are completely independent. If so, you have to break the series on a per driver basis. Since the total number of patch will be higher then 15 (maximum size allowed on netdev) you will have to split this in several smaller series. Beyond making the change reviewable, it will allow eventually reverting the changes individually, should that cause any regressions. Thanks, Paolo
Re: [PATCH 1/2] powerpc/kexec_file: fix extra size calculation for kexec FDT
Hi Sourabh,
kernel test robot noticed the following build warnings:
[auto build test WARNING on next-20240508]
[cannot apply to powerpc/next powerpc/fixes linus/master v6.9-rc7 v6.9-rc6
v6.9-rc5 v6.9-rc7]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Sourabh-Jain/powerpc-kexec_file-fix-extra-size-calculation-for-kexec-FDT/20240508-211003
base: next-20240508
patch link:
https://lore.kernel.org/r/20240508130558.1939304-2-sourabhjain%40linux.ibm.com
patch subject: [PATCH 1/2] powerpc/kexec_file: fix extra size calculation for
kexec FDT
config: powerpc-allyesconfig
(https://download.01.org/0day-ci/archive/20240509/202405091511.8sd2zyrn-...@intel.com/config)
compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project
0ab4458df0688955620b72cc2c72a32dffad3615)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240509/202405091511.8sd2zyrn-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202405091511.8sd2zyrn-...@intel.com/
All warnings (new ones prefixed by >>):
In file included from arch/powerpc/kexec/file_load_64.c:17:
In file included from include/linux/kexec.h:18:
In file included from include/linux/vmcore_info.h:6:
In file included from include/linux/elfcore.h:11:
In file included from include/linux/ptrace.h:10:
In file included from include/linux/pid_namespace.h:7:
In file included from include/linux/mm.h:2253:
include/linux/vmstat.h:500:43: warning: arithmetic between different
enumeration types ('enum zone_stat_item' and 'enum numa_stat_item')
[-Wenum-enum-conversion]
500 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
|~ ^
501 |item];
|
include/linux/vmstat.h:507:43: warning: arithmetic between different
enumeration types ('enum zone_stat_item' and 'enum numa_stat_item')
[-Wenum-enum-conversion]
507 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
|~ ^
508 |NR_VM_NUMA_EVENT_ITEMS +
|~~
include/linux/vmstat.h:514:36: warning: arithmetic between different
enumeration types ('enum node_stat_item' and 'enum lru_list')
[-Wenum-enum-conversion]
514 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_"
| ~~~ ^ ~~~
include/linux/vmstat.h:519:43: warning: arithmetic between different
enumeration types ('enum zone_stat_item' and 'enum numa_stat_item')
[-Wenum-enum-conversion]
519 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
|~ ^
520 |NR_VM_NUMA_EVENT_ITEMS +
|~~
include/linux/vmstat.h:528:43: warning: arithmetic between different
enumeration types ('enum zone_stat_item' and 'enum numa_stat_item')
[-Wenum-enum-conversion]
528 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
|~ ^
529 |NR_VM_NUMA_EVENT_ITEMS +
|~~
>> arch/powerpc/kexec/file_load_64.c:863:3: warning: variable 'cpu_nodes' is
>> uninitialized when used here [-Wuninitialized]
863 | cpu_nodes++;
| ^
arch/powerpc/kexec/file_load_64.c:854:24: note: initialize the variable
'cpu_nodes' to silence this warning
854 | unsigned int cpu_nodes, extra_size = 0;
| ^
|= 0
6 warnings generated.
vim +/cpu_nodes +863 arch/powerpc/kexec/file_load_64.c
843
844 /**
845 * kexec_extra_fdt_size_ppc64 - Return the estimated additional size
needed to
846 * setup FDT for kexec/kdump kernel.
847 * @image: kexec image being loaded.
848 *
849 * Returns the estimated extra size needed for kexec/kdump kernel FDT.
850 */
851 unsigned int kexec_extra_fdt_size_ppc64(struct kimage *image, struct
crash_mem *rmem)
852 {
853 struct device_node *dn;
854 unsigned int cpu_nodes, extra_size = 0;
855
856 // Budget some space for the password blob. There's already
extra space
857
