* Re: [PATCH] powerpc/bpf: fix write protecting JIT code
From: Michael Ellerman @ 2021-11-02 10:12 UTC (permalink / raw)
To: jniethe5, christophe.leroy, Hari Bathini, naveen.n.rao, daniel,
ast, mpe
Cc: songliubraving, netdev, john.fastabend, kpsingh, stable, andrii,
paulus, yhs, bpf, linuxppc-dev, kafai
In-Reply-To: <20211025055649.114728-1-hbathini@linux.ibm.com>
On Mon, 25 Oct 2021 11:26:49 +0530, Hari Bathini wrote:
> Running program with bpf-to-bpf function calls results in data access
> exception (0x300) with the below call trace:
>
> [c000000000113f28] bpf_int_jit_compile+0x238/0x750 (unreliable)
> [c00000000037d2f8] bpf_check+0x2008/0x2710
> [c000000000360050] bpf_prog_load+0xb00/0x13a0
> [c000000000361d94] __sys_bpf+0x6f4/0x27c0
> [c000000000363f0c] sys_bpf+0x2c/0x40
> [c000000000032434] system_call_exception+0x164/0x330
> [c00000000000c1e8] system_call_vectored_common+0xe8/0x278
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/bpf: fix write protecting JIT code
https://git.kernel.org/powerpc/c/44a8214de96bafb5210e43bfa2c97c19bf75af3d
cheers
^ permalink raw reply
* Re: [PATCH][next] powerpc/vas: Fix potential NULL pointer dereference
From: Michael Ellerman @ 2021-11-02 10:11 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Haren Myneni, Nicholas Piggin,
Gustavo A. R. Silva, Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel, linux-hardening
In-Reply-To: <20211015050345.GA1161918@embeddedor>
On Fri, 15 Oct 2021 00:03:45 -0500, Gustavo A. R. Silva wrote:
> (!ptr && !ptr->foo) strikes again. :)
>
> The expression (!ptr && !ptr->foo) is bogus and in case ptr is NULL,
> it leads to a NULL pointer dereference: ptr->foo.
>
> Fix this by converting && to ||
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/vas: Fix potential NULL pointer dereference
https://git.kernel.org/powerpc/c/61cb9ac66b30374c7fd8a8b2a3c4f8f432c72e36
cheers
^ permalink raw reply
* Re: [PATCH -next] powerpc/44x/fsp2: add missing of_node_put
From: Michael Ellerman @ 2021-11-02 10:12 UTC (permalink / raw)
To: Bixuan Cui, linux-kernel, linuxppc-dev; +Cc: ivan, paulus
In-Reply-To: <1635406102-88719-1-git-send-email-cuibixuan@linux.alibaba.com>
On Thu, 28 Oct 2021 15:28:22 +0800, Bixuan Cui wrote:
> Early exits from for_each_compatible_node() should decrement the
> node reference counter. Reported by Coccinelle:
>
> ./arch/powerpc/platforms/44x/fsp2.c:206:1-25: WARNING: Function
> "for_each_compatible_node" should have of_node_put() before return
> around line 218.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/44x/fsp2: add missing of_node_put
https://git.kernel.org/powerpc/c/290fe8aa69ef5c51c778c0bb33f8ef0181c769f5
cheers
^ permalink raw reply
* Re: [PATCH v3] powerpc/boot: Set LC_ALL=C in wrapper script
From: Michael Ellerman @ 2021-11-02 10:11 UTC (permalink / raw)
To: Paul Mackerras, Michael Ellerman, Christophe Leroy,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <a9ff3bc98035f63b122c051f02dc47c7aed10430.1635256089.git.christophe.leroy@csgroup.eu>
On Tue, 26 Oct 2021 15:48:29 +0200, Christophe Leroy wrote:
> While trying to build a simple Image for ACADIA platform, I got the
> following error:
>
> WRAP arch/powerpc/boot/simpleImage.acadia
> INFO: Uncompressed kernel (size 0x6ae7d0) overlaps the address of the wrapper(0x400000)
> INFO: Fixing the link_address of wrapper to (0x700000)
> powerpc64-linux-gnu-ld : mode d'émulation non reconnu : -T
> Émulations prises en charge : elf64ppc elf32ppc elf32ppclinux elf32ppcsim elf64lppc elf32lppc elf32lppclinux elf32lppcsim
> make[1]: *** [arch/powerpc/boot/Makefile:424 : arch/powerpc/boot/simpleImage.acadia] Erreur 1
> make: *** [arch/powerpc/Makefile:285 : simpleImage.acadia] Erreur 2
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/boot: Set LC_ALL=C in wrapper script
https://git.kernel.org/powerpc/c/b949d009dd52ecdced248889cf11297677f9e8a6
cheers
^ permalink raw reply
* Re: [PATCH v3] powerpc/32: Add support for out-of-line static calls
From: Michael Ellerman @ 2021-11-02 10:11 UTC (permalink / raw)
To: Paul Mackerras, Michael Ellerman, Christophe Leroy,
Benjamin Herrenschmidt
Cc: Peter Zijlstra, linux-kernel, Steven Rostedt, Jason Baron,
Josh Poimboeuf, linuxppc-dev, Ard Biesheuvel
In-Reply-To: <6ec2a7865ed6a5ec54ab46d026785bafe1d837ea.1630484892.git.christophe.leroy@csgroup.eu>
On Wed, 1 Sep 2021 08:30:21 +0000 (UTC), Christophe Leroy wrote:
> Add support for out-of-line static calls on PPC32. This change
> improve performance of calls to global function pointers by
> using direct calls instead of indirect calls.
>
> The trampoline is initialy populated with a 'blr' or branch to target,
> followed by an unreachable long jump sequence.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/32: Add support for out-of-line static calls
https://git.kernel.org/powerpc/c/5c810ced36ae1a8f1a7403c1635b0dc07c115086
cheers
^ permalink raw reply
* Re: [PATCH v2 RESEND] powerpc/audit: Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC
From: Michael Ellerman @ 2021-11-02 10:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Christophe Leroy,
Michael Ellerman
Cc: linux-audit, linuxppc-dev, linux-kernel, Eric Paris, Paul Moore
In-Reply-To: <a4b3951d1191d4183d92a07a6097566bde60d00a.1629812058.git.christophe.leroy@csgroup.eu>
On Tue, 24 Aug 2021 13:36:13 +0000 (UTC), Christophe Leroy wrote:
> Commit e65e1fc2d24b ("[PATCH] syscall class hookup for all normal
> targets") added generic support for AUDIT but that didn't include
> support for bi-arch like powerpc.
>
> Commit 4b58841149dc ("audit: Add generic compat syscall support")
> added generic support for bi-arch.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/audit: Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC
https://git.kernel.org/powerpc/c/566af8cda399c088763d07464463dc871c943b54
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc: warn on emulation of dcbz instruction in kernel mode
From: Michael Ellerman @ 2021-11-02 10:11 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Christophe Leroy,
Benjamin Herrenschmidt
Cc: linuxppc-dev, Stan Johnson, Finn Thain, linux-kernel
In-Reply-To: <2e3acfe63d289c6fba366e16973c9ab8369e8b75.1631803922.git.christophe.leroy@csgroup.eu>
On Thu, 16 Sep 2021 16:52:09 +0200, Christophe Leroy wrote:
> dcbz instruction shouldn't be used on non-cached memory. Using
> it on non-cached memory can result in alignment exception and
> implies a heavy handling.
>
> Instead of silentely emulating the instruction and resulting in high
> performance degradation, warn whenever an alignment exception is
> taken in kernel mode due to dcbz, so that the user is made aware that
> dcbz instruction has been used unexpectedly by the kernel.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: warn on emulation of dcbz instruction in kernel mode
https://git.kernel.org/powerpc/c/cbe654c779616807e1e6823c3bdbfe07a10562b8
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/8xx: Simplify TLB handling
From: Michael Ellerman @ 2021-11-02 10:11 UTC (permalink / raw)
To: Paul Mackerras, Michael Ellerman, Christophe Leroy,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <fb324f1c8f2ddb57cf6aad1cea26329558f1c1c0.1631887021.git.christophe.leroy@csgroup.eu>
On Fri, 17 Sep 2021 15:57:12 +0200, Christophe Leroy wrote:
> In the old days, TLB handling for 8xx was using tlbie and tlbia
> instructions directly as much as possible.
>
> But commit f048aace29e0 ("powerpc/mm: Add SMP support to no-hash
> TLB handling") broke that by introducing out-of-line unnecessary
> complex functions for booke/smp which don't have tlbie/tlbia
> instructions and require more complex handling.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/8xx: Simplify TLB handling
https://git.kernel.org/powerpc/c/63f501e07a8557bc8ab79d17ef76ae21df1e395d
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/32: Don't use a struct based type for pte_t
From: Michael Ellerman @ 2021-11-02 10:11 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Christophe Leroy,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <c904599f33aaf6bb7ee2836a9ff8368509e0d78d.1631887042.git.christophe.leroy@csgroup.eu>
On Fri, 17 Sep 2021 15:57:31 +0200, Christophe Leroy wrote:
> Long time ago we had a config item called STRICT_MM_TYPECHECKS
> to build the kernel with pte_t defined as a structure in order
> to perform additional build checks or build it with pte_t
> defined as a simple type in order to get simpler generated code.
>
> Commit 670eea924198 ("powerpc/mm: Always use STRICT_MM_TYPECHECKS")
> made the struct based definition the only one, considering that the
> generated code was similar in both cases.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/32: Don't use a struct based type for pte_t
https://git.kernel.org/powerpc/c/c7d19189d7241e135cd2e450a7fbc77cb7bd40ee
cheers
^ permalink raw reply
* Re: [PATCH v1 1/8] powerpc/booke: Disable STRICT_KERNEL_RWX, DEBUG_PAGEALLOC and KFENCE
From: Michael Ellerman @ 2021-11-02 10:11 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Christophe Leroy,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <d1ad9fdd9b27da3fdfa16510bb542ed51fa6e134.1634292136.git.christophe.leroy@csgroup.eu>
On Fri, 15 Oct 2021 12:02:42 +0200, Christophe Leroy wrote:
> fsl_booke and 44x are not able to map kernel linear memory with
> pages, so they can't support DEBUG_PAGEALLOC and KFENCE, and
> STRICT_KERNEL_RWX is also a problem for now.
>
> Enable those only on book3s (both 32 and 64 except KFENCE), 8xx and 40x.
>
>
> [...]
Applied to powerpc/next.
[1/8] powerpc/booke: Disable STRICT_KERNEL_RWX, DEBUG_PAGEALLOC and KFENCE
https://git.kernel.org/powerpc/c/68b44f94d6370e2c6c790fedd28e637fa9964a93
[2/8] powerpc/fsl_booke: Rename fsl_booke.c to fsl_book3e.c
https://git.kernel.org/powerpc/c/3a75fd709c89cb45b8b1044b8ef0d15027a69f9b
[3/8] powerpc/fsl_booke: Take exec flag into account when setting TLBCAMs
https://git.kernel.org/powerpc/c/01116e6e98b08ab0641fa516ddafb1b1b2088e64
[4/8] powerpc/fsl_booke: Enable reloading of TLBCAM without switching to AS1
https://git.kernel.org/powerpc/c/a97dd9e2f760c6996a8f1385ddab0bfef325b364
[5/8] powerpc/fsl_booke: Tell map_mem_in_cams() if init is done
https://git.kernel.org/powerpc/c/52bda69ae8b5102fe08c9db10f4a1514478e07d3
[6/8] powerpc/fsl_booke: Allocate separate TLBCAMs for readonly memory
https://git.kernel.org/powerpc/c/0b2859a74306b2b89f6e77c216fe0992ff890fa6
[7/8] powerpc/fsl_booke: Update of TLBCAMs after init
https://git.kernel.org/powerpc/c/d5970045cf9e266d9a43941ac0866865fd22a36a
[8/8] powerpc/fsl_booke: Enable STRICT_KERNEL_RWX
https://git.kernel.org/powerpc/c/49e3d8ea62482625c3835f0a33ae9c1dda39ea8f
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/time: Remove generic_suspend_{dis/en}able_irqs()
From: Michael Ellerman @ 2021-11-02 10:11 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Christophe Leroy,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <c3f9ec9950394ef939014f7934268e6ee30ca04f.1630398566.git.christophe.leroy@csgroup.eu>
On Tue, 31 Aug 2021 08:29:35 +0000 (UTC), Christophe Leroy wrote:
> Commit d75d68cfef49 ("powerpc: Clean up obsolete code relating to
> decrementer and timebase") made generic_suspend_enable_irqs() and
> generic_suspend_disable_irqs() static.
>
> Fold them into their only caller.
>
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/time: Remove generic_suspend_{dis/en}able_irqs()
https://git.kernel.org/powerpc/c/e606a2f46c72ec399bb9be194f6df95ea8ec3b1b
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: Mark .opd section read-only
From: Michael Ellerman @ 2021-11-02 10:11 UTC (permalink / raw)
To: Paul Mackerras, Michael Ellerman, Christophe Leroy,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <3cd40b682fb6f75bb40947b55ca0bac20cb3f995.1634136222.git.christophe.leroy@csgroup.eu>
On Wed, 13 Oct 2021 16:43:54 +0200, Christophe Leroy wrote:
> .opd section contains function descriptors used to locate
> functions in the kernel. If someone is able to modify a
> function descriptor he will be able to run arbitrary
> kernel function instead of another.
>
> To avoid that, move .opd section inside read-only memory.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: Mark .opd section read-only
https://git.kernel.org/powerpc/c/3091f5fc5f1df7741ddf326561384e0997eca2a1
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/machdep: Remove stale functions from ppc_md structure
From: Michael Ellerman @ 2021-11-02 10:11 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Christophe Leroy,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <24d4ca0ada683c9436a5f812a7aeb0a1362afa2b.1630398606.git.christophe.leroy@csgroup.eu>
On Tue, 31 Aug 2021 08:30:24 +0000 (UTC), Christophe Leroy wrote:
> ppc_md.iommu_save() is not set anymore by any platform after
> commit c40785ad305b ("powerpc/dart: Use a cachable DART").
> So iommu_save() has become a nop and can be removed.
>
> ppc_md.show_percpuinfo() is not set anymore by any platform after
> commit 4350147a816b ("[PATCH] ppc64: SMU based macs cpufreq support").
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/machdep: Remove stale functions from ppc_md structure
https://git.kernel.org/powerpc/c/8f7fadb4ba87f6639d817a9b2d99112e9507dc63
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/lib/sstep: Don't use __{get/put}_user() on kernel addresses
From: Michael Ellerman @ 2021-11-02 10:11 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Christophe Leroy,
Benjamin Herrenschmidt
Cc: linuxppc-dev, Stan Johnson, Finn Thain, linux-kernel
In-Reply-To: <22831c9d17f948680a12c5292e7627288b15f713.1631817805.git.christophe.leroy@csgroup.eu>
On Thu, 16 Sep 2021 20:43:36 +0200, Christophe Leroy wrote:
> In the old days, when we didn't have kernel userspace access
> protection and had set_fs(), it was wise to use __get_user()
> and friends to read kernel memory.
>
> Nowadays, get_user() and put_user() are granting userspace access and
> are exclusively for userspace access.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/lib/sstep: Don't use __{get/put}_user() on kernel addresses
https://git.kernel.org/powerpc/c/e28d0b675056d072f1f11fa644d0efbb016bb7ce
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: Don't provide __kernel_map_pages() without ARCH_SUPPORTS_DEBUG_PAGEALLOC
From: Michael Ellerman @ 2021-11-02 10:12 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Christophe Leroy,
Benjamin Herrenschmidt
Cc: linuxppc-dev, kernel test robot, linux-kernel
In-Reply-To: <971b69739ff4746252e711a9845210465c023a9e.1635425947.git.christophe.leroy@csgroup.eu>
On Thu, 28 Oct 2021 14:59:15 +0200, Christophe Leroy wrote:
> When ARCH_SUPPORTS_DEBUG_PAGEALLOC is not selected, the user can
> still select CONFIG_DEBUG_PAGEALLOC in which case __kernel_map_pages()
> is provided by mm/page_poison.c
>
> So only define __kernel_map_pages() when both
> CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC and CONFIG_DEBUG_PAGEALLOC
> are defined.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: Don't provide __kernel_map_pages() without ARCH_SUPPORTS_DEBUG_PAGEALLOC
https://git.kernel.org/powerpc/c/f8c0e36b48e32b14bb83332d24e0646acd31d9e9
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/breakpoint: Cleanup
From: Michael Ellerman @ 2021-11-02 10:11 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Christophe Leroy,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <6184b08088312a7d787d450eb902584e4ae77f7a.1632317816.git.christophe.leroy@csgroup.eu>
On Wed, 22 Sep 2021 15:37:18 +0200, Christophe Leroy wrote:
> cache_op_size() does exactly the same as l1_dcache_bytes().
>
> Remove it.
>
> MSR_64BIT already exists, no need to enclode the check
> around #ifdef __powerpc64__
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/breakpoint: Cleanup
https://git.kernel.org/powerpc/c/a61ec782a754229b24aae2d6c2109510d6420ae6
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: Activate CONFIG_STRICT_KERNEL_RWX by default
From: Michael Ellerman @ 2021-11-02 10:11 UTC (permalink / raw)
To: Paul Mackerras, Michael Ellerman, Christophe Leroy,
Benjamin Herrenschmidt
Cc: linuxppc-dev, Kees Cook, linux-kernel
In-Reply-To: <057c40164084bfc7d77c0b2ff78d95dbf6a2a21b.1632503622.git.christophe.leroy@csgroup.eu>
On Fri, 24 Sep 2021 19:13:53 +0200, Christophe Leroy wrote:
> CONFIG_STRICT_KERNEL_RWX should be set by default on every
> architectures (See https://github.com/KSPP/linux/issues/4)
>
> On PPC32 we have to find a compromise between performance and/or
> memory wasting and selection of strict_kernel_rwx, because it implies
> either smaller memory chunks or larger alignment between RO memory
> and RW memory.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: Activate CONFIG_STRICT_KERNEL_RWX by default
https://git.kernel.org/powerpc/c/fdacae8a84024474afff234bdd1dbe19ad597a10
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/32: Don't use lmw/stmw for saving/restoring non volatile regs
From: Michael Ellerman @ 2021-11-02 10:11 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Christophe Leroy,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <316c543b8906712c108985c8463eec09c8db577b.1629732542.git.christophe.leroy@csgroup.eu>
On Mon, 23 Aug 2021 15:29:12 +0000 (UTC), Christophe Leroy wrote:
> Instructions lmw/stmw are interesting for functions that are rarely
> used and not in the cache, because only one instruction is to be
> copied into the instruction cache instead of 19. However those
> instruction are less performant than 19x raw lwz/stw as they require
> synchronisation plus one additional cycle.
>
> SAVE_NVGPRS / REST_NVGPRS are used in only a few places which are
> mostly in interrupts entries/exits and in task switch so they are
> likely already in the cache.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/32: Don't use lmw/stmw for saving/restoring non volatile regs
https://git.kernel.org/powerpc/c/a85c728cb5e12216c19ae5878980c2cbbbf8616d
cheers
^ permalink raw reply
* Re: [PATCH 0/4] Update mpc5200 dts files to fix warnings
From: Michael Ellerman @ 2021-11-02 10:11 UTC (permalink / raw)
To: Anatolij Gustschin, linuxppc-dev
Cc: devicetree, Stephen Rothwell, linux-kernel, Rob Herring,
Paul Mackerras
In-Reply-To: <20211013220532.24759-1-agust@denx.de>
On Thu, 14 Oct 2021 00:05:28 +0200, Anatolij Gustschin wrote:
> This series fixes localbus, memory and pci node build warnings.
> It was tested with current linux-next on digsy_mtc and tqm5200
> boards.
>
> Anatolij Gustschin (4):
> powerpc/5200: dts: add missing pci ranges
> powerpc/5200: dts: fix pci ranges warnings
> powerpc/5200: dts: fix memory node unit name
> powerpc/5200: dts: fix localbus node warnings
>
> [...]
Patches 1-3 applied to powerpc/next.
[1/4] powerpc/5200: dts: add missing pci ranges
https://git.kernel.org/powerpc/c/e9efabc6e4c31517394be13c2f0c5abadd33f328
[2/4] powerpc/5200: dts: fix pci ranges warnings
https://git.kernel.org/powerpc/c/7855b6c66dc458e2f5abfb2b50f527ea4101df77
[3/4] powerpc/5200: dts: fix memory node unit name
https://git.kernel.org/powerpc/c/aed2886a5e9ffc8269a4220bff1e9e030d3d2eb1
cheers
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/nohash: Fix __ptep_set_access_flags() and ptep_set_wrprotect()
From: Michael Ellerman @ 2021-11-02 10:11 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Christophe Leroy,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <922bdab3a220781bae2360ff3dd5adb7fe4d34f1.1635226743.git.christophe.leroy@csgroup.eu>
On Tue, 26 Oct 2021 07:39:24 +0200, Christophe Leroy wrote:
> Commit 26973fa5ac0e ("powerpc/mm: use pte helpers in generic code")
> changed those two functions to use pte helpers to determine which
> bits to clear and which bits to set.
>
> This change was based on the assumption that bits to be set/cleared
> are always the same and can be determined by applying the pte
> manipulation helpers on __pte(0).
>
> [...]
Applied to powerpc/next.
[1/3] powerpc/nohash: Fix __ptep_set_access_flags() and ptep_set_wrprotect()
https://git.kernel.org/powerpc/c/b1b93cb7e794e914787bf7d9936b57a149cdee4f
[2/3] powerpc/book3e: Fix set_memory_x() and set_memory_nx()
https://git.kernel.org/powerpc/c/b6cb20fdc2735f8b2e082937066c33fe376c2ee2
[3/3] powerpc/fsl_booke: Fix setting of exec flag when setting TLBCAMs
https://git.kernel.org/powerpc/c/44c14509b0dabb909ad1ec28800893ea71762732
cheers
^ permalink raw reply
* Re: [V3] powerpc/perf: Enable PMU counters post partition migration if PMU is active
From: Nicholas Piggin @ 2021-11-02 11:35 UTC (permalink / raw)
To: Athira Rajeev, Michael Ellerman
Cc: nathanl, kjain, maddy, linuxppc-dev, rnsastry
In-Reply-To: <87sfwk7z0m.fsf@mpe.ellerman.id.au>
Excerpts from Michael Ellerman's message of October 29, 2021 11:15 pm:
> Nicholas Piggin <npiggin@gmail.com> writes:
>> Excerpts from Athira Rajeev's message of October 29, 2021 1:05 pm:
>>> @@ -631,12 +632,18 @@ static int pseries_migrate_partition(u64 handle)
>>> if (ret)
>>> return ret;
>>>
>>> + /* Disable PMU before suspend */
>>> + on_each_cpu(&mobility_pmu_disable, NULL, 0);
>>
>> Why was this moved out of stop machine and to an IPI?
>>
>> My concern would be, what are the other CPUs doing at this time? Is it
>> possible they could take interrupts and schedule? Could that mess up the
>> perf state here?
>
> pseries_migrate_partition() is called directly from migration_store(),
> which is the sysfs store function, which can be called concurrently by
> different CPUs.
>
> It's also potentially called from rtas_syscall_dispatch_ibm_suspend_me(),
> from sys_rtas(), again with no locking.
>
> So we could have two CPUs calling into here at the same time, which
> might not crash, but is unlikely to work well.
>
> I think the lack of locking might have been OK in the past because only
> one CPU will successfully get the other CPUs to call do_join() in
> pseries_suspend(). But I could be wrong.
>
> Anyway, now that we're mutating the PMU state before suspending we need
> to be more careful. So I think we need a lock around the whole sequence.
My concern is still that we wouldn't necessarily have the other CPUs
under control at that point even if we serialize the migrate path.
They could take interrupts, possibly call into perf subsystem after
the mobility_pmu_disable (e.g., via syscall or context switch) which
might mess things up.
I think the stop machine is a reasonable place for the code in this
case. It's a low level disabling of hardware facility and saving off
registers.
Thanks,
Nick
^ permalink raw reply
* Re: [V3] powerpc/perf: Enable PMU counters post partition migration if PMU is active
From: Athira Rajeev @ 2021-11-02 6:13 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: Nathan Lynch, maddy, rnsastry, kjain, linuxppc-dev
In-Reply-To: <1635487923.hwdpof7s4v.astroid@bobo.none>
[-- Attachment #1: Type: text/plain, Size: 8090 bytes --]
> On 29-Oct-2021, at 11:46 AM, Nicholas Piggin <npiggin@gmail.com> wrote:
>
> Excerpts from Athira Rajeev's message of October 29, 2021 1:05 pm:
>> During Live Partition Migration (LPM), it is observed that perf
>> counter values reports zero post migration completion. However
>> 'perf stat' with workload continues to show counts post migration
>> since PMU gets disabled/enabled during sched switches. But incase
>> of system/cpu wide monitoring, zero counts were reported with 'perf
>> stat' after migration completion.
>>
>> Example:
>> ./perf stat -e r1001e -I 1000
>> time counts unit events
>> 1.001010437 22,137,414 r1001e
>> 2.002495447 15,455,821 r1001e
>> <<>> As seen in next below logs, the counter values shows zero
>> after migration is completed.
>> <<>>
>> 86.142535370 129,392,333,440 r1001e
>> 87.144714617 0 r1001e
>> 88.146526636 0 r1001e
>> 89.148085029 0 r1001e
>
> This is the output without the patch? After the patch it keeps counting
> I suppose? And does the very large count go away too?
Hi Nick,
Thanks for the review comments.
The output is without the patch. After the patch it keeps counting and negative count goes away.
My bad, missed to keep both results in present version. I will add the before and after patch results in next version.
>
>>
>> Here PMU is enabled during start of perf session and counter
>> values are read at intervals. Counters are only disabled at the
>> end of session. The powerpc mobility code presently does not handle
>> disabling and enabling back of PMU counters during partition
>> migration. Also since the PMU register values are not saved/restored
>> during migration, PMU registers like Monitor Mode Control Register 0
>> (MMCR0), Monitor Mode Control Register 1 (MMCR1) will not contain
>> the value it was programmed with. Hence PMU counters will not be
>> enabled correctly post migration.
>>
>> Fix this in mobility code by handling disabling and enabling of
>> PMU in all cpu's before and after migration. Patch introduces two
>> functions 'mobility_pmu_disable' and 'mobility_pmu_enable'.
>> mobility_pmu_disable() is called before the processor threads goes
>> to suspend state so as to disable the PMU counters. And disable is
>> done only if there are any active events running on that cpu.
>> mobility_pmu_enable() is called after the migrate is done to enable
>> back the PMU counters.
>>
>> Since the performance Monitor counters ( PMCs) are not
>> saved/restored during LPM, results in PMC value being zero and the
>> 'event->hw.prev_count' being non-zero value. This causes problem
>> during updation of event->count since we always accumulate
>> (event->hw.prev_count - PMC value) in event->count. If
>> event->hw.prev_count is greater PMC value, event->count becomes
>> negative. To fix this, 'prev_count' also needs to be re-initialised
>> for all events while enabling back the events. Hence read the
>> existing events and clear the PMC index (stored in event->hw.idx)
>> for all events im mobility_pmu_disable. By this way, event count
>> settings will get re-initialised correctly in power_pmu_enable.
>>
>> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
>> [ Fixed compilation error reported by kernel test robot ]
>> Reported-by: kernel test robot <lkp@intel.com>
>> ---
>> Changelog:
>> Change from v2 -> v3:
>> Addressed review comments from Nicholas Piggin.
>> - Removed the "migrate" field which was added in initial
>> patch to address updation of event count settings correctly
>> in power_pmu_enable. Instead read off existing events in
>> mobility_pmu_disable before power_pmu_enable.
>> - Moved the mobility_pmu_disable/enable declaration from
>> rtas.h to perf event header file.
>>
>> Addressed review comments from Nathan.
>> - Moved the mobility function calls from stop_machine
>> context out to pseries_migrate_partition. Also now this
>> is a per cpu invocation.
>>
>> Change from v1 -> v2:
>> - Moved the mobility_pmu_enable and mobility_pmu_disable
>> declarations under CONFIG_PPC_PERF_CTRS in rtas.h.
>> Also included 'asm/rtas.h' in core-book3s to fix the
>> compilation warning reported by kernel test robot.
>>
>> arch/powerpc/include/asm/perf_event.h | 8 +++++
>> arch/powerpc/perf/core-book3s.c | 39 +++++++++++++++++++++++
>> arch/powerpc/platforms/pseries/mobility.c | 7 ++++
>> 3 files changed, 54 insertions(+)
>>
>> diff --git a/arch/powerpc/include/asm/perf_event.h b/arch/powerpc/include/asm/perf_event.h
>> index 164e910bf654..88aab6cf840c 100644
>> --- a/arch/powerpc/include/asm/perf_event.h
>> +++ b/arch/powerpc/include/asm/perf_event.h
>> @@ -17,6 +17,14 @@ static inline bool is_sier_available(void) { return false; }
>> static inline unsigned long get_pmcs_ext_regs(int idx) { return 0; }
>> #endif
>>
>> +#ifdef CONFIG_PPC_PERF_CTRS
>> +void mobility_pmu_disable(void *unused);
>> +void mobility_pmu_enable(void *unused);
>> +#else
>> +static inline void mobility_pmu_disable(void *unused) { }
>> +static inline void mobility_pmu_enable(void *unused) { }
>> +#endif
>> +
>> #ifdef CONFIG_FSL_EMB_PERF_EVENT
>> #include <asm/perf_event_fsl_emb.h>
>> #endif
>> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
>> index 73e62e9b179b..2e8c4c668fa3 100644
>> --- a/arch/powerpc/perf/core-book3s.c
>> +++ b/arch/powerpc/perf/core-book3s.c
>> @@ -1343,6 +1343,33 @@ static void power_pmu_disable(struct pmu *pmu)
>> local_irq_restore(flags);
>> }
>>
>> +/*
>> + * Called from pseries_migrate_partition() function
>> + * before migration, from powerpc/mobility code.
>> + */
>> +void mobility_pmu_disable(void *unused)
>> +{
>> + struct cpu_hw_events *cpuhw = this_cpu_ptr(&cpu_hw_events);
>> + struct perf_event *event;
>> +
>> + if (cpuhw->n_events != 0) {
>> + int i;
>> +
>> + power_pmu_disable(NULL);
>> + /*
>> + * Read off any pre-existing events because the register
>> + * values may not be migrated.
>> + */
>> + for (i = 0; i < cpuhw->n_events; ++i) {
>> + event = cpuhw->event[i];
>> + if (event->hw.idx) {
>> + power_pmu_read(event);
>> + event->hw.idx = 0;
>> + }
>> + }
>> + }
>> +}
>> +
>> /*
>> * Re-enable all events if disable == 0.
>> * If we were previously disabled and events were added, then
>> @@ -1515,6 +1542,18 @@ static void power_pmu_enable(struct pmu *pmu)
>> local_irq_restore(flags);
>> }
>>
>> +/*
>> + * Called from pseries_migrate_partition() function
>> + * after migration, from powerpc/mobility code.
>> + */
>> +void mobility_pmu_enable(void *unused)
>> +{
>> + struct cpu_hw_events *cpuhw = this_cpu_ptr(&cpu_hw_events);
>> +
>> + cpuhw->n_added = cpuhw->n_events;
>> + power_pmu_enable(NULL);
>> +}
>> +
>> static int collect_events(struct perf_event *group, int max_count,
>> struct perf_event *ctrs[], u64 *events,
>> unsigned int *flags)
>> diff --git a/arch/powerpc/platforms/pseries/mobility.c b/arch/powerpc/platforms/pseries/mobility.c
>> index e83e0891272d..3e96485ccba4 100644
>> --- a/arch/powerpc/platforms/pseries/mobility.c
>> +++ b/arch/powerpc/platforms/pseries/mobility.c
>> @@ -22,6 +22,7 @@
>> #include <linux/delay.h>
>> #include <linux/slab.h>
>> #include <linux/stringify.h>
>> +#include <linux/perf_event.h>
>>
>> #include <asm/machdep.h>
>> #include <asm/rtas.h>
>> @@ -631,12 +632,18 @@ static int pseries_migrate_partition(u64 handle)
>> if (ret)
>> return ret;
>>
>> + /* Disable PMU before suspend */
>> + on_each_cpu(&mobility_pmu_disable, NULL, 0);
>
> Why was this moved out of stop machine and to an IPI?
>
> My concern would be, what are the other CPUs doing at this time? Is it
> possible they could take interrupts and schedule? Could that mess up the
> perf state here?
>
> Thanks,
> Nick
[-- Attachment #2: Type: text/html, Size: 23307 bytes --]
^ permalink raw reply
* [Bug 214913] [xfstests generic/051] BUG: Kernel NULL pointer dereference on read at 0x00000108 NIP [c0000000000372e4] tm_cgpr_active+0x14/0x40
From: bugzilla-daemon @ 2021-11-02 9:29 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-214913-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=214913
--- Comment #1 from Zorro Lang (zlang@redhat.com) ---
Created attachment 299403
--> https://bugzilla.kernel.org/attachment.cgi?id=299403&action=edit
.config file
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 214913] New: [xfstests generic/051] BUG: Kernel NULL pointer dereference on read at 0x00000108 NIP [c0000000000372e4] tm_cgpr_active+0x14/0x40
From: bugzilla-daemon @ 2021-11-02 9:27 UTC (permalink / raw)
To: linuxppc-dev
https://bugzilla.kernel.org/show_bug.cgi?id=214913
Bug ID: 214913
Summary: [xfstests generic/051] BUG: Kernel NULL pointer
dereference on read at 0x00000108 NIP
[c0000000000372e4] tm_cgpr_active+0x14/0x40
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: mainline linux v5.15
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: PPC-64
Assignee: platform_ppc-64@kernel-bugs.osdl.org
Reporter: zlang@redhat.com
Regression: No
xfstests generic/051 and some similar test cases always hit a kernel panic on
XFS.
From the call trace, it doesn't look like a xfs bug. As I only reproduce it on
ppc64le, so I report this bug to PPC64 at first.
[ 740.492561] run fstests generic/051 at 2021-11-01 12:40:42
[ 742.806962] XFS (sda3): Mounting V5 Filesystem
[ 742.925825] XFS (sda3): Ending clean mount
[ 742.955028] XFS (sda3): User initiated shutdown received.
[ 742.955201] XFS (sda3): Metadata I/O Error (0x4) detected at
xfs_fs_goingdown+0x68/0x160 [xfs] (fs/xfs/xfs_fsops.c:497). Shutting down
filesystem.
[ 742.955370] XFS (sda3): Please unmount the filesystem and rectify the
problem(s)
[ 742.973098] XFS (sda3): Unmounting Filesystem
[ 744.352066] XFS (sda3): Mounting V5 Filesystem
[ 744.425758] XFS (sda3): Ending clean mount
[ 775.192100] XFS (sda3): Unmounting Filesystem
[ 776.116445] XFS (sda3): Mounting V5 Filesystem
[ 777.331381] XFS (sda3): Ending clean mount
[ 800.111560] restraintd[1327]: *** Current Time: Mon Nov 01 12:41:42 2021
Localwatchdog at: Wed Nov 03 12:31:42 2021
[ 813.403287] XFS (sda3): User initiated shutdown received.
[ 813.403380] XFS (sda3): Log I/O Error (0x6) detected at
xfs_fs_goingdown+0xf8/0x160 [xfs] (fs/xfs/xfs_fsops.c:500). Shutting down
filesystem.
[ 813.403514] XFS (sda3): Please unmount the filesystem and rectify the
problem(s)
[ 813.418455] sda3: writeback error on inode 60042, offset 63640576, sector
2306320
[ 813.418484] sda3: writeback error on inode 81161, offset 13091840, sector
2306496
[ 813.428831] sda3: writeback error on inode 16878782, offset 30536704, sector
18080754
[ 813.429026] Kernel attempted to read user page (108) - exploit attempt?
(uid: 0)
[ 813.429068] BUG: Kernel NULL pointer dereference on read at 0x00000108
[ 813.429085] Faulting instruction address: 0xc0000000000372e4
[ 813.429102] Oops: Kernel access of bad area, sig: 11 [#1]
[ 813.429117] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
[ 813.429133] Modules linked in: bonding rfkill tls sunrpc pseries_rng drm
fuse drm_panel_orientation_quirks xfs libcrc32c sd_mod t10_pi sg ibmvscsi
ibmveth scsi_transport_srp vmx_crypto
[ 813.429202] CPU: 3 PID: 94001 Comm: fsstress Kdump: loaded Tainted: G
W 5.15.0 #1
[ 813.429216] NIP: c0000000000372e4 LR: c0000000006d9e48 CTR:
c0000000000372d0
[ 813.429227] REGS: c000000064ba7440 TRAP: 0300 Tainted: G W
(5.15.0)
[ 813.429238] MSR: 800000010280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]>
CR: 88004280 XER: 00000000
[ 813.429272] CFAR: c00000000000cb1c DAR: 0000000000000108 DSISR: 40000000
IRQMASK: 0
[ 813.429272] GPR00: c0000000006d9e48 c000000064ba76e0 c000000002cdc400
0000000000000000
[ 813.429272] GPR04: c000000002c3ac50 0000000000000000 0000000000000000
c00000004d174000
[ 813.429272] GPR08: c0000000013d21d8 0000000000000000 0000000000000012
0000000000000000
[ 813.429272] GPR12: c0000000000372d0 c000000007fccb00 0000000000000000
0000000000000005
[ 813.429272] GPR16: 0000000000000000 c0000000d19fa900 c000000001365bb0
c000000003fc26b4
[ 813.429272] GPR20: c0000000d19fb338 0000000000040100 0000000000000001
0000000000000001
[ 813.429272] GPR24: c00000000135d2e0 00000000ffffffff c000000064ba7968
c000000001091ef8
[ 813.429272] GPR28: 0000000000000108 0000000000000004 c0000000cc456400
c000000002c3ac50
[ 813.429396] NIP [c0000000000372e4] tm_cgpr_active+0x14/0x40
[ 813.429420] LR [c0000000006d9e48] fill_thread_core_info+0x158/0x250
[ 813.429435] Call Trace:
[ 813.429443] [c000000064ba76e0] [c0000000006d9eb8]
fill_thread_core_info+0x1c8/0x250 (unreliable)
[ 813.429465] [c000000064ba7760] [c0000000006dac70]
fill_note_info.constprop.0+0x240/0x420
[ 813.429480] [c000000064ba77d0] [c0000000006daf3c] elf_core_dump+0xec/0x5e0
[ 813.429494] [c000000064ba79e0] [c0000000006e1edc] do_coredump+0x32c/0xc10
[ 813.429507] [c000000064ba7bb0] [c000000000187adc] get_signal+0x52c/0x910
[ 813.429519] [c000000064ba7ca0] [c000000000021b9c] do_signal+0x7c/0x330
[ 813.429533] [c000000064ba7d40] [c000000000022e00]
do_notify_resume+0xb0/0x140
[ 813.429548] [c000000064ba7d70] [c000000000031330]
interrupt_exit_user_prepare_main+0x220/0x280
[ 813.429562] [c000000064ba7de0] [c000000000031804]
syscall_exit_prepare+0xe4/0x1e0
[ 813.429575] [c000000064ba7e10] [c00000000000c174]
system_call_vectored_common+0xf4/0x278
[ 813.429589] --- interrupt: 3000 at 0x7fffa9c7667c
[ 813.429600] NIP: 00007fffa9c7667c LR: 0000000000000000 CTR:
0000000000000000
[ 813.429610] REGS: c000000064ba7e80 TRAP: 3000 Tainted: G W
(5.15.0)
[ 813.429621] MSR: 800000000000d033 <SF,EE,PR,ME,IR,DR,RI,LE> CR: 44004402
XER: 00000000
[ 813.429647] IRQMASK: 0
[ 813.429647] GPR00: 00000000000000fa 00007fffefa13e10 00007fffa9e17100
0000000000000000
[ 813.429647] GPR04: 0000000000016f31 0000000000000006 0000000000000008
00000000ffffffff
[ 813.429647] GPR08: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
[ 813.429647] GPR12: 0000000000000000 00007fffa9f2b040 0000000000000000
0000000000000000
[ 813.429647] GPR16: 0000000000000000 0000000000000000 0000000000000000
0000000010030de4
[ 813.429647] GPR20: 00000000100158c8 0000000000000000 0000000000000000
0000000010003d60
[ 813.429647] GPR24: 0000000000000001 0000000010012c60 00000000100137c8
0000000000000006
[ 813.429647] GPR28: 0000000000000005 ffffffffffffffff 00007fffa9f23840
0000000000016f31
[ 813.429776] NIP [00007fffa9c7667c] 0x7fffa9c7667c
[ 813.429789] LR [0000000000000000] 0x0
[ 813.429799] --- interrupt: 3000
[ 813.429808] Instruction dump:
[ 813.429816] 4bfe8345 60000000 e8010040 38210030 ebe1fff8 7c0803a6 4e800020
7c0802a6
[ 813.429839] 60000000 60000000 e92329c0 38600000 <e9290108> 7929e844 79291f43
4d820020
[ 813.429863] ---[ end trace 8a41ad95f224ad91 ]---
[ 813.431701]
[ 813.431723] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:573
[ 813.431733] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 94001,
name: fsstress
[ 813.431744] INFO: lockdep is turned off.
[ 813.431750] irq event stamp: 1270330
[ 813.431756] hardirqs last enabled at (1270329): [<c000000000589680>]
___slab_alloc+0xc40/0xf60
[ 813.431769] hardirqs last disabled at (1270330): [<c00000000009a4cc>]
interrupt_enter_prepare.constprop.0+0x10c/0x200
[ 813.431784] softirqs last enabled at (1269500): [<c008000001dc61dc>]
__rhashtable_insert_fast.constprop.0+0x3d4/0x7c0 [xfs]
[ 813.431932] softirqs last disabled at (1269498): [<c008000001dc5ef8>]
__rhashtable_insert_fast.constprop.0+0xf0/0x7c0 [xfs]
[ 813.432045] CPU: 3 PID: 94001 Comm: fsstress Kdump: loaded Tainted: G D
W 5.15.0 #1
[ 813.432056] Call Trace:
[ 813.432060] [c000000064ba6f20] [c00000000093e5d8] dump_stack_lvl+0xac/0x108
(unreliable)
[ 813.432075] [c000000064ba6f60] [c0000000001b991c] ___might_sleep+0x2dc/0x300
[ 813.432087] [c000000064ba6ff0] [c00000000107703c] __mutex_lock+0x6c/0x9e0
[ 813.432098] [c000000064ba7100] [c00000000069f678]
io_uring_del_tctx_node+0x78/0x170
[ 813.432111] [c000000064ba7140] [c0000000006b4c28]
io_uring_cancel_generic+0x248/0x3e0
[ 813.432122] [c000000064ba7200] [c00000000016ff70] do_exit+0xf0/0x700
[ 813.432135] [c000000064ba7290] [c00000000002b060] oops_end+0x1d0/0x200
[ 813.432148] [c000000064ba7310] [c000000000092ac4]
__bad_page_fault+0x174/0x190
[ 813.432177] [c000000064ba7380] [c00000000009c508]
__do_hash_fault+0x148/0x1f0
[ 813.432196] [c000000064ba73b0] [c00000000009c5d8] do_hash_fault+0x28/0x60
[ 813.432211] [c000000064ba73d0] [c00000000000891c]
data_access_common_virt+0x19c/0x1f0
[ 813.432226] --- interrupt: 300 at tm_cgpr_active+0x14/0x40
[ 813.432234] NIP: c0000000000372e4 LR: c0000000006d9e48 CTR:
c0000000000372d0
[ 813.432244] REGS: c000000064ba7440 TRAP: 0300 Tainted: G D W
(5.15.0)
[ 813.432253] MSR: 800000010280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]>
CR: 88004280 XER: 00000000
[ 813.432286] CFAR: c00000000000cb1c DAR: 0000000000000108 DSISR: 40000000
IRQMASK: 0
[ 813.432286] GPR00: c0000000006d9e48 c000000064ba76e0 c000000002cdc400
0000000000000000
[ 813.432286] GPR04: c000000002c3ac50 0000000000000000 0000000000000000
c00000004d174000
[ 813.432286] GPR08: c0000000013d21d8 0000000000000000 0000000000000012
0000000000000000
[ 813.432286] GPR12: c0000000000372d0 c000000007fccb00 0000000000000000
0000000000000005
[ 813.432286] GPR16: 0000000000000000 c0000000d19fa900 c000000001365bb0
c000000003fc26b4
[ 813.432286] GPR20: c0000000d19fb338 0000000000040100 0000000000000001
0000000000000001
[ 813.432286] GPR24: c00000000135d2e0 00000000ffffffff c000000064ba7968
c000000001091ef8
[ 813.432286] GPR28: 0000000000000108 0000000000000004 c0000000cc456400
c000000002c3ac50
[ 813.432402] NIP [c0000000000372e4] tm_cgpr_active+0x14/0x40
[ 813.432412] LR [c0000000006d9e48] fill_thread_core_info+0x158/0x250
[ 813.432424] --- interrupt: 300
[ 813.432429] [c000000064ba76e0] [c0000000006d9eb8]
fill_thread_core_info+0x1c8/0x250 (unreliable)
[ 813.432443] [c000000064ba7760] [c0000000006dac70]
fill_note_info.constprop.0+0x240/0x420
[ 813.432455] [c000000064ba77d0] [c0000000006daf3c] elf_core_dump+0xec/0x5e0
[ 813.432467] [c000000064ba79e0] [c0000000006e1edc] do_coredump+0x32c/0xc10
[ 813.432479] [c000000064ba7bb0] [c000000000187adc] get_signal+0x52c/0x910
[ 813.432492] [c000000064ba7ca0] [c000000000021b9c] do_signal+0x7c/0x330
[ 813.432518] [c000000064ba7d40] [c000000000022e00]
do_notify_resume+0xb0/0x140
[ 813.432537] [c000000064ba7d70] [c000000000031330]
interrupt_exit_user_prepare_main+0x220/0x280
[ 813.432556] [c000000064ba7de0] [c000000000031804]
syscall_exit_prepare+0xe4/0x1e0
[ 813.432571] [c000000064ba7e10] [c00000000000c174]
system_call_vectored_common+0xf4/0x278
[ 813.432585] --- interrupt: 3000 at 0x7fffa9c7667c
[ 813.432595] NIP: 00007fffa9c7667c LR: 0000000000000000 CTR:
0000000000000000
[ 813.432605] REGS: c000000064ba7e80 TRAP: 3000 Tainted: G D W
(5.15.0)
[ 813.432615] MSR: 800000000000d033 <SF,EE,PR,ME,IR,DR,RI,LE> CR: 44004402
XER: 00000000
[ 813.432641] IRQMASK: 0
[ 813.432641] GPR00: 00000000000000fa 00007fffefa13e10 00007fffa9e17100
0000000000000000
[ 813.432641] GPR04: 0000000000016f31 0000000000000006 0000000000000008
00000000ffffffff
[ 813.432641] GPR08: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
[ 813.432641] GPR12: 0000000000000000 00007fffa9f2b040 0000000000000000
0000000000000000
[ 813.432641] GPR16: 0000000000000000 0000000000000000 0000000000000000
0000000010030de4
[ 813.432641] GPR20: 00000000100158c8 0000000000000000 0000000000000000
0000000010003d60
[ 813.432641] GPR24: 0000000000000001 0000000010012c60 00000000100137c8
0000000000000006
[ 813.432641] GPR28: 0000000000000005 ffffffffffffffff 00007fffa9f23840
0000000000016f31
[ 813.432761] NIP [00007fffa9c7667c] 0x7fffa9c7667c
[ 813.432770] LR [0000000000000000] 0x0
[ 813.432777] --- interrupt: 3000
[ 860.223013] restraintd[1327]: *** Current Time: Mon Nov 01 12:42:42 2021
Localwatchdog at: Wed Nov 03 12:31:42 2021
I reproduced this bug on linux HEAD=8bb7eca972ad. The steps to reproduce this
bug is:
1) git clone git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
2) build xfstests
3) run generic/051 on ppc64le on xfs.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [PATCH v2] drivers: scsi: replace snprintf in show functions with sysfs_emit
From: cgel.zte @ 2021-11-02 6:59 UTC (permalink / raw)
To: tyreld
Cc: Jing Yao, martin.petersen, linux-scsi, jejb, linux-kernel, paulus,
linuxppc-dev, Zeal Robot
From: Jing Yao <yao.jing2@zte.com.cn>
coccicheck complains about the use of snprintf() in sysfs show
functions:
WARNING use scnprintf or sprintf
Use sysfs_emit instead of scnprintf or sprintf makes more sense.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Jing Yao <yao.jing2@zte.com.cn>
---
drivers/scsi/ibmvscsi/ibmvfc.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index d0eab5700dc5..69bf55c037a5 100644
--- a/drivers/scsi/ibmvscsi/ibmvfc.c
+++ b/drivers/scsi/ibmvscsi/ibmvfc.c
@@ -3403,7 +3403,7 @@ static ssize_t ibmvfc_show_host_partition_name(struct device *dev,
struct Scsi_Host *shost = class_to_shost(dev);
struct ibmvfc_host *vhost = shost_priv(shost);
- return snprintf(buf, PAGE_SIZE, "%s\n",
+ return sysfs_emit(buf, "%s\n",
vhost->login_buf->resp.partition_name);
}
@@ -3413,7 +3413,7 @@ static ssize_t ibmvfc_show_host_device_name(struct device *dev,
struct Scsi_Host *shost = class_to_shost(dev);
struct ibmvfc_host *vhost = shost_priv(shost);
- return snprintf(buf, PAGE_SIZE, "%s\n",
+ return sysfs_emit(buf, "%s\n",
vhost->login_buf->resp.device_name);
}
@@ -3423,7 +3423,7 @@ static ssize_t ibmvfc_show_host_loc_code(struct device *dev,
struct Scsi_Host *shost = class_to_shost(dev);
struct ibmvfc_host *vhost = shost_priv(shost);
- return snprintf(buf, PAGE_SIZE, "%s\n",
+ return sysfs_emit(buf, "%s\n",
vhost->login_buf->resp.port_loc_code);
}
@@ -3433,7 +3433,7 @@ static ssize_t ibmvfc_show_host_drc_name(struct device *dev,
struct Scsi_Host *shost = class_to_shost(dev);
struct ibmvfc_host *vhost = shost_priv(shost);
- return snprintf(buf, PAGE_SIZE, "%s\n",
+ return sysfs_emit(buf, "%s\n",
vhost->login_buf->resp.drc_name);
}
@@ -3442,7 +3442,7 @@ static ssize_t ibmvfc_show_host_npiv_version(struct device *dev,
{
struct Scsi_Host *shost = class_to_shost(dev);
struct ibmvfc_host *vhost = shost_priv(shost);
- return snprintf(buf, PAGE_SIZE, "%d\n", be32_to_cpu(vhost->login_buf->resp.version));
+ return sysfs_emit(buf, "%d\n", be32_to_cpu(vhost->login_buf->resp.version));
}
static ssize_t ibmvfc_show_host_capabilities(struct device *dev,
@@ -3450,7 +3450,7 @@ static ssize_t ibmvfc_show_host_capabilities(struct device *dev,
{
struct Scsi_Host *shost = class_to_shost(dev);
struct ibmvfc_host *vhost = shost_priv(shost);
- return snprintf(buf, PAGE_SIZE, "%llx\n", be64_to_cpu(vhost->login_buf->resp.capabilities));
+ return sysfs_emit(buf, "%llx\n", be64_to_cpu(vhost->login_buf->resp.capabilities));
}
/**
--
2.25.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox