[RFC PATCH] powerpc: udbg: export udbg_putc

[Randy Dunlap]

In a randconfig with CONFIG_SERIAL_CPM=m and
CONFIG_PPC_EARLY_DEBUG_CPM=y, there is a build error:
ERROR: modpost: "udbg_putc" [drivers/tty/serial/cpm_uart/cpm_uart.ko] undefined!

The build can be fixed by exporting "udbg_putc" in udbg.c.

OTOH, maybe something like this is more appropriate in
arch/powerpc/Kconfig.debug?

config PPC_EARLY_DEBUG_CPM
bool "Early serial debugging for Freescale CPM-based serial ports"
-   depends on SERIAL_CPM
+   depends on SERIAL_CPM=y

Signed-off-by: Randy Dunlap 
Cc: Michael Ellerman 
Cc: Nicholas Piggin 
Cc: Christophe Leroy 
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Arnd Bergmann 
Cc: "Pali Rohár" 
---
 arch/powerpc/kernel/udbg.c |1 +
 1 file changed, 1 insertion(+)

diff -- a/arch/powerpc/kernel/udbg.c b/arch/powerpc/kernel/udbg.c
--- a/arch/powerpc/kernel/udbg.c
+++ b/arch/powerpc/kernel/udbg.c
@@ -14,6 +14,7 @@
 #include 
 
 void (*udbg_putc)(char c);
+EXPORT_SYMBOL(udbg_putc);
 void (*udbg_flush)(void);
 int (*udbg_getc)(void);
 int (*udbg_getc_poll)(void);

[PATCH v2] powerpc/embedded6xx: select MPC10X_BRIDGE only if PCI is set

[Randy Dunlap]

When CONFIG_SMP is not set, CONFIG_BROKEN_ON_SMP is set, and
CONFIG_PCI is not set, there can be a kconfig warning:

WARNING: unmet direct dependencies detected for PPC_INDIRECT_PCI
  Depends on [n]: PCI [=n]
  Selected by [y]:
  - MPC10X_BRIDGE [=y]

To fix that, make the selects of MPC10X_BRIDGE be conditional
on PCI and use "imply" instead of "select".

Signed-off-by: Randy Dunlap 
Cc: Michael Ellerman 
Cc: Nicholas Piggin 
Cc: Christophe Leroy 
Cc: linuxppc-dev@lists.ozlabs.org
Suggested-by: Michael Ellerman  # use "imply"
---
v2: use imply instead of select (mpe)

 arch/powerpc/platforms/embedded6xx/Kconfig |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff -- a/arch/powerpc/platforms/embedded6xx/Kconfig 
b/arch/powerpc/platforms/embedded6xx/Kconfig
--- a/arch/powerpc/platforms/embedded6xx/Kconfig
+++ b/arch/powerpc/platforms/embedded6xx/Kconfig
@@ -10,7 +10,7 @@ config LINKSTATION
select FSL_SOC
select PPC_UDBG_16550 if SERIAL_8250
select DEFAULT_UIMAGE
-   select MPC10X_BRIDGE
+   imply MPC10X_BRIDGE if PCI
help
  Select LINKSTATION if configuring for one of PPC- (MPC8241)
  based NAS systems from Buffalo Technology. So far only
@@ -24,7 +24,7 @@ config STORCENTER
select MPIC
select FSL_SOC
select PPC_UDBG_16550 if SERIAL_8250
-   select MPC10X_BRIDGE
+   imply MPC10X_BRIDGE if PCI
help
  Select STORCENTER if configuring for the iomega StorCenter
  with an 8241 CPU in it.

Re: [PATCH v2] soc/fsl/qe: fix usb.c build errors

[Randy Dunlap]

Any comments on this patch?

I am still seeing this build error.

On 4/9/23 18:12, Randy Dunlap wrote:
> Fix build errors in soc/fsl/qe/usb.c when QUICC_ENGINE is not set.
> This happens when PPC_EP88XC is set, which selects CPM1 & CPM.
> When CPM is set, USB_FSL_QE can be set without QUICC_ENGINE
> being set. When USB_FSL_QE is set, QE_USB deafults to y, which
> causes build errors when QUICC_ENGINE is not set. Making
> QE_USB depend on QUICC_ENGINE prevents QE_USB from defaulting to y.
> 
> Fixes these build errors:
> 
> drivers/soc/fsl/qe/usb.o: in function `qe_usb_clock_set':
> usb.c:(.text+0x1e): undefined reference to `qe_immr'
> powerpc-linux-ld: usb.c:(.text+0x2a): undefined reference to `qe_immr'
> powerpc-linux-ld: usb.c:(.text+0xbc): undefined reference to `qe_setbrg'
> powerpc-linux-ld: usb.c:(.text+0xca): undefined reference to `cmxgcr_lock'
> powerpc-linux-ld: usb.c:(.text+0xce): undefined reference to `cmxgcr_lock'
> 
> Fixes: 5e41486c408e ("powerpc/QE: add support for QE USB clocks routing")
> Signed-off-by: Randy Dunlap 
> Reported-by: kernel test robot 
> Link: https://lore.kernel.org/all/202301101500.pillnv6r-...@intel.com/
> Suggested-by: Michael Ellerman 
> Cc: Christophe Leroy 
> Cc: Leo Li 
> Cc: Masahiro Yamada 
> Cc: Nicolas Schier 
> Cc: Qiang Zhao 
> Cc: linuxppc-dev 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: Kumar Gala 
> ---
> v2: drop Anton Vorontsov ; rebase/resend
> 
>  drivers/soc/fsl/qe/Kconfig |1 +
>  1 file changed, 1 insertion(+)
> 
> diff -- a/drivers/soc/fsl/qe/Kconfig b/drivers/soc/fsl/qe/Kconfig
> --- a/drivers/soc/fsl/qe/Kconfig
> +++ b/drivers/soc/fsl/qe/Kconfig
> @@ -62,6 +62,7 @@ config QE_TDM
>  
>  config QE_USB
>   bool
> + depends on QUICC_ENGINE
>   default y if USB_FSL_QE
>   help
> QE USB Controller support

-- 
~Randy

Re: Fwd: Linux 6.3.1 + AMD RX 570 on ppc64le 4K: Kernel attempted to read user page (1128) - exploit attempt? (uid: 0)

[Greg Kroah-Hartman]

On Fri, May 12, 2023 at 03:25:47PM +, Christophe Leroy wrote:
> 
> 
> Le 12/05/2023 à 17:16, Christophe Leroy a écrit :
> > 
> > 
> > Le 11/05/2023 à 19:25, Niccolò Belli a écrit :
> >> [Vous ne recevez pas souvent de courriers de 
> >> darkba...@linuxsystems.it. D?couvrez pourquoi ceci est important ? 
> >> https://aka.ms/LearnAboutSenderIdentification ]
> >>
> >> Il 2023-05-12 10:32 Bagas Sanjaya ha scritto:
> >>> #regzbot introduced: f4f3b7dedbe849
> >>> #regzbot link: https://gitlab.freedesktop.org/drm/amd/-/issues/2553
> >>
> >> It doesn't look like the aforementioned patch made its way into 6.3 yet:
> >>
> >> niko@talos2 ~/devel/linux-stable $ git branch
> >> * linux-6.3.y
> >>    master
> >> niko@talos2 ~/devel/linux-stable $ git show f4f3b7dedbe8 | patch -p1
> >> patching file
> >> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> >> Hunk #1 succeeded at 227 (offset 15 lines).
> >> Hunk #2 succeeded at 269 with fuzz 2 (offset 19 lines).
> >> patching file
> >> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.h
> >> Hunk #1 succeeded at 49 with fuzz 2 (offset 15 lines).
> > 
> > As far as I can see that patch has no Fixes: tag, so it will unlikely be 
> > automatically merged into stable.
> > 
> > Has anybody requested greg/sasha to get it into 6.3 ?
> > 
> 
> In fact, it seems that patch is already part of 6.3:
> 
> $ git tag --contains f4f3b7dedbe8
> v6.3
> v6.3-rc5
> v6.3-rc6
> v6.3-rc7
> v6.3.1
> v6.3.2
> v6.4-rc1

And that commit is already in the following releases:
5.10.177 5.15.106 6.1.23 6.2.10 6.3

So what needs to be done here?

confused,

greg k-h

Re: Fwd: Linux 6.3.1 + AMD RX 570 on ppc64le 4K: Kernel attempted to read user page (1128) - exploit attempt? (uid: 0)

[Niccolò Belli]

Il 2023-05-12 10:32 Bagas Sanjaya ha scritto:

#regzbot introduced: f4f3b7dedbe849
#regzbot link: https://gitlab.freedesktop.org/drm/amd/-/issues/2553


It doesn't look like the aforementioned patch made its way into 6.3 yet:

niko@talos2 ~/devel/linux-stable $ git branch
* linux-6.3.y
  master
niko@talos2 ~/devel/linux-stable $ git show f4f3b7dedbe8 | patch -p1
patching file 
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c

Hunk #1 succeeded at 227 (offset 15 lines).
Hunk #2 succeeded at 269 with fuzz 2 (offset 19 lines).
patching file 
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.h

Hunk #1 succeeded at 49 with fuzz 2 (offset 15 lines).

Re: [PATCH v8 0/7] Add pci_dev_for_each_resource() helper and update users

[Bjorn Helgaas]

On Fri, May 12, 2023 at 01:56:29PM +0300, Andy Shevchenko wrote:
> On Tue, May 09, 2023 at 01:21:22PM -0500, Bjorn Helgaas wrote:
> > On Tue, Apr 04, 2023 at 11:11:01AM -0500, Bjorn Helgaas wrote:
> > > On Thu, Mar 30, 2023 at 07:24:27PM +0300, Andy Shevchenko wrote:
> > > > Provide two new helper macros to iterate over PCI device resources and
> > > > convert users.
> > 
> > > Applied 2-7 to pci/resource for v6.4, thanks, I really like this!
> > 
> > This is 09cc90063240 ("PCI: Introduce pci_dev_for_each_resource()")
> > upstream now.
> > 
> > Coverity complains about each use,
> 
> It needs more clarification here. Use of reduced variant of the
> macro or all of them? If the former one, then I can speculate that
> Coverity (famous for false positives) simply doesn't understand `for
> (type var; var ...)` code.

True, Coverity finds false positives.  It flagged every use in
drivers/pci and drivers/pnp.  It didn't mention the arch/alpha, arm,
mips, powerpc, sh, or sparc uses, but I think it just didn't look at
those.

It flagged both:

  pbus_size_iopci_dev_for_each_resource(dev, r)
  pbus_size_mem   pci_dev_for_each_resource(dev, r, i)

Here's a spreadsheet with a few more details (unfortunately I don't
know how to make it dump the actual line numbers or analysis like I
pasted below, so "pci_dev_for_each_resource" doesn't appear).  These
are mostly in the "Drivers-PCI" component.

https://docs.google.com/spreadsheets/d/1ohOJwxqXXoDUA0gwopgk-z-6ArLvhN7AZn4mIlDkHhQ/edit?usp=sharing

These particular reports are in the "High Impact Outstanding" tab.

> > sample below from
> > drivers/pci/vgaarb.c.  I didn't investigate at all, so it might be a
> > false positive; just FYI.
> > 
> >   1. Condition screen_info.capabilities & (2U /* 1 << 1 */), taking 
> > true branch.
> >   556if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
> >   557base |= (u64)screen_info.ext_lfb_base << 32;
> >   558
> >   559limit = base + size;
> >   560
> >   561/* Does firmware framebuffer belong to us? */
> >   2. Condition __b < PCI_NUM_RESOURCES, taking true branch.
> >   3. Condition (r = >resource[__b]) , (__b < PCI_NUM_RESOURCES), 
> > taking true branch.
> >   6. Condition __b < PCI_NUM_RESOURCES, taking true branch.
> >   7. cond_at_most: Checking __b < PCI_NUM_RESOURCES implies that __b 
> > may be up to 16 on the true branch.
> >   8. Condition (r = >resource[__b]) , (__b < PCI_NUM_RESOURCES), 
> > taking true branch.
> >   11. incr: Incrementing __b. The value of __b may now be up to 17.
> >   12. alias: Assigning: r = >resource[__b]. r may now point to as 
> > high as element 17 of pdev->resource (which consists of 17 64-byte 
> > elements).
> >   13. Condition __b < PCI_NUM_RESOURCES, taking true branch.
> >   14. Condition (r = >resource[__b]) , (__b < PCI_NUM_RESOURCES), 
> > taking true branch.
> >   562pci_dev_for_each_resource(pdev, r) {
> >   4. Condition resource_type(r) != 512, taking true branch.
> >   9. Condition resource_type(r) != 512, taking true branch.
> > 
> >   CID 1529911 (#1 of 1): Out-of-bounds read (OVERRUN)
> >   15. overrun-local: Overrunning array of 1088 bytes at byte offset 1088 by 
> > dereferencing pointer r. [show details]
> >   563if (resource_type(r) != IORESOURCE_MEM)
> >   5. Continuing loop.
> >   10. Continuing loop.
> >   564continue;
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 

Re: [PATCH v8 1/3] riscv: Introduce CONFIG_RELOCATABLE

[Palmer Dabbelt]

On Thu, 11 May 2023 11:18:23 PDT (-0700), sch...@linux-m68k.org wrote:

On Mai 09 2023, Alexandre Ghiti wrote:


On 5/9/23 21:07, Andreas Schwab wrote:

That does not work with UEFI booting:

Loading Linux 6.4.0-rc1-1.g668187d-default ...
Loading initial ramdisk ...
Unhandled exception: Instruction access fault
EPC: 80016d56 RA: 8020334e TVAL: 007f80016d56
EPC: 002d1d56 RA: 004be34e reloc adjusted
Unhandled exception: Load access fault
EPC: fff462d4 RA: fff462d0 TVAL: 80016d56
EPC: 802012d4 RA: 802012d0 reloc adjusted

Code: c825 8e0d 05b3 40b4 d0ef 0636 7493 ffe4 (d783 0004)
UEFI image [0xfe65e000:0xfe6e3fff] '/efi\boot\bootriscv64.efi'
UEFI image [0xdaa82000:0xdcc2afff]



I need more details please, as I have a UEFI bootflow and it works great
(KASLR is based on a relocatable kernel and works fine in UEFI too).


It also crashes without UEFI.  Disabling CONFIG_RELOCATABLE fixes that.
This was tested on the HiFive Unmatched board.
The kernel image I tested is available from
.  The
same kernel with CONFIG_RELOCATABLE disabled is available from
.


Sorry I missed this earlier, there's been some other reports of boot 
failures on rc1 showing up but those were all a lot more vague.  Just 
setting CONFIG_RELOCATABLE=y doesn't manifest a boot failure on QEMU on 
my end and I don't have an UNmatched floating around.


Alex says he's going to look into it (and IIRC he has my Unmatched...).

Re: [PATCH 1/3] kcsan: Don't expect 64 bits atomic builtins from 32 bits architectures

[Christophe Leroy]

Le 12/05/2023 à 18:09, Marco Elver a écrit :
> On Fri, 12 May 2023 at 17:31, Christophe Leroy
>  wrote:
>>
>> Activating KCSAN on a 32 bits architecture leads to the following
>> link-time failure:
>>
>>  LD  .tmp_vmlinux.kallsyms1
>>powerpc64-linux-ld: kernel/kcsan/core.o: in function 
>> `__tsan_atomic64_load':
>>kernel/kcsan/core.c:1273: undefined reference to `__atomic_load_8'
>>powerpc64-linux-ld: kernel/kcsan/core.o: in function 
>> `__tsan_atomic64_store':
>>kernel/kcsan/core.c:1273: undefined reference to `__atomic_store_8'
>>powerpc64-linux-ld: kernel/kcsan/core.o: in function 
>> `__tsan_atomic64_exchange':
>>kernel/kcsan/core.c:1273: undefined reference to `__atomic_exchange_8'
>>powerpc64-linux-ld: kernel/kcsan/core.o: in function 
>> `__tsan_atomic64_fetch_add':
>>kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_add_8'
>>powerpc64-linux-ld: kernel/kcsan/core.o: in function 
>> `__tsan_atomic64_fetch_sub':
>>kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_sub_8'
>>powerpc64-linux-ld: kernel/kcsan/core.o: in function 
>> `__tsan_atomic64_fetch_and':
>>kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_and_8'
>>powerpc64-linux-ld: kernel/kcsan/core.o: in function 
>> `__tsan_atomic64_fetch_or':
>>kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_or_8'
>>powerpc64-linux-ld: kernel/kcsan/core.o: in function 
>> `__tsan_atomic64_fetch_xor':
>>kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_xor_8'
>>powerpc64-linux-ld: kernel/kcsan/core.o: in function 
>> `__tsan_atomic64_fetch_nand':
>>kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_nand_8'
>>powerpc64-linux-ld: kernel/kcsan/core.o: in function 
>> `__tsan_atomic64_compare_exchange_strong':
>>kernel/kcsan/core.c:1273: undefined reference to 
>> `__atomic_compare_exchange_8'
>>powerpc64-linux-ld: kernel/kcsan/core.o: in function 
>> `__tsan_atomic64_compare_exchange_weak':
>>kernel/kcsan/core.c:1273: undefined reference to 
>> `__atomic_compare_exchange_8'
>>powerpc64-linux-ld: kernel/kcsan/core.o: in function 
>> `__tsan_atomic64_compare_exchange_val':
>>kernel/kcsan/core.c:1273: undefined reference to 
>> `__atomic_compare_exchange_8'
>>
>> 32 bits architectures don't have 64 bits atomic builtins. Only
>> include DEFINE_TSAN_ATOMIC_OPS(64) on 64 bits architectures.
>>
>> Fixes: 0f8ad5f2e934 ("kcsan: Add support for atomic builtins")
>> Suggested-by: Marco Elver 
>> Signed-off-by: Christophe Leroy 
> 
> Reviewed-by: Marco Elver 
> 
> Do you have your own tree to take this through with the other patches?

I don't have my own tree but I guess that it can be taken by Michael for 
6.5 via powerpc tree with acks from you and Max.

Michael is that ok for you ?

Christophe

[Bug 217427] Linux 6.3.1 + AMD RX 570 on ppc64le 4K: Kernel attempted to read user page (1128) - exploit attempt? (uid: 0)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217427

Artem S. Tashkinov (a...@gmx.com) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

Re: [PATCH 3/3] xtensa: Remove 64 bits atomic builtins stubs

[Max Filippov]

On Fri, May 12, 2023 at 8:31 AM Christophe Leroy
 wrote:
>
> The stubs were provided by commit 725aea873261 ("xtensa: enable KCSAN")
> to make linker happy allthought they are not meant to be used at all.
>
> KCSAN core has been fixed to not require them anymore on
> 32 bits architectures.
>
> Then they can be removed.
>
> Signed-off-by: Christophe Leroy 
> ---
>  arch/xtensa/lib/Makefile  |  2 --
>  arch/xtensa/lib/kcsan-stubs.c | 54 ---
>  2 files changed, 56 deletions(-)
>  delete mode 100644 arch/xtensa/lib/kcsan-stubs.c

Acked-by: Max Filippov 

-- 
Thanks.
-- Max

Re: [PATCH 0/3] Extend KCSAN to all powerpc

[Marco Elver]

On Fri, 12 May 2023 at 17:31, Christophe Leroy
 wrote:
>
> This series enables KCSAN on all powerpc.
>
> To do this, a fix is required to KCSAN core.
>
> Once that fix is done, the stubs can also be removed from xtensa.
>
> It would be nice if patch 1 could go in v6.4 as a fix, then patches 2 and 3
> could be handled separately in each architecture in next cycle.
>
> Christophe Leroy (2):
>   kcsan: Don't expect 64 bits atomic builtins from 32 bits architectures
>   xtensa: Remove 64 bits atomic builtins stubs
>
> Rohan McLure (1):
>   powerpc/{32,book3e}: kcsan: Extend KCSAN Support

Acked-by: Marco Elver 

Re: [PATCH 1/3] kcsan: Don't expect 64 bits atomic builtins from 32 bits architectures

[Marco Elver]

On Fri, 12 May 2023 at 17:31, Christophe Leroy
 wrote:
>
> Activating KCSAN on a 32 bits architecture leads to the following
> link-time failure:
>
> LD  .tmp_vmlinux.kallsyms1
>   powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_load':
>   kernel/kcsan/core.c:1273: undefined reference to `__atomic_load_8'
>   powerpc64-linux-ld: kernel/kcsan/core.o: in function 
> `__tsan_atomic64_store':
>   kernel/kcsan/core.c:1273: undefined reference to `__atomic_store_8'
>   powerpc64-linux-ld: kernel/kcsan/core.o: in function 
> `__tsan_atomic64_exchange':
>   kernel/kcsan/core.c:1273: undefined reference to `__atomic_exchange_8'
>   powerpc64-linux-ld: kernel/kcsan/core.o: in function 
> `__tsan_atomic64_fetch_add':
>   kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_add_8'
>   powerpc64-linux-ld: kernel/kcsan/core.o: in function 
> `__tsan_atomic64_fetch_sub':
>   kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_sub_8'
>   powerpc64-linux-ld: kernel/kcsan/core.o: in function 
> `__tsan_atomic64_fetch_and':
>   kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_and_8'
>   powerpc64-linux-ld: kernel/kcsan/core.o: in function 
> `__tsan_atomic64_fetch_or':
>   kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_or_8'
>   powerpc64-linux-ld: kernel/kcsan/core.o: in function 
> `__tsan_atomic64_fetch_xor':
>   kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_xor_8'
>   powerpc64-linux-ld: kernel/kcsan/core.o: in function 
> `__tsan_atomic64_fetch_nand':
>   kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_nand_8'
>   powerpc64-linux-ld: kernel/kcsan/core.o: in function 
> `__tsan_atomic64_compare_exchange_strong':
>   kernel/kcsan/core.c:1273: undefined reference to 
> `__atomic_compare_exchange_8'
>   powerpc64-linux-ld: kernel/kcsan/core.o: in function 
> `__tsan_atomic64_compare_exchange_weak':
>   kernel/kcsan/core.c:1273: undefined reference to 
> `__atomic_compare_exchange_8'
>   powerpc64-linux-ld: kernel/kcsan/core.o: in function 
> `__tsan_atomic64_compare_exchange_val':
>   kernel/kcsan/core.c:1273: undefined reference to 
> `__atomic_compare_exchange_8'
>
> 32 bits architectures don't have 64 bits atomic builtins. Only
> include DEFINE_TSAN_ATOMIC_OPS(64) on 64 bits architectures.
>
> Fixes: 0f8ad5f2e934 ("kcsan: Add support for atomic builtins")
> Suggested-by: Marco Elver 
> Signed-off-by: Christophe Leroy 

Reviewed-by: Marco Elver 

Do you have your own tree to take this through with the other patches?

> ---
>  kernel/kcsan/core.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/kernel/kcsan/core.c b/kernel/kcsan/core.c
> index 5a60cc52adc0..8a7baf4e332e 100644
> --- a/kernel/kcsan/core.c
> +++ b/kernel/kcsan/core.c
> @@ -1270,7 +1270,9 @@ static __always_inline void 
> kcsan_atomic_builtin_memorder(int memorder)
>  DEFINE_TSAN_ATOMIC_OPS(8);
>  DEFINE_TSAN_ATOMIC_OPS(16);
>  DEFINE_TSAN_ATOMIC_OPS(32);
> +#ifdef CONFIG_64BIT
>  DEFINE_TSAN_ATOMIC_OPS(64);
> +#endif
>
>  void __tsan_atomic_thread_fence(int memorder);
>  void __tsan_atomic_thread_fence(int memorder)
> --
> 2.40.1
>

[PATCH 2/3] powerpc/{32,book3e}: kcsan: Extend KCSAN Support

[Christophe Leroy]

From: Rohan McLure 

Enable HAVE_ARCH_KCSAN on all powerpc platforms, permitting use of the
kernel concurrency sanitiser through the CONFIG_KCSAN_* kconfig options.

Boots and passes selftests on 32-bit and 64-bit platforms. See
documentation in Documentation/dev-tools/kcsan.rst for more information.

Signed-off-by: Rohan McLure 
Signed-off-by: Christophe Leroy 
---
 arch/powerpc/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 539d1f03ff42..2f6af3cb75d6 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -211,7 +211,7 @@ config PPC
select HAVE_ARCH_KASAN  if PPC_RADIX_MMU
select HAVE_ARCH_KASAN  if PPC_BOOK3E_64
select HAVE_ARCH_KASAN_VMALLOC  if HAVE_ARCH_KASAN
-   select HAVE_ARCH_KCSAN  if PPC_BOOK3S_64
+   select HAVE_ARCH_KCSAN
select HAVE_ARCH_KFENCE if ARCH_SUPPORTS_DEBUG_PAGEALLOC
select HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET
select HAVE_ARCH_WITHIN_STACK_FRAMES
-- 
2.40.1

[PATCH 0/3] Extend KCSAN to all powerpc

[Christophe Leroy]

This series enables KCSAN on all powerpc.

To do this, a fix is required to KCSAN core.

Once that fix is done, the stubs can also be removed from xtensa.

It would be nice if patch 1 could go in v6.4 as a fix, then patches 2 and 3
could be handled separately in each architecture in next cycle.

Christophe Leroy (2):
  kcsan: Don't expect 64 bits atomic builtins from 32 bits architectures
  xtensa: Remove 64 bits atomic builtins stubs

Rohan McLure (1):
  powerpc/{32,book3e}: kcsan: Extend KCSAN Support

 arch/powerpc/Kconfig  |  2 +-
 arch/xtensa/lib/Makefile  |  2 --
 arch/xtensa/lib/kcsan-stubs.c | 54 ---
 kernel/kcsan/core.c   |  2 ++
 4 files changed, 3 insertions(+), 57 deletions(-)
 delete mode 100644 arch/xtensa/lib/kcsan-stubs.c

-- 
2.40.1

[PATCH 3/3] xtensa: Remove 64 bits atomic builtins stubs

[Christophe Leroy]

The stubs were provided by commit 725aea873261 ("xtensa: enable KCSAN")
to make linker happy allthought they are not meant to be used at all.

KCSAN core has been fixed to not require them anymore on
32 bits architectures.

Then they can be removed.

Signed-off-by: Christophe Leroy 
---
 arch/xtensa/lib/Makefile  |  2 --
 arch/xtensa/lib/kcsan-stubs.c | 54 ---
 2 files changed, 56 deletions(-)
 delete mode 100644 arch/xtensa/lib/kcsan-stubs.c

diff --git a/arch/xtensa/lib/Makefile b/arch/xtensa/lib/Makefile
index 7ecef0519a27..23c22411d1d9 100644
--- a/arch/xtensa/lib/Makefile
+++ b/arch/xtensa/lib/Makefile
@@ -8,5 +8,3 @@ lib-y   += memcopy.o memset.o checksum.o \
   divsi3.o udivsi3.o modsi3.o umodsi3.o mulsi3.o umulsidi3.o \
   usercopy.o strncpy_user.o strnlen_user.o
 lib-$(CONFIG_PCI) += pci-auto.o
-lib-$(CONFIG_KCSAN) += kcsan-stubs.o
-KCSAN_SANITIZE_kcsan-stubs.o := n
diff --git a/arch/xtensa/lib/kcsan-stubs.c b/arch/xtensa/lib/kcsan-stubs.c
deleted file mode 100644
index 2b08faa62b86..
--- a/arch/xtensa/lib/kcsan-stubs.c
+++ /dev/null
@@ -1,54 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-
-#include 
-#include 
-
-void __atomic_store_8(volatile void *p, u64 v, int i)
-{
-   BUG();
-}
-
-u64 __atomic_load_8(const volatile void *p, int i)
-{
-   BUG();
-}
-
-u64 __atomic_exchange_8(volatile void *p, u64 v, int i)
-{
-   BUG();
-}
-
-bool __atomic_compare_exchange_8(volatile void *p1, void *p2, u64 v, bool b, 
int i1, int i2)
-{
-   BUG();
-}
-
-u64 __atomic_fetch_add_8(volatile void *p, u64 v, int i)
-{
-   BUG();
-}
-
-u64 __atomic_fetch_sub_8(volatile void *p, u64 v, int i)
-{
-   BUG();
-}
-
-u64 __atomic_fetch_and_8(volatile void *p, u64 v, int i)
-{
-   BUG();
-}
-
-u64 __atomic_fetch_or_8(volatile void *p, u64 v, int i)
-{
-   BUG();
-}
-
-u64 __atomic_fetch_xor_8(volatile void *p, u64 v, int i)
-{
-   BUG();
-}
-
-u64 __atomic_fetch_nand_8(volatile void *p, u64 v, int i)
-{
-   BUG();
-}
-- 
2.40.1

[PATCH 1/3] kcsan: Don't expect 64 bits atomic builtins from 32 bits architectures

[Christophe Leroy]

Activating KCSAN on a 32 bits architecture leads to the following
link-time failure:

LD  .tmp_vmlinux.kallsyms1
  powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_load':
  kernel/kcsan/core.c:1273: undefined reference to `__atomic_load_8'
  powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_store':
  kernel/kcsan/core.c:1273: undefined reference to `__atomic_store_8'
  powerpc64-linux-ld: kernel/kcsan/core.o: in function 
`__tsan_atomic64_exchange':
  kernel/kcsan/core.c:1273: undefined reference to `__atomic_exchange_8'
  powerpc64-linux-ld: kernel/kcsan/core.o: in function 
`__tsan_atomic64_fetch_add':
  kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_add_8'
  powerpc64-linux-ld: kernel/kcsan/core.o: in function 
`__tsan_atomic64_fetch_sub':
  kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_sub_8'
  powerpc64-linux-ld: kernel/kcsan/core.o: in function 
`__tsan_atomic64_fetch_and':
  kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_and_8'
  powerpc64-linux-ld: kernel/kcsan/core.o: in function 
`__tsan_atomic64_fetch_or':
  kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_or_8'
  powerpc64-linux-ld: kernel/kcsan/core.o: in function 
`__tsan_atomic64_fetch_xor':
  kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_xor_8'
  powerpc64-linux-ld: kernel/kcsan/core.o: in function 
`__tsan_atomic64_fetch_nand':
  kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_nand_8'
  powerpc64-linux-ld: kernel/kcsan/core.o: in function 
`__tsan_atomic64_compare_exchange_strong':
  kernel/kcsan/core.c:1273: undefined reference to `__atomic_compare_exchange_8'
  powerpc64-linux-ld: kernel/kcsan/core.o: in function 
`__tsan_atomic64_compare_exchange_weak':
  kernel/kcsan/core.c:1273: undefined reference to `__atomic_compare_exchange_8'
  powerpc64-linux-ld: kernel/kcsan/core.o: in function 
`__tsan_atomic64_compare_exchange_val':
  kernel/kcsan/core.c:1273: undefined reference to `__atomic_compare_exchange_8'

32 bits architectures don't have 64 bits atomic builtins. Only
include DEFINE_TSAN_ATOMIC_OPS(64) on 64 bits architectures.

Fixes: 0f8ad5f2e934 ("kcsan: Add support for atomic builtins")
Suggested-by: Marco Elver 
Signed-off-by: Christophe Leroy 
---
 kernel/kcsan/core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/kcsan/core.c b/kernel/kcsan/core.c
index 5a60cc52adc0..8a7baf4e332e 100644
--- a/kernel/kcsan/core.c
+++ b/kernel/kcsan/core.c
@@ -1270,7 +1270,9 @@ static __always_inline void 
kcsan_atomic_builtin_memorder(int memorder)
 DEFINE_TSAN_ATOMIC_OPS(8);
 DEFINE_TSAN_ATOMIC_OPS(16);
 DEFINE_TSAN_ATOMIC_OPS(32);
+#ifdef CONFIG_64BIT
 DEFINE_TSAN_ATOMIC_OPS(64);
+#endif
 
 void __tsan_atomic_thread_fence(int memorder);
 void __tsan_atomic_thread_fence(int memorder)
-- 
2.40.1

Re: Fwd: Linux 6.3.1 + AMD RX 570 on ppc64le 4K: Kernel attempted to read user page (1128) - exploit attempt? (uid: 0)

[Christophe Leroy]

Le 12/05/2023 à 17:16, Christophe Leroy a écrit :
> 
> 
> Le 11/05/2023 à 19:25, Niccolò Belli a écrit :
>> [Vous ne recevez pas souvent de courriers de 
>> darkba...@linuxsystems.it. D?couvrez pourquoi ceci est important ? 
>> https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Il 2023-05-12 10:32 Bagas Sanjaya ha scritto:
>>> #regzbot introduced: f4f3b7dedbe849
>>> #regzbot link: https://gitlab.freedesktop.org/drm/amd/-/issues/2553
>>
>> It doesn't look like the aforementioned patch made its way into 6.3 yet:
>>
>> niko@talos2 ~/devel/linux-stable $ git branch
>> * linux-6.3.y
>>    master
>> niko@talos2 ~/devel/linux-stable $ git show f4f3b7dedbe8 | patch -p1
>> patching file
>> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
>> Hunk #1 succeeded at 227 (offset 15 lines).
>> Hunk #2 succeeded at 269 with fuzz 2 (offset 19 lines).
>> patching file
>> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.h
>> Hunk #1 succeeded at 49 with fuzz 2 (offset 15 lines).
> 
> As far as I can see that patch has no Fixes: tag, so it will unlikely be 
> automatically merged into stable.
> 
> Has anybody requested greg/sasha to get it into 6.3 ?
> 

In fact, it seems that patch is already part of 6.3:

$ git tag --contains f4f3b7dedbe8
v6.3
v6.3-rc5
v6.3-rc6
v6.3-rc7
v6.3.1
v6.3.2
v6.4-rc1

Re: Fwd: Linux 6.3.1 + AMD RX 570 on ppc64le 4K: Kernel attempted to read user page (1128) - exploit attempt? (uid: 0)

[Alex Deucher]

On Fri, May 12, 2023 at 11:16 AM Christophe Leroy
 wrote:
>
>
>
> Le 11/05/2023 à 19:25, Niccolò Belli a écrit :
> > [Vous ne recevez pas souvent de courriers de darkba...@linuxsystems.it.
> > D?couvrez pourquoi ceci est important ?
> > https://aka.ms/LearnAboutSenderIdentification ]
> >
> > Il 2023-05-12 10:32 Bagas Sanjaya ha scritto:
> >> #regzbot introduced: f4f3b7dedbe849
> >> #regzbot link: https://gitlab.freedesktop.org/drm/amd/-/issues/2553
> >
> > It doesn't look like the aforementioned patch made its way into 6.3 yet:
> >
> > niko@talos2 ~/devel/linux-stable $ git branch
> > * linux-6.3.y
> >master
> > niko@talos2 ~/devel/linux-stable $ git show f4f3b7dedbe8 | patch -p1
> > patching file
> > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > Hunk #1 succeeded at 227 (offset 15 lines).
> > Hunk #2 succeeded at 269 with fuzz 2 (offset 19 lines).
> > patching file
> > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.h
> > Hunk #1 succeeded at 49 with fuzz 2 (offset 15 lines).
>
> As far as I can see that patch has no Fixes: tag, so it will unlikely be
> automatically merged into stable.
>
> Has anybody requested greg/sasha to get it into 6.3 ?

This is no fix identified yet.

Alex

Re: Fwd: Linux 6.3.1 + AMD RX 570 on ppc64le 4K: Kernel attempted to read user page (1128) - exploit attempt? (uid: 0)

[Christophe Leroy]

Le 11/05/2023 à 19:25, Niccolò Belli a écrit :
> [Vous ne recevez pas souvent de courriers de darkba...@linuxsystems.it. 
> D?couvrez pourquoi ceci est important ? 
> https://aka.ms/LearnAboutSenderIdentification ]
> 
> Il 2023-05-12 10:32 Bagas Sanjaya ha scritto:
>> #regzbot introduced: f4f3b7dedbe849
>> #regzbot link: https://gitlab.freedesktop.org/drm/amd/-/issues/2553
> 
> It doesn't look like the aforementioned patch made its way into 6.3 yet:
> 
> niko@talos2 ~/devel/linux-stable $ git branch
> * linux-6.3.y
>    master
> niko@talos2 ~/devel/linux-stable $ git show f4f3b7dedbe8 | patch -p1
> patching file
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> Hunk #1 succeeded at 227 (offset 15 lines).
> Hunk #2 succeeded at 269 with fuzz 2 (offset 19 lines).
> patching file
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.h
> Hunk #1 succeeded at 49 with fuzz 2 (offset 15 lines).

As far as I can see that patch has no Fixes: tag, so it will unlikely be 
automatically merged into stable.

Has anybody requested greg/sasha to get it into 6.3 ?

Christophe

Re: [PATCH v4 12/17] watchdog/hardlockup: Have the perf hardlockup use __weak functions more cleanly

[Petr Mladek]

On Thu 2023-05-04 15:13:44, Douglas Anderson wrote:
> The fact that there watchdog_hardlockup_enable(),
> watchdog_hardlockup_disable(), and watchdog_hardlockup_probe() are
> declared __weak means that the configured hardlockup detector can
> define non-weak versions of those functions if it needs to. Instead of
> doing this, the perf hardlockup detector hooked itself into the
> default __weak implementation, which was a bit awkward. Clean this up.
> 
> >From comments, it looks as if the original design was done because the
> __weak function were expected to implemented by the architecture and
> not by the configured hardlockup detector. This got awkward when we
> tried to add the buddy lockup detector which was not arch-specific but
> wanted to hook into those same functions.
> 
> This is not expected to have any functional impact.
> 
> Signed-off-by: Douglas Anderson 

I like this change:

Reviewed-by: Petr Mladek 

See a comment below.

> --- a/kernel/watchdog_perf.c
> +++ b/kernel/watchdog_perf.c
> @@ -147,12 +151,16 @@ void hardlockup_detector_perf_enable(void)
>  }
>  
>  /**
> - * hardlockup_detector_perf_disable - Disable the local event
> + * watchdog_hardlockup_disable - Disable the local event
> + *
> + * @cpu: The CPU to enable hard lockup on.
>   */
> -void hardlockup_detector_perf_disable(void)
> +void watchdog_hardlockup_disable(unsigned int cpu)
>  {
>   struct perf_event *event = this_cpu_read(watchdog_ev);
>  
> + WARN_ON_ONCE(cpu != smp_processor_id());
> +

It makes sense. But it just shows how the code is weird.
@cpu is passed as a parameter and the code expects that it is
running on the given CPU.

It seems that @cpu is passed as a parameter because this is
called from:

  + [CPUHP_AP_WATCHDOG_ONLINE].teardown.single()
+ lockup_detector_offline_cpu()
  + watchdog_disable()

and the CPU hotplug API passes @cpu parameter.

IMHO, the clean solution would be to use per_cpu*() instead
of this_cpu*() API everywhere in this code path.

But it is yet another cleanup. It seems to be out-of-scope of
this patchset.

>   if (event) {
>   perf_event_disable(event);
>   this_cpu_write(watchdog_ev, NULL);

Best Regards,
Petr

Re: [PATCH v4 11/17] watchdog/hardlockup: Rename some "NMI watchdog" constants/function

[Petr Mladek]

On Fri 2023-05-05 13:06:41, Nicholas Piggin wrote:
> On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote:
> > Do a search and replace of:
> > - NMI_WATCHDOG_ENABLED => HARD_WATCHDOG_ENABLED
> > - watchdog_nmi_ => watchdog_hardlockup_
> 
> These are just making prefixes inconsistent again.

Yeah, HARD_WATCHDOG_ENABLED does not fit in. I would personally
rename:

  - NMI_WATCHDOG_ENABLED => WATCHDOG_HARDLOCKUP_ENABLED
  - SOFT_WATCHDOG_ENABLED => WATCHDOG_SOFTOCKUP_ENABLED

to follow the new name space.

> If you really want to do a prefix, I would call it hardlockup which

I wish, we found a good short prefix. My problem with hardlockup_
is that for example "hardlockup_enable() looks ugly.

Also some stuff is common for both softlockup and hardlockup
detectors. And some stuff will be common for both perf and
buddy hardlockup detectors.

Possible alternatives:

   a) watchdog_, watchdog_sl_ and watchdog_hl_, watchdog_hl_buddy_
   b) wd_, wd_hardlockup_, wd_softlockup_, wd_hardlockup_buddy_
   c) wd_, wd_hl_, wd_sl_, wd_hl_buddy_
   d_ wd_, wdhl_, wdsl_, wdhl_buddy_

If you want something shorter then c) looks the best to me.

The wd_ prefix seems to be already used in:

   + arch/powerpc/kernel/watchdog.c
   + kernel/time/clocksource.c

, but it is not used in the core watchdog code at all so it
would require renaming almost everything.


> probably best matches existing code and sysctl / boot stuff, and
> concentrate on non-static symbols.

Yeah, we could hardly change the sysctl interface visible to
userspace. But we could change at least the internal code.

And if we are changing the API anyway because of the
nmi/perf/buddy/hardlockup/hard mess then lets choose
something that will help to distinguish the common watchdog
vs. softlockup/hardlockup/buddy/perf-specific watchdog code.

And I would change it to the watchdog_hardlockup_ as it is
done in this patchset:

   + the names were mostly long even before
   + the code mostly stayed within the 80-chars per-line limit
   + the patches are ready


> No problem with minor things like this that touch arch/powerpc
> going through Andrew's tree though. I'm sure sparc maintainers
> wouldn't mind either.

Good to know.

Best Regards,
Petr

Re: [PATCH v8 0/7] Add pci_dev_for_each_resource() helper and update users

[Andy Shevchenko]

On Tue, May 09, 2023 at 01:21:22PM -0500, Bjorn Helgaas wrote:
> On Tue, Apr 04, 2023 at 11:11:01AM -0500, Bjorn Helgaas wrote:
> > On Thu, Mar 30, 2023 at 07:24:27PM +0300, Andy Shevchenko wrote:
> > > Provide two new helper macros to iterate over PCI device resources and
> > > convert users.
> 
> > Applied 2-7 to pci/resource for v6.4, thanks, I really like this!
> 
> This is 09cc90063240 ("PCI: Introduce pci_dev_for_each_resource()")
> upstream now.
> 
> Coverity complains about each use,

It needs more clarification here. Use of reduced variant of the macro or all of
them? If the former one, then I can speculate that Coverity (famous for false
positives) simply doesn't understand `for (type var; var ...)` code.

>   sample below from
> drivers/pci/vgaarb.c.  I didn't investigate at all, so it might be a
> false positive; just FYI.
> 
> 1. Condition screen_info.capabilities & (2U /* 1 << 1 */), taking 
> true branch.
>   556if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
>   557base |= (u64)screen_info.ext_lfb_base << 32;
>   558
>   559limit = base + size;
>   560
>   561/* Does firmware framebuffer belong to us? */
> 2. Condition __b < PCI_NUM_RESOURCES, taking true branch.
> 3. Condition (r = >resource[__b]) , (__b < PCI_NUM_RESOURCES), 
> taking true branch.
> 6. Condition __b < PCI_NUM_RESOURCES, taking true branch.
> 7. cond_at_most: Checking __b < PCI_NUM_RESOURCES implies that __b 
> may be up to 16 on the true branch.
> 8. Condition (r = >resource[__b]) , (__b < PCI_NUM_RESOURCES), 
> taking true branch.
> 11. incr: Incrementing __b. The value of __b may now be up to 17.
> 12. alias: Assigning: r = >resource[__b]. r may now point to as 
> high as element 17 of pdev->resource (which consists of 17 64-byte elements).
> 13. Condition __b < PCI_NUM_RESOURCES, taking true branch.
> 14. Condition (r = >resource[__b]) , (__b < PCI_NUM_RESOURCES), 
> taking true branch.
>   562pci_dev_for_each_resource(pdev, r) {
> 4. Condition resource_type(r) != 512, taking true branch.
> 9. Condition resource_type(r) != 512, taking true branch.
> 
>   CID 1529911 (#1 of 1): Out-of-bounds read (OVERRUN)
>   15. overrun-local: Overrunning array of 1088 bytes at byte offset 1088 by 
> dereferencing pointer r. [show details]
>   563if (resource_type(r) != IORESOURCE_MEM)
> 5. Continuing loop.
> 10. Continuing loop.
>   564continue;

-- 
With Best Regards,
Andy Shevchenko

Re: Fwd: Linux 6.3.1 + AMD RX 570 on ppc64le 4K: Kernel attempted to read user page (1128) - exploit attempt? (uid: 0)

[Bagas Sanjaya]

On 5/11/23 15:06, Bagas Sanjaya wrote:
> Hi,
> 
> I notice a regression report on bugzilla ([1]). As many developers
> don't keep an eye on it, I decide to forward it by email.
> 
> Quoting from it:
> 
>>  darkbasic 2023-05-10 13:36:37 UTC
>>
>> I'm using Gentoo Linux on a Raptor CS Talos 2 ppc64le, GPU is an AMD RX 570. 
>> So far the past dozen of kernels (up to 6.2.14) worked flawlessly, but with 
>> 6.3.1 I don't get any video output and I get the following in journalctl:
>>
>> May 10 15:09:01 talos2 kernel: Kernel attempted to read user page (1128) - 
>> exploit attempt? (uid: 0)
>> May 10 15:09:01 talos2 kernel: BUG: Unable to handle kernel data access on 
>> read at 0x1128
>> May 10 15:09:01 talos2 kernel: Faulting instruction address: 
>> 0xc0080d1a805c
>> May 10 15:09:01 talos2 kernel: Oops: Kernel access of bad area, sig: 11 [#1]
>> May 10 15:09:01 talos2 kernel: LE PAGE_SIZE=4K MMU=Radix SMP NR_CPUS=512 
>> NUMA PowerNV
>> May 10 15:09:01 talos2 kernel: Modules linked in: rfkill(+) 8021q garp mrp 
>> stp llc binfmt_misc amdgpu uvcvideo uvc videobuf2_vmalloc videobuf2_memops 
>> gpu_sched snd_hda_codec_hdmi i2c_algo_bit at24(+) videobuf2_v4l2 
>> drm_ttm_helper regmap_i2c videobuf2_common ttm snd_usb_audio drm_di>
>> May 10 15:09:01 talos2 kernel: CPU: 0 PID: 188 Comm: kworker/0:3 Not tainted 
>> 6.3.1-gentoo-dist #1
>> May 10 15:09:01 talos2 kernel: Hardware name: T2P9S01 REV 1.01 POWER9 
>> 0x4e1202 opal:skiboot-9858186 PowerNV
>> May 10 15:09:01 talos2 kernel: Workqueue: events_long 
>> drm_dp_check_and_send_link_address [drm_display_helper]
>> May 10 15:09:01 talos2 kernel: NIP:  c0080d1a805c LR: c0080d1a8018 
>> CTR: c0c87900
>> May 10 15:09:01 talos2 kernel: REGS: cbeb3370 TRAP: 0300   Not 
>> tainted  (6.3.1-gentoo-dist)
>> May 10 15:09:01 talos2 kernel: MSR:  9280b033 
>>   CR: 88048223  XER: 005a
>> May 10 15:09:01 talos2 kernel: CFAR: c0c87980 DAR: 1128 
>> DSISR: 4000 IRQMASK: 0 
>>GPR00: c0080d1a8018 cbeb3610 
>> c0080d690f00  
>>GPR04: 0002 c0080d6297c0 
>>  c0002a00b740 
>>GPR08:  1124 
>>  c0080d431560 
>>GPR12: c0c87900 c2a6b000 
>> c0170ad8 c0001a460310 
>>GPR16: 0045 c00022858388 
>> c00026000340 0001 
>>GPR20:  0001 
>> c000260001a0 4000 
>>GPR24: 4000 c0002610 
>> c000228580b8 fffd 
>>GPR28:  c000228580a0 
>> c00022856000 c00022858000 
>> May 10 15:09:01 talos2 kernel: NIP [c0080d1a805c] 
>> is_synaptics_cascaded_panamera+0x244/0x600 [amdgpu]
>> May 10 15:09:01 talos2 kernel: LR [c0080d1a8018] 
>> is_synaptics_cascaded_panamera+0x200/0x600 [amdgpu]
>> May 10 15:09:01 talos2 kernel: Call Trace:
>> May 10 15:09:01 talos2 kernel: [cbeb3610] [c0080d1a8018] 
>> is_synaptics_cascaded_panamera+0x200/0x600 [amdgpu] (unreliable)
>> May 10 15:09:01 talos2 kernel: [cbeb36d0] [c0080b7c2b18] 
>> drm_helper_probe_single_connector_modes+0x230/0x698 [drm_kms_helper]
>> May 10 15:09:01 talos2 kernel: [cbeb3810] [c0c57174] 
>> drm_client_modeset_probe+0x2b4/0x16c0
>> May 10 15:09:01 talos2 kernel: [cbeb3a10] [c0080b7c7a30] 
>> __drm_fb_helper_initial_config_and_unlock+0x68/0x640 [drm_kms_helper]
>> May 10 15:09:01 talos2 kernel: [cbeb3af0] [c0080b7c5b08] 
>> drm_fbdev_client_hotplug+0x40/0x1d0 [drm_kms_helper]
>> May 10 15:09:01 talos2 kernel: [cbeb3b70] [c0c55480] 
>> drm_client_dev_hotplug+0x120/0x1b0
>> May 10 15:09:01 talos2 kernel: [cbeb3c00] [c0080b7c1130] 
>> drm_kms_helper_hotplug_event+0x58/0x80 [drm_kms_helper]
>> May 10 15:09:01 talos2 kernel: [cbeb3c30] [c0080b80b298] 
>> drm_dp_check_and_send_link_address+0x330/0x3a0 [drm_display_helper]
>> May 10 15:09:01 talos2 kernel: [cbeb3cd0] [c0162d84] 
>> process_one_work+0x2f4/0x580
>> May 10 15:09:01 talos2 kernel: [cbeb3d70] [c01630b8] 
>> worker_thread+0xa8/0x600
>> May 10 15:09:01 talos2 kernel: [cbeb3e00] [c0170bf4] 
>> kthread+0x124/0x130
>> May 10 15:09:01 talos2 kernel: [cbeb3e50] [c000dd14] 
>> ret_from_kernel_thread+0x5c/0x64
>> May 10 15:09:01 talos2 kernel: --- interrupt: 0 at 0x0
>> May 10 15:09:01 talos2 kernel: NIP:   LR:  
>> CTR: 
>> May 10 15:09:01 talos2 kernel: REGS: cbeb3e80 TRAP:    Not 
>> tainted  (6.3.1-gentoo-dist)
>> May 10 15:09:01 talos2 kernel: MSR:   <>  CR: