aboutsummaryrefslogtreecommitdiffstats
path: root/arch/powerpc
AgeCommit message (Collapse)Author
6 daysMerge branch 'v6.1/standard/base' into ↵v6.1/standard/preempt-rt/cn-sdkv5.15/octeonBruce Ashfield
v6.1/standard/preempt-rt/cn-sdkv5.15/octeon Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> # Conflicts: # drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c
6 daysMerge tag 'v6.1.96' into v6.1/standard/basev6.1/standard/xilinx-zynqmpv6.1/standard/tiny/x86v6.1/standard/tiny/common-pcv6.1/standard/tiny/basev6.1/standard/ti-am335xv6.1/standard/qemuarm64v6.1/standard/nxp-ls20xxv6.1/standard/edgerouterv6.1/standard/beaglebonev6.1/standard/baseBruce Ashfield
This is the 6.1.96 stable release # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmZ9UTsACgkQONu9yGCS # aT46xxAAz4DR7XcjUDBRhOgA8NM6PVqHX1ZPzIAhUXYTtHcppvZXFvXk2nx0WWU2 # h/BWc9jaokteozI1+uMnlsye/t2gHYozE0300fFrFQkT0erVe6sPlmyKIOqikHi8 # 64SC4A3SoUxKo380iEtkLnFAhAjC8fppI2hjzofU71mFTQURM0Eeel+W6RSsZy09 # /oieXg9JeQF1nF/LfF8HindqyZ5q8GndEq7xD93zdDSimP1WpEfKJxqlDRzQLIUG # P1fvsam8+HClG5iN12WLfo3M9QjlaeDK8R0bplyKnRugeDCVCzRjk5MDucbODNSy # VQVihKV5QSTkwK3xD1tQ2Oko7/WXw1nWYJXwetPbRuVadqo+7jnYe0fL+QvzSGte # cliNWxiEGeCGBPm3YTP9f3oU+cBZVXZhs6p90dT8JNkfmySCxyXByHvEl8EidwHc # WvE4ntv9lgh3Q7q58yFGBSVtfkF6XxWbaEdF3WvskNTsXDvdnVyX1qI3O9Hj2o+o # NL+jHAqghReNgxKBxkG/hbYr8jkJ4zrPI+1fpipQfBR0Ytz5B/roiwQ/LozdW3BN # eCjUnjgU4z3feOm5bpEyOkuptV8zW3OTmA5Jnr+xq8TE9xfrDCuBrouj85UgUV8m # n9Q+BYd0WOe5lYNuS9Fq5eVE4r5BfXKUSgTfY6ZdQJ0fMPvGoRU= # =EnG7 # -----END PGP SIGNATURE----- # gpg: Signature made Thu 27 Jun 2024 07:47:07 AM EDT # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
8 dayspowerpc/io: Avoid clang null pointer arithmetic warningsMichael Ellerman
[ Upstream commit 03c0f2c2b2220fc9cf8785cd7b61d3e71e24a366 ] With -Wextra clang warns about pointer arithmetic using a null pointer. When building with CONFIG_PCI=n, that triggers a warning in the IO accessors, eg: In file included from linux/arch/powerpc/include/asm/io.h:672: linux/arch/powerpc/include/asm/io-defs.h:23:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] 23 | DEF_PCI_AC_RET(inb, u8, (unsigned long port), (port), pio, port) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... linux/arch/powerpc/include/asm/io.h:591:53: note: expanded from macro '__do_inb' 591 | #define __do_inb(port) readb((PCI_IO_ADDR)_IO_BASE + port); | ~~~~~~~~~~~~~~~~~~~~~ ^ That is because when CONFIG_PCI=n, _IO_BASE is defined as 0. Although _IO_BASE is defined as plain 0, the cast (PCI_IO_ADDR) converts it to void * before the addition with port happens. Instead the addition can be done first, and then the cast. The resulting value will be the same, but avoids the warning, and also avoids void pointer arithmetic which is apparently non-standard. Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Closes: https://lore.kernel.org/all/CA+G9fYtEh8zmq8k8wE-8RZwW-Qr927RLTn+KqGnq1F=ptaaNsA@mail.gmail.com Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240503075619.394467-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin <sashal@kernel.org>
8 dayspowerpc/pseries: Enforce hcall result buffer validity and sizeNathan Lynch
[ Upstream commit ff2e185cf73df480ec69675936c4ee75a445c3e4 ] plpar_hcall(), plpar_hcall9(), and related functions expect callers to provide valid result buffers of certain minimum size. Currently this is communicated only through comments in the code and the compiler has no idea. For example, if I write a bug like this: long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...); This compiles with no diagnostics emitted, but likely results in stack corruption at runtime when plpar_hcall9() stores results past the end of the array. (To be clear this is a contrived example and I have not found a real instance yet.) To make this class of error less likely, we can use explicitly-sized array parameters instead of pointers in the declarations for the hcall APIs. When compiled with -Warray-bounds[1], the code above now provokes a diagnostic like this: error: array argument is too small; is of size 32, callee requires at least 72 [-Werror,-Warray-bounds] 60 | plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, | ^ ~~~~~~ [1] Enabled for LLVM builds but not GCC for now. See commit 0da6e5fd6c37 ("gcc: disable '-Warray-bounds' for gcc-13 too") and related changes. Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240408-pseries-hvcall-retbuf-v1-1-ebc73d7253cf@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
10 daysMerge branch 'v6.1/standard/base' into v6.1/standard/preempt-rt/baseBruce Ashfield
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> # Conflicts: # drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
10 daysMerge tag 'v6.1.95' into v6.1/standard/baseBruce Ashfield
This is the 6.1.95 stable release # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmZ1c7gACgkQONu9yGCS # aT6k6w//dJLH5VWQ2Gc3OCzKYKjNGa5vAdMpsqHZmyMUiK8Rhv/38cb9NrAYcFHQ # wlxm6sftbPPCHet6GpSiqDB/HDemGtqjCzHng8AywSsaiPhpvki4wvpt6p+hlUmf # Lck1qyvyJitoUoUikdWskD4HU02kBXRLHj5k4TxBVTT9FmyG5rjbXRD2pZjI6897 # PVni/94hJhBcTV/rqAufLOivKE4gwiYVfa7et9WMD3xiAmN7i5hcYUeBCCXlaE4B # wMbYTBcMZF2rz3q5LP1ZC/qotnaT04xSwm8bW21FTji6tsyVAK8XmYIenLunTOgw # 3om5GJBYciZ0bHrxugUEz5UenORFS2bMuMQJ0q0fuo5vkVHoSRZt5DnOmtxq4fGN # t2/TYFDKp7V52z0FJ3moWwwxBdfCEeZ/+XVKtwzb/rT1fFAfemMrY7TnkAZxbmhv # 2PTw+i59hlwrOgw3VeiZDA9gxNDEas9SbwZYFDndTmMA9KtYLj2OGKH1K1rCEDkp # tOTWTzWR4Tkd255J3z4WBvw6VCRsun5tSSEBUkDen8QgWtk57XmIzGu+479zINkQ # SUqXJA9dFiAPBHSsVGgcz7RsQMi2ubVjM9ZWa9i2CK7IkwAP1qISFqI8Wdthr4M8 # UK/SI0RF/M+mMWlxqr6Kyfj7JBZmljqzu+vwiX8D6KgXNp2npbk= # =RFmj # -----END PGP SIGNATURE----- # gpg: Signature made Fri 21 Jun 2024 08:36:08 AM EDT # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
14 dayspowerpc/uaccess: Fix build errors seen with GCC 13/14Michael Ellerman
commit 2d43cc701b96f910f50915ac4c2a0cae5deb734c upstream. Building ppc64le_defconfig with GCC 14 fails with assembler errors: CC fs/readdir.o /tmp/ccdQn0mD.s: Assembler messages: /tmp/ccdQn0mD.s:212: Error: operand out of domain (18 is not a multiple of 4) /tmp/ccdQn0mD.s:226: Error: operand out of domain (18 is not a multiple of 4) ... [6 lines] /tmp/ccdQn0mD.s:1699: Error: operand out of domain (18 is not a multiple of 4) A snippet of the asm shows: # ../fs/readdir.c:210: unsafe_copy_dirent_name(dirent->d_name, name, namlen, efault_end); ld 9,0(29) # MEM[(u64 *)name_38(D) + _88 * 1], MEM[(u64 *)name_38(D) + _88 * 1] # 210 "../fs/readdir.c" 1 1: std 9,18(8) # put_user # *__pus_addr_52, MEM[(u64 *)name_38(D) + _88 * 1] The 'std' instruction requires a 4-byte aligned displacement because it is a DS-form instruction, and as the assembler says, 18 is not a multiple of 4. A similar error is seen with GCC 13 and CONFIG_UBSAN_SIGNED_WRAP=y. The fix is to change the constraint on the memory operand to put_user(), from "m" which is a general memory reference to "YZ". The "Z" constraint is documented in the GCC manual PowerPC machine constraints, and specifies a "memory operand accessed with indexed or indirect addressing". "Y" is not documented in the manual but specifies a "memory operand for a DS-form instruction". Using both allows the compiler to generate a DS-form "std" or X-form "stdx" as appropriate. The change has to be conditional on CONFIG_PPC_KERNEL_PREFIXED because the "Y" constraint does not guarantee 4-byte alignment when prefixed instructions are enabled. Unfortunately clang doesn't support the "Y" constraint so that has to be behind an ifdef. Although the build error is only seen with GCC 13/14, that appears to just be luck. The constraint has been incorrect since it was first added. Fixes: c20beffeec3c ("powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()") Cc: stable@vger.kernel.org # v5.10+ Suggested-by: Kewen Lin <linkw@gcc.gnu.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240529123029.146953-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-17Merge branch 'v6.1/standard/base' into v6.1/standard/preempt-rt/baseBruce Ashfield
2024-06-17Merge tag 'v6.1.94' into v6.1/standard/baseBruce Ashfield
This is the 6.1.94 stable release # -----BEGIN PGP SIGNATURE----- # # iQIyBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmZuz8EACgkQONu9yGCS # aT4YXw/4jfUDI5QTQiD7h176b8YZQlDG0XqFl2YcfZfk3QlP8kvBOxFreUCORI8P # lzsI0azmlNPbkIQt/B4PZ2g+TWOdty/qsNWX5rWKe1H4/S6rBqgC7J4ppTDn+rGw # MeUiFCSqBz0Twku+EOxGWqVS4gs9+OPll2fqCGSzN8+6Ku4uhmrKvz0sNHgej5ct # B8KqvznVN8sitBquVwoTcW2fUWAt/98Dhh/+0E0Q28P2KhVyqrt5TwkI1rsNXVA3 # ZYHONT4k4ItPMGMw2gyeEo9avlyjIdd4BQ696ePrqFaGWHTUIEbw/ZLw/cb8AbWn # YVv3PcgAZoX10vHZmwqBEklt8cM6B3L55o5gHoO1bSKKqmJQO/a4WTdzgGNFdOLe # hvN+chrt6y3R7naT8Q5xdt5DVa59f+drw4AX2vnK3Siv3u1J7k4Iq6WT8Ij/FSUH # cL5UtQ9/iWPeEg1221WidoCttFySwFfUixg+Fc8sX71PFkraAOvJmV/Eiqo79d3t # VbCY1MWoTkieeu2AGffA3IXWEL6yTdVTw2zfPkd5kKv584yCwlvsV4GhV16ygqJK # e08I3vjiCO9hLjpplrYkFFxE97gqq2IQuwZbxgOhdKfpo+tTTZrS7p00AZRPIpvL # RQK5ogSTkNQr15pjDY1SdqXpOntZxp5RFaPXwLJ28qUByZsUGw== # =nofp # -----END PGP SIGNATURE----- # gpg: Signature made Sun 16 Jun 2024 07:42:57 AM EDT # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
2024-06-17Merge tag 'v6.1.93' into v6.1/standard/baseBruce Ashfield
This is the 6.1.93 stable release # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmZpZN8ACgkQONu9yGCS # aT4/2RAApnfpBVZKYq3SNotcHVSJwMp0lY2L1Hy714QtQ1xCu8c4LgxcytKemBZo # riduGbSV3t3BOHcRyVwJLLSjRMMdESdp6jvieXItHroNJLmoLBhlWg0ifbceCIBe # M+IuNIB0kDs5dVmVc0x/E9h7Zloj6ikLfyaJrwedXbpTTRep6BRjkkUcBs6AqvrL # Ndo2GoTfkQ8VrGsj4aNn+YcbTpaokP2ikaNntTsUc6PfdK7C7k8pEgUQKq2CM7zl # 7p5TQEOjS+lEAisA4Dswz+fhh/Gvke0TStDQzRQRfFzgB3tVb4gxGYmLKOGqidya # ttLa3D6bEJgqg75NNuNg7skgrYjzUs6z3/YlNxrUwpK+fUId/EYyJjIQKDmoQSgr # bBUiT6FWb5b+sJ2zOjlJSCptTaq4m/oT0nXXQtVldPkEWn3biKxSwB9+ya6mzVi7 # dlbONp0OBpTFxKHhwE3V/tYrowqq6Aqfc9GafJRHXFYi6bp+F6Ghha47UqYJ/Vpk # xD31HequQOh7V3HpMQqfiJwWj5ykvGZch6q8FxYI66MLhFfcob3nCvvb80E77q27 # 2nvLEdNOdK26ypwKDJRQRJnudf1lFoFqq5NaY3bJDvGDB2Qe3MbR1ZhWTht73cMO # NNMk4IDUl4zOvpDdkeYe4gG6ncBkKLW3GhFDfM1T6yTIHFPjB0Y= # =9a7Q # -----END PGP SIGNATURE----- # gpg: Signature made Wed 12 Jun 2024 05:05:35 AM EDT # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
2024-06-16powerpc/bpf: enforce full ordering for ATOMIC operations with BPF_FETCHPuranjay Mohan
commit b1e7cee96127468c2483cf10c2899c9b5cf79bf8 upstream. The Linux Kernel Memory Model [1][2] requires RMW operations that have a return value to be fully ordered. BPF atomic operations with BPF_FETCH (including BPF_XCHG and BPF_CMPXCHG) return a value back so they need to be JITed to fully ordered operations. POWERPC currently emits relaxed operations for these. We can show this by running the following litmus-test: PPC SB+atomic_add+fetch { 0:r0=x; (* dst reg assuming offset is 0 *) 0:r1=2; (* src reg *) 0:r2=1; 0:r4=y; (* P0 writes to this, P1 reads this *) 0:r5=z; (* P1 writes to this, P0 reads this *) 0:r6=0; 1:r2=1; 1:r4=y; 1:r5=z; } P0 | P1 ; stw r2, 0(r4) | stw r2,0(r5) ; | ; loop:lwarx r3, r6, r0 | ; mr r8, r3 | ; add r3, r3, r1 | sync ; stwcx. r3, r6, r0 | ; bne loop | ; mr r1, r8 | ; | ; lwa r7, 0(r5) | lwa r7,0(r4) ; ~exists(0:r7=0 /\ 1:r7=0) Witnesses Positive: 9 Negative: 3 Condition ~exists (0:r7=0 /\ 1:r7=0) Observation SB+atomic_add+fetch Sometimes 3 9 This test shows that the older store in P0 is reordered with a newer load to a different address. Although there is a RMW operation with fetch between them. Adding a sync before and after RMW fixes the issue: Witnesses Positive: 9 Negative: 0 Condition ~exists (0:r7=0 /\ 1:r7=0) Observation SB+atomic_add+fetch Never 0 9 [1] https://www.kernel.org/doc/Documentation/memory-barriers.txt [2] https://www.kernel.org/doc/Documentation/atomic_t.txt Fixes: aea7ef8a82c0 ("powerpc/bpf/32: add support for BPF_ATOMIC bitwise operations") Fixes: 2d9206b22743 ("powerpc/bpf/32: Add instructions for atomic_[cmp]xchg") Fixes: dbe6e2456fb0 ("powerpc/bpf/64: add support for atomic fetch operations") Fixes: 1e82dfaa7819 ("powerpc/bpf/64: Add instructions for atomic_[cmp]xchg") Cc: stable@vger.kernel.org # v6.0+ Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Reviewed-by: Naveen N Rao <naveen@kernel.org> Acked-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240513100248.110535-1-puranjay@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-16mm: fix race between __split_huge_pmd_locked() and GUP-fastRyan Roberts
commit 3a5a8d343e1cf96eb9971b17cbd4b832ab19b8e7 upstream. __split_huge_pmd_locked() can be called for a present THP, devmap or (non-present) migration entry. It calls pmdp_invalidate() unconditionally on the pmdp and only determines if it is present or not based on the returned old pmd. This is a problem for the migration entry case because pmd_mkinvalid(), called by pmdp_invalidate() must only be called for a present pmd. On arm64 at least, pmd_mkinvalid() will mark the pmd such that any future call to pmd_present() will return true. And therefore any lockless pgtable walker could see the migration entry pmd in this state and start interpretting the fields as if it were present, leading to BadThings (TM). GUP-fast appears to be one such lockless pgtable walker. x86 does not suffer the above problem, but instead pmd_mkinvalid() will corrupt the offset field of the swap entry within the swap pte. See link below for discussion of that problem. Fix all of this by only calling pmdp_invalidate() for a present pmd. And for good measure let's add a warning to all implementations of pmdp_invalidate[_ad](). I've manually reviewed all other pmdp_invalidate[_ad]() call sites and believe all others to be conformant. This is a theoretical bug found during code review. I don't have any test case to trigger it in practice. Link: https://lkml.kernel.org/r/20240501143310.1381675-1-ryan.roberts@arm.com Link: https://lore.kernel.org/all/0dd7827a-6334-439a-8fd0-43c98e6af22b@arm.com/ Fixes: 84c3fc4e9c56 ("mm: thp: check pmd migration entry in common path") Signed-off-by: Ryan Roberts <ryan.roberts@arm.com> Reviewed-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Acked-by: David Hildenbrand <david@redhat.com> Cc: Andreas Larsson <andreas@gaisler.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Aneesh Kumar K.V <aneesh.kumar@kernel.org> Cc: Borislav Petkov (AMD) <bp@alien8.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Naveen N. Rao <naveen.n.rao@linux.ibm.com> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-12powerpc/pseries/lparcfg: drop error message from guest name lookupNathan Lynch
[ Upstream commit 12870ae3818e39ea65bf710f645972277b634f72 ] It's not an error or exceptional situation when the hosting environment does not expose a name for the LP/guest via RTAS or the device tree. This happens with qemu when run without the '-name' option. The message also lacks a newline. Remove it. Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com> Fixes: eddaa9a40275 ("powerpc/pseries: read the lpar name from the firmware") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240524-lparcfg-updates-v2-1-62e2e9d28724@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12powerpc/pseries: Add failure related checks for h_get_mpp and h_get_pppShrikanth Hegde
[ Upstream commit 6d4341638516bf97b9a34947e0bd95035a8230a5 ] Couple of Minor fixes: - hcall return values are long. Fix that for h_get_mpp, h_get_ppp and parse_ppp_data - If hcall fails, values set should be at-least zero. It shouldn't be uninitialized values. Fix that for h_get_mpp and h_get_ppp Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240412092047.455483-3-sshegde@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12powerpc/fsl-soc: hide unused const variableArnd Bergmann
[ Upstream commit 01acaf3aa75e1641442cc23d8fe0a7bb4226efb1 ] vmpic_msi_feature is only used conditionally, which triggers a rare -Werror=unused-const-variable= warning with gcc: arch/powerpc/sysdev/fsl_msi.c:567:37: error: 'vmpic_msi_feature' defined but not used [-Werror=unused-const-variable=] 567 | static const struct fsl_msi_feature vmpic_msi_feature = Hide this one in the same #ifdef as the reference so we can turn on the warning by default. Fixes: 305bcf26128e ("powerpc/fsl-soc: use CONFIG_EPAPR_PARAVIRT for hcalls") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240403080702.3509288-2-arnd@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-28Merge branch 'v6.1/standard/base' into v6.1/standard/preempt-rt/baseBruce Ashfield
2024-05-28Merge tag 'v6.1.91' into v6.1/standard/baseBruce Ashfield
This is the 6.1.91 stable release # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmZHKjwACgkQONu9yGCS # aT4J+hAAvA8bJfKlcwBNgXkL5+0e67cLce27T/YG2KlF1GFmBDDz6DS1OgYofgfj # ejyFZBFto4lz1MF74LycCpNfaqwNeumuxENVV+hn9JDlm6UtjmX3qSKQl4S9sjlw # lPUHoJOeh2ZmK8UBtjEH/f7emdn0IhMRpVs+kqhDmFXiiaxu0PY1XrPNvaSP+zdk # 7VKtVQFy8no3aHyQweOw0T86/WEri7U65g1qx+XIhU4AQyaeCAH88UNjuZh3Flq7 # sTOSl32hvOCkki+pxI2nN+M8JaJtxZUoxesdpva/TBXEuPlLJk9XXgTY6WvonMy6 # 5r1mQ1ReB/N4X9UkGmLSXIENZJy+AkGLUxkqYsscSPZrX67SeuN37Jiy0bijzMFs # 863tDPESzNDtdmk0tuX2Vjtn6ge1Yu6uB5TgtOgiv0I3PqGAmiIykrRrOpoEnj0S # uwWNyk4vG2i9ncTpoL6f+dsO3av+hvttbxirq2yxxJ4qR96aIk1zzINTZyg+lKw8 # +NU+bri/6I+ckgBKmgUfHyLMWTrFc0VBmefvXPFWx64eq3tHQROd0O949W+XBGgO # GZZxvAqT1LAHh7HSg4KS8SYlHlR7bGXEZhZOJI7JprQVcBZfWAYd1r1lUBIMWLxV # A0SeY0jcyePtgNCJlfKrrtxTV/SH+LtasJPEi3W2pme61zn+jCw= # =nwTL # -----END PGP SIGNATURE----- # gpg: Signature made Fri 17 May 2024 05:58:20 AM EDT # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
2024-05-17powerpc/pseries/iommu: LPAR panics during boot up with a frozen PEGaurav Batra
[ Upstream commit 49a940dbdc3107fecd5e6d3063dc07128177e058 ] At the time of LPAR boot up, partition firmware provides Open Firmware property ibm,dma-window for the PE. This property is provided on the PCI bus the PE is attached to. There are execptions where the partition firmware might not provide this property for the PE at the time of LPAR boot up. One of the scenario is where the firmware has frozen the PE due to some error condition. This PE is frozen for 24 hours or unless the whole system is reinitialized. Within this time frame, if the LPAR is booted, the frozen PE will be presented to the LPAR but ibm,dma-window property could be missing. Today, under these circumstances, the LPAR oopses with NULL pointer dereference, when configuring the PCI bus the PE is attached to. BUG: Kernel NULL pointer dereference on read at 0x000000c8 Faulting instruction address: 0xc0000000001024c0 Oops: Kernel access of bad area, sig: 7 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: Supported: Yes CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.4.0-150600.9-default #1 Hardware name: IBM,9043-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_023) hv:phyp pSeries NIP: c0000000001024c0 LR: c0000000001024b0 CTR: c000000000102450 REGS: c0000000037db5c0 TRAP: 0300 Not tainted (6.4.0-150600.9-default) MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 28000822 XER: 00000000 CFAR: c00000000010254c DAR: 00000000000000c8 DSISR: 00080000 IRQMASK: 0 ... NIP [c0000000001024c0] pci_dma_bus_setup_pSeriesLP+0x70/0x2a0 LR [c0000000001024b0] pci_dma_bus_setup_pSeriesLP+0x60/0x2a0 Call Trace: pci_dma_bus_setup_pSeriesLP+0x60/0x2a0 (unreliable) pcibios_setup_bus_self+0x1c0/0x370 __of_scan_bus+0x2f8/0x330 pcibios_scan_phb+0x280/0x3d0 pcibios_init+0x88/0x12c do_one_initcall+0x60/0x320 kernel_init_freeable+0x344/0x3e4 kernel_init+0x34/0x1d0 ret_from_kernel_user_thread+0x14/0x1c Fixes: b1fc44eaa9ba ("pseries/iommu/ddw: Fix kdump to work in absence of ibm,dma-window") Signed-off-by: Gaurav Batra <gbatra@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240422205141.10662-1-gbatra@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-17powerpc/pseries: make max polling consistent for longer H_CALLsNayna Jain
[ Upstream commit 784354349d2c988590c63a5a001ca37b2a6d4da1 ] Currently, plpks_confirm_object_flushed() function polls for 5msec in total instead of 5sec. Keep max polling time consistent for all the H_CALLs, which take longer than expected, to be 5sec. Also, make use of fsleep() everywhere to insert delay. Reported-by: Nageswara R Sastry <rnsastry@linux.ibm.com> Fixes: 2454a7af0f2a ("powerpc/pseries: define driver for Platform KeyStore") Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com> Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240418031230.170954-1-nayna@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-17powerpc/pseries: Move PLPKS constants to header fileRussell Currey
[ Upstream commit 3def7a3e7c2ce2ab5e5c54561da7125206851be4 ] Move the constants defined in plpks.c to plpks.h, and standardise their naming, so that PLPKS consumers can make use of them later on. Signed-off-by: Russell Currey <ruscur@russell.cc> Co-developed-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20230210080401.345462-16-ajd@linux.ibm.com Stable-dep-of: 784354349d2c ("powerpc/pseries: make max polling consistent for longer H_CALLs") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-17powerpc/pseries: replace kmalloc with kzalloc in PLPKS driverNayna Jain
[ Upstream commit 212dd5cfbee7815f3c665a51c501701edb881599 ] Replace kmalloc with kzalloc in construct_auth() function to default initialize structure with zeroes. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20221106205839.600442-6-nayna@linux.ibm.com Stable-dep-of: 784354349d2c ("powerpc/pseries: make max polling consistent for longer H_CALLs") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-09Merge branch 'v6.1/standard/base' into v6.1/standard/preempt-rt/baseBruce Ashfield
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> # Conflicts: # drivers/tty/serial/8250/8250_port.c
2024-04-09Merge tag 'v6.1.84' into v6.1/standard/baseBruce Ashfield
This is the 6.1.84 stable release # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmYNV6cACgkQONu9yGCS # aT4HvBAAmblOq7LuUZQ7GdoPH6huJC4Znm0zLYcWZEhIFssA0Xm8lt57VEDrsJft # DYpNCNWOo42v2Ml15fTVEzeWHjcNWbewIBESJYaOSuRHt+6hihteoMu1ad2lM+aR # +CXE3PJjAipunnKtbdyS0z+g4WHuIVG/EgjvRdTzonznGODOiTz6D2KiRcIJo9kR # T+HwkPw/S+1N8yICGuMfJQzj9lF+NJpvFBxwFsm62RPXGD/xI2Q93upPoXdBlxXX # aWoR3HmkZ1EVXqkEIzFVviRn2QI22uKUGE942R38Wg5xdZcTrOeI5to0fX7rr+oA # sJVLQzmrnwaJWiBMXtiGbtwn1PdtIaZbMMrxJa471/plVv3aQW+fTNLOPW9wzPDV # 8Aap29bgvI0lDhbP5yK2uCCbpvN570cKWgk/xFmIGq7USfZNUOKXrg2uuHAC6BLo # U8PycpD2OvL/t0Y8gA/twjPsqqpoNPZuywUEWbfaWPvpnKPh0UweKXi1syqv41Th # //HQDrSzJxQuraWCoYvmG1R1jlOSOp7tiHNmnBCmbjJw1wEC9XOMwQ2frrVrRj1n # g4IDY04jcOQmbrgVqBkIRa1ZFFFpepZlDwnyYpmFpo8szPr+1YvJ8h/w/olcH11Q # 2VDenFG4E3nY/fjWclp4PmkVlmpXYMlciV89pDhOn/FVl8Adhp0= # =maia # -----END PGP SIGNATURE----- # gpg: Signature made Wed 03 Apr 2024 09:20:39 AM EDT # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
2024-04-03powerpc: xor_vmx: Add '-mhard-float' to CFLAGSNathan Chancellor
[ Upstream commit 35f20786c481d5ced9283ff42de5c69b65e5ed13 ] arch/powerpc/lib/xor_vmx.o is built with '-msoft-float' (from the main powerpc Makefile) and '-maltivec' (from its CFLAGS), which causes an error when building with clang after a recent change in main: error: option '-msoft-float' cannot be specified with '-maltivec' make[6]: *** [scripts/Makefile.build:243: arch/powerpc/lib/xor_vmx.o] Error 1 Explicitly add '-mhard-float' before '-maltivec' in xor_vmx.o's CFLAGS to override the previous inclusion of '-msoft-float' (as the last option wins), which matches how other areas of the kernel use '-maltivec', such as AMDGPU. Cc: stable@vger.kernel.org Closes: https://github.com/ClangBuiltLinux/linux/issues/1986 Link: https://github.com/llvm/llvm-project/commit/4792f912b232141ecba4cbae538873be3c28556c Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240127-ppc-xor_vmx-drop-msoft-float-v1-1-f24140e81376@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-03powerpc/fsl: Fix mfpmr build errors with newer binutilsMichael Ellerman
[ Upstream commit 5f491356b7149564ab22323ccce79c8d595bfd0c ] Binutils 2.38 complains about the use of mfpmr when building ppc6xx_defconfig: CC arch/powerpc/kernel/pmc.o {standard input}: Assembler messages: {standard input}:45: Error: unrecognized opcode: `mfpmr' {standard input}:56: Error: unrecognized opcode: `mtpmr' This is because by default the kernel is built with -mcpu=powerpc, and the mt/mfpmr instructions are not defined. It can be avoided by enabling CONFIG_E300C3_CPU, but just adding that to the defconfig will leave open the possibility of randconfig failures. So add machine directives around the mt/mfpmr instructions to tell binutils how to assemble them. Cc: stable@vger.kernel.org Reported-by: Jan-Benedict Glaw <jbglaw@lug-owl.de> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240229122521.762431-3-mpe@ellerman.id.au Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-03powerpc/smp: Increase nr_cpu_ids to include the boot CPUMichael Ellerman
[ Upstream commit 777f81f0a9c780a6443bcf2c7785f0cc2e87c1ef ] If nr_cpu_ids is too low to include the boot CPU adjust nr_cpu_ids upward. Otherwise the kernel will BUG when trying to allocate a paca for the boot CPU and fail to boot. Cc: stable@vger.kernel.org Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231229120107.2281153-2-mpe@ellerman.id.au Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-03powerpc/smp: Adjust nr_cpu_ids to cover all threads of a coreMichael Ellerman
[ Upstream commit 5580e96dad5a439d561d9648ffcbccb739c2a120 ] If nr_cpu_ids is too low to include at least all the threads of a single core adjust nr_cpu_ids upwards. This avoids triggering odd bugs in code that assumes all threads of a core are available. Cc: stable@vger.kernel.org Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231229120107.2281153-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-28Merge branch 'v6.1/standard/base' into v6.1/standard/preempt-rt/baseBruce Ashfield
2024-03-28Merge tag 'v6.1.83' into v6.1/standard/baseBruce Ashfield
Linux 6.1.83 # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCgAdFiEE4n5dijQDou9mhzu83qZv95d3LNwFAmYDTlsACgkQ3qZv95d3 # LNx2Pw/8DMFid77ao/8dNIIsldgMFxz+7GQwQCHGWcJOm0QJVX5h51n7pH9i8t7Y # gBbnitOnEq9Oo5mDHaowNQnmcR1oB7BWpM+wcEN2L1eGqJFVOj1f5MdloUY9OLcO # l9Mq6lM+uojxc02i3y/J6WwLUZNs+3iVLnv30CyU4pjnbBB8OBm2JFyF3p+nl9oa # QL/6cqeOBKwyRu+cvNWsRchrN+uGBk+2l6ufwPup2o+U4gLKhdVSjpmO4km+DjM2 # KnZ8Qy4enDYT9whrMJ8mACb13+qHLm/HiVZycqr253SsbeJ9H1LX02RvAKqzrmqQ # KwOTM/p1Fep7NdqeANSyTSj+mU5ZP/ScApqXiLzEDOgpW5IfgBmCdIhvlqeJwm3s # kVhLM7Cs6UZmJuMibCztnv12xFUZyd8W9gBVD7M1wy/ANScJzF7c9+OC7iqPZqRt # tGq4ngMYDEPy/eIKJUaa2b5m1K6jeCzCxjig5GyLjJpKBJWK6HJGJ9eQLixLpotr # uOqlzIEHtGBerm69CNQFLUUqvqc4fGqZKHEBeIYUKrhOR3+ILTEHb/eiKaaBjJaD # inor8t6OyXZsm+SuoRsQY5czmzrJJYa3towh5Ha8dNUS6HzCemLykQWX+AALpVZ8 # UKh1swqxX2xNk4CGA3tS/Ti096GCZUoXIVlf3dZ5ejGrw+ocT+4= # =2pYy # -----END PGP SIGNATURE----- # gpg: Signature made Tue 26 Mar 2024 06:38:19 PM EDT # gpg: using RSA key E27E5D8A3403A2EF66873BBCDEA66FF797772CDC # gpg: Can't check signature: No public key
2024-03-26powerpc/embedded6xx: Fix no previous prototype for avr_uart_send() etc.Michael Ellerman
[ Upstream commit 20933531be0577cdd782216858c26150dbc7936f ] Move the prototypes into mpc10x.h which is included by all the relevant C files, fixes: arch/powerpc/platforms/embedded6xx/ls_uart.c:59:6: error: no previous prototype for 'avr_uart_configure' arch/powerpc/platforms/embedded6xx/ls_uart.c:82:6: error: no previous prototype for 'avr_uart_send' Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240305123410.3306253-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-26powerpc/hv-gpci: Fix the H_GET_PERF_COUNTER_INFO hcall return value checksKajol Jain
[ Upstream commit ad86d7ee43b22aa2ed60fb982ae94b285c1be671 ] Running event hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ in one of the system throws below error: ---Logs--- # perf list | grep hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=?/[Kernel PMU event] # perf stat -v -e hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ sleep 2 Using CPUID 00800200 Control descriptor is not initialized Warning: hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ event is not supported by the kernel. failed to read counter hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ Performance counter stats for 'system wide': <not supported> hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ 2.000700771 seconds time elapsed The above error is because of the hcall failure as required permission "Enable Performance Information Collection" is not set. Based on current code, single_gpci_request function did not check the error type incase hcall fails and by default returns EINVAL. But we can have other reasons for hcall failures like H_AUTHORITY/H_PARAMETER with detail_rc as GEN_BUF_TOO_SMALL, for which we need to act accordingly. Fix this issue by adding new checks in the single_gpci_request and h_gpci_event_init functions. Result after fix patch changes: # perf stat -e hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ sleep 2 Error: No permission to enable hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ event. Fixes: 220a0c609ad1 ("powerpc/perf: Add support for the hv gpci (get performance counter info) interface") Reported-by: Akanksha J N <akanksha@linux.ibm.com> Signed-off-by: Kajol Jain <kjain@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240229122847.101162-1-kjain@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-26powerpc/pseries: Fix potential memleak in papr_get_attr()Qiheng Lin
[ Upstream commit cda9c0d556283e2d4adaa9960b2dc19b16156bae ] `buf` is allocated in papr_get_attr(), and krealloc() of `buf` could fail. We need to free the original `buf` in the case of failure. Fixes: 3c14b73454cf ("powerpc/pseries: Interface to represent PAPR firmware attributes") Signed-off-by: Qiheng Lin <linqiheng@huawei.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20221208133449.16284-1-linqiheng@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-26powerpc: Force inlining of arch_vmap_p{u/m}d_supported()Christophe Leroy
[ Upstream commit c5aebb53b32460bc52680dd4e2a2f6b84d5ea521 ] arch_vmap_pud_supported() and arch_vmap_pmd_supported() are expected to constant-fold to false when RADIX is not enabled. Force inlining in order to avoid following failure which leads to unexpected call of non-existing pud_set_huge() and pmd_set_huge() on powerpc 8xx. In function 'pud_huge_tests', inlined from 'debug_vm_pgtable' at mm/debug_vm_pgtable.c:1399:2: ./arch/powerpc/include/asm/vmalloc.h:9:33: warning: inlining failed in call to 'arch_vmap_pud_supported.isra': call is unlikely and code size would grow [-Winline] 9 | #define arch_vmap_pud_supported arch_vmap_pud_supported | ^~~~~~~~~~~~~~~~~~~~~~~ ./arch/powerpc/include/asm/vmalloc.h:10:20: note: in expansion of macro 'arch_vmap_pud_supported' 10 | static inline bool arch_vmap_pud_supported(pgprot_t prot) | ^~~~~~~~~~~~~~~~~~~~~~~ ./arch/powerpc/include/asm/vmalloc.h:9:33: note: called from here 9 | #define arch_vmap_pud_supported arch_vmap_pud_supported mm/debug_vm_pgtable.c:458:14: note: in expansion of macro 'arch_vmap_pud_supported' 458 | if (!arch_vmap_pud_supported(args->page_prot) || | ^~~~~~~~~~~~~~~~~~~~~~~ Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202402131836.OU1TDuoi-lkp@intel.com/ Fixes: 8309c9d71702 ("powerpc: inline huge vmap supported functions") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/bbd84ad52bf377e8d3b5865a906f2dc5d99964ba.1707832677.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-10Merge branch 'v6.1/standard/base' into v6.1/standard/preempt-rt/baseBruce Ashfield
2024-03-10Merge tag 'v6.1.81' into v6.1/standard/baseBruce Ashfield
This is the 6.1.81 stable release # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmXogYcACgkQONu9yGCS # aT4cyA//ZR+UzUyvnZcZ2o7NKuuYw6GOD3RvtNEaFSRAksQVX4nmeg48ScwT6VaG # NdvJSfXOasDx75hiSXTShbtwP3hAh68fnKVzx8e2pzLDPyoIqrTAq3eR1DDg1y0+ # jh8CfddqY5wSsZQVmQUCNOr03m3U/K4QDp6bYTCESHzCkBcAsPPOf8JhJgkwkjnV # wzCGJ7DoOKcaSHnnyMIPYkW9gFdYvQeA8pIKnVGv5NcwmwI47VhQpdlPyC5t5SVj # cEr+bH/mioLdzd5tjdNSSRZ5EsP2VScSDfUQDK0HZMFzJDBe0w6vdg0v+SwzpYey # yMYHrPvRDvWIQ+STZbFZkzGpDv9v6nL1fpxgNyVc74SsaxQINC+XTtgnmglw2TYP # VZOGhdd1TZ2D83l20LO5U6NyiTH5QGzbTHK4nL4XYdycc4xRflP00zuveAhJmXCq # 2zhEybu0BWzWu02uLnNTi9INUTYEUo87ArXsTcy3RNT+TcEr6Hgj320Es6QSpuf6 # aM/5LN4c+o1iHrCuPwFZuO0YUmi75hrTsOGYYSQ1Fim7DXHB540lHucL+e0j5hHd # lL6JZCdGXJZ0hY8JAl1vlyjU9tJk+/L9yaQg1/AvaPxzycKe7b35I66IVTuz1W1b # QGpb1iVJEwvh7ZS7H+yg+FuIhIfBG+1E28D5aK0BOahwvzQGZWQ= # =puHB # -----END PGP SIGNATURE----- # gpg: Signature made Wed 06 Mar 2024 09:45:27 AM EST # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
2024-03-06powerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOVGaurav Batra
[ Upstream commit 09a3c1e46142199adcee372a420b024b4fc61051 ] When kdump kernel tries to copy dump data over SR-IOV, LPAR panics due to NULL pointer exception: Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc000000020847ad4 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12 Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries NIP: c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c REGS: c000000029162ca0 TRAP: 0300 Not tainted (6.4.0-Test102+) MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 48288244 XER: 00000008 CFAR: c00000002083b2d8 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1 ... NIP _find_next_zero_bit+0x24/0x110 LR bitmap_find_next_zero_area_off+0x5c/0xe0 Call Trace: dev_printk_emit+0x38/0x48 (unreliable) iommu_area_alloc+0xc4/0x180 iommu_range_alloc+0x1e8/0x580 iommu_alloc+0x60/0x130 iommu_alloc_coherent+0x158/0x2b0 dma_iommu_alloc_coherent+0x3c/0x50 dma_alloc_attrs+0x170/0x1f0 mlx5_cmd_init+0xc0/0x760 [mlx5_core] mlx5_function_setup+0xf0/0x510 [mlx5_core] mlx5_init_one+0x84/0x210 [mlx5_core] probe_one+0x118/0x2c0 [mlx5_core] local_pci_probe+0x68/0x110 pci_call_probe+0x68/0x200 pci_device_probe+0xbc/0x1a0 really_probe+0x104/0x540 __driver_probe_device+0xb4/0x230 driver_probe_device+0x54/0x130 __driver_attach+0x158/0x2b0 bus_for_each_dev+0xa8/0x130 driver_attach+0x34/0x50 bus_add_driver+0x16c/0x300 driver_register+0xa4/0x1b0 __pci_register_driver+0x68/0x80 mlx5_init+0xb8/0x100 [mlx5_core] do_one_initcall+0x60/0x300 do_init_module+0x7c/0x2b0 At the time of LPAR dump, before kexec hands over control to kdump kernel, DDWs (Dynamic DMA Windows) are scanned and added to the FDT. For the SR-IOV case, default DMA window "ibm,dma-window" is removed from the FDT and DDW added, for the device. Now, kexec hands over control to the kdump kernel. When the kdump kernel initializes, PCI busses are scanned and IOMMU group/tables created, in pci_dma_bus_setup_pSeriesLP(). For the SR-IOV case, there is no "ibm,dma-window". The original commit: b1fc44eaa9ba, fixes the path where memory is pre-mapped (direct mapped) to the DDW. When TCEs are direct mapped, there is no need to initialize IOMMU tables. iommu_table_setparms_lpar() only considers "ibm,dma-window" property when initiallizing IOMMU table. In the scenario where TCEs are dynamically allocated for SR-IOV, newly created IOMMU table is not initialized. Later, when the device driver tries to enter TCEs for the SR-IOV device, NULL pointer execption is thrown from iommu_area_alloc(). The fix is to initialize the IOMMU table with DDW property stored in the FDT. There are 2 points to remember: 1. For the dedicated adapter, kdump kernel would encounter both default and DDW in FDT. In this case, DDW property is used to initialize the IOMMU table. 2. A DDW could be direct or dynamic mapped. kdump kernel would initialize IOMMU table and mark the existing DDW as "dynamic". This works fine since, at the time of table initialization, iommu_table_clear() makes some space in the DDW, for some predefined number of TCEs which are needed for kdump to succeed. Fixes: b1fc44eaa9ba ("pseries/iommu/ddw: Fix kdump to work in absence of ibm,dma-window") Signed-off-by: Gaurav Batra <gbatra@linux.vnet.ibm.com> Reviewed-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240125203017.61014-1-gbatra@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-27Merge branch 'v6.1/standard/base' into v6.1/standard/preempt-rt/baseBruce Ashfield
2024-02-27Subject: [PATCH v6.1] powerpc: drop duplicate entry in Makefile for lib dirPaul Gortmaker
We have two copies of "crtsavres: fixups for 5.4+" - presumably because it is a commit with lots of whitespace in the context that will loosely match in several places, leading to easily but inadvertently applying it more than once. In the v6.1/standard/base we have the following SHAs: commit 77fa1b70cdbdf9c846592a8f7bdf4873b8cba9f9 commit cd107e4edd5f798689074cd08845db78e8834f13 The v5.10 and v5.15 did not have the duplicated v5.4 content, and the v6.5 code base seems to have sensibly dropped the old fixup entirely. The duplicated lines are obvious in the context of this fixup, and leads to the following: arch/powerpc/Makefile:383: warning: overriding recipe for target 'arch/powerpc/lib/crtsavres.o' Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
2024-02-26Merge branch 'v6.1/standard/base' into v6.1/standard/preempt-rt/baseBruce Ashfield
2024-02-26Merge tag 'v6.1.79' into v6.1/standard/baseBruce Ashfield
This is the 6.1.79 stable release # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmXYU4wACgkQONu9yGCS # aT6fBBAAvlSP+o5z7nHxlIVdTcKsp5/25CjpbkBjxk8DxzxQUDJt3Mgsx8WKMS4I # sqgS7xDvqwdZMt04SjDivUrMTxlHnOefEk51SpOBYYfQpc/nxj6Hd5T9cFdwDvzc # /m+L6p6D9p2fcBwNzxERSSG5xrYvtyiWADgc8BxxIUpMVQzZuMyvDdIbPdSJPK20 # kex+bZjXpZEKPUyloeYYujWc/t+Ec88GAk52yX3sk3iZrp5MwOMLZHdu8Fgy5Rou # 0ScNoUvRq4qB/up7LTJJ4y14/hJStZVDJJWD3w9D0cy3ShcWmOx3PZm0NHmInteI # iRu4wNclVCXx882s7x18ECsosb1SsQr0lSzEfzSkdCzw0YFtpGf10zH5SdH0bAzw # 9iopEFx1OPG8jAj6tyMvApN3FmuwEBcznYlLqsmuW6oIALQjKLf0KUwrE+cDk+eA # xuLNePOO5DHnlYiHY4GIufBL5urGOXPDGcMQs9bNJLvx8ny8ghmoQ0nzP5XVBDxn # vDgjop5g7B/Y8Bqh1bj3+W7VRunTQz8fmO81vInPagsRTOVmZHTO3NE1Du70ri0I # eoVmI4n9WXKLigwPhpJl2R/w+oCGQKgAnzBThM0zZHZJskznWFzGiFPMUeoB3tvX # ApVfFEh6rWLYGtM0y4XonHOSY+xqi6fS+pX+QcAFZoWe3czrqBQ= # =4CV+ # -----END PGP SIGNATURE----- # gpg: Signature made Fri 23 Feb 2024 03:13:00 AM EST # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
2024-02-23powerpc/pseries: fix accuracy of stolen timeShrikanth Hegde
commit cbecc9fcbbec60136b0180ba0609c829afed5c81 upstream. powerVM hypervisor updates the VPA fields with stolen time data. It currently reports enqueue_dispatch_tb and ready_enqueue_tb for this purpose. In linux these two fields are used to report the stolen time. The VPA fields are updated at the TB frequency. On powerPC its mostly set at 512Mhz. Hence this needs a conversion to ns when reporting it back as rest of the kernel timings are in ns. This conversion is already handled in tb_to_ns function. So use that function to report accurate stolen time. Observed this issue and used an Capped Shared Processor LPAR(SPLPAR) to simplify the experiments. In all these cases, 100% VP Load is run using stress-ng workload. Values of stolen time is in percentages as reported by mpstat. With the patch values are close to expected. 6.8.rc1 +Patch 12EC/12VP 0.0 0.0 12EC/24VP 25.7 50.2 12EC/36VP 37.3 69.2 12EC/48VP 38.5 78.3 Fixes: 0e8a63132800 ("powerpc/pseries: Implement CONFIG_PARAVIRT_TIME_ACCOUNTING") Cc: stable@vger.kernel.org # v6.1+ Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240213052635.231597-1-sshegde@linux.ibm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-23powerpc/cputable: Add missing PPC_FEATURE_BOOKE on PPC64 Book-EDavid Engraf
commit eb6d871f4ba49ac8d0537e051fe983a3a4027f61 upstream. Commit e320a76db4b0 ("powerpc/cputable: Split cpu_specs[] out of cputable.h") moved the cpu_specs to separate header files. Previously PPC_FEATURE_BOOKE was enabled by CONFIG_PPC_BOOK3E_64. The definition in cpu_specs_e500mc.h for PPC64 no longer enables PPC_FEATURE_BOOKE. This breaks user space reading the ELF hwcaps and expect PPC_FEATURE_BOOKE. Debugging an application with gdb is no longer working on e5500/e6500 because the 64-bit detection relies on PPC_FEATURE_BOOKE for Book-E. Fixes: e320a76db4b0 ("powerpc/cputable: Split cpu_specs[] out of cputable.h") Cc: stable@vger.kernel.org # v6.1+ Signed-off-by: David Engraf <david.engraf@sysgo.com> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240207092758.1058893-1-david.engraf@sysgo.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-23powerpc/64: Set task pt_regs->link to the LR value on scv entryNaveen N Rao
commit aad98efd0b121f63a2e1c221dcb4d4850128c697 upstream. Nysal reported that userspace backtraces are missing in offcputime bcc tool. As an example: $ sudo ./bcc/tools/offcputime.py -uU Tracing off-CPU time (us) of user threads by user stack... Hit Ctrl-C to end. ^C write - python (9107) 8 write - sudo (9105) 9 mmap - python (9107) 16 clock_nanosleep - multipathd (697) 3001604 The offcputime bcc tool attaches a bpf program to a kprobe on finish_task_switch(), which is usually hit on a syscall from userspace. With the switch to system call vectored, we started setting pt_regs->link to zero. This is because system call vectored behaves like a function call with LR pointing to the system call return address, and with no modification to SRR0/SRR1. The LR value does indicate our next instruction, so it is being saved as pt_regs->nip, and pt_regs->link is being set to zero. This is not a problem by itself, but BPF uses perf callchain infrastructure for capturing stack traces, and that stores LR as the second entry in the stack trace. perf has code to cope with the second entry being zero, and skips over it. However, generic userspace unwinders assume that a zero entry indicates end of the stack trace, resulting in a truncated userspace stack trace. Rather than fixing all userspace unwinders to ignore/skip past the second entry, store the real LR value in pt_regs->link so that there continues to be a valid, though duplicate entry in the stack trace. With this change: $ sudo ./bcc/tools/offcputime.py -uU Tracing off-CPU time (us) of user threads by user stack... Hit Ctrl-C to end. ^C write write [unknown] [unknown] [unknown] [unknown] [unknown] PyObject_VectorcallMethod [unknown] [unknown] PyObject_CallOneArg PyFile_WriteObject PyFile_WriteString [unknown] [unknown] PyObject_Vectorcall _PyEval_EvalFrameDefault PyEval_EvalCode [unknown] [unknown] [unknown] _PyRun_SimpleFileObject _PyRun_AnyFileObject Py_RunMain [unknown] Py_BytesMain [unknown] __libc_start_main - python (1293) 7 write write [unknown] sudo_ev_loop_v1 sudo_ev_dispatch_v1 [unknown] [unknown] [unknown] [unknown] __libc_start_main - sudo (1291) 7 syscall syscall bpf_open_perf_buffer_opts [unknown] [unknown] [unknown] [unknown] _PyObject_MakeTpCall PyObject_Vectorcall _PyEval_EvalFrameDefault PyEval_EvalCode [unknown] [unknown] [unknown] _PyRun_SimpleFileObject _PyRun_AnyFileObject Py_RunMain [unknown] Py_BytesMain [unknown] __libc_start_main - python (1293) 11 clock_nanosleep clock_nanosleep nanosleep sleep [unknown] [unknown] __clone - multipathd (698) 3001661 Fixes: 7fa95f9adaee ("powerpc/64s: system call support for scv/rfscv instructions") Cc: stable@vger.kernel.org Reported-by: "Nysal Jan K.A" <nysal@linux.ibm.com> Signed-off-by: Naveen N Rao <naveen@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240202154316.395276-1-naveen@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-23powerpc/kasan: Limit KASAN thread size increase to 32KBMichael Ellerman
[ Upstream commit f1acb109505d983779bbb7e20a1ee6244d2b5736 ] KASAN is seen to increase stack usage, to the point that it was reported to lead to stack overflow on some 32-bit machines (see link). To avoid overflows the stack size was doubled for KASAN builds in commit 3e8635fb2e07 ("powerpc/kasan: Force thread size increase with KASAN"). However with a 32KB stack size to begin with, the doubling leads to a 64KB stack, which causes build errors: arch/powerpc/kernel/switch.S:249: Error: operand out of range (0x000000000000fe50 is not between 0xffffffffffff8000 and 0x0000000000007fff) Although the asm could be reworked, in practice a 32KB stack seems sufficient even for KASAN builds - the additional usage seems to be in the 2-3KB range for a 64-bit KASAN build. So only increase the stack for KASAN if the stack size is < 32KB. Fixes: 18f14afe2816 ("powerpc/64s: Increase default stack size to 32KB") Reported-by: Spoorthy <spoorthy@linux.ibm.com> Reported-by: Benjamin Gray <bgray@linux.ibm.com> Reviewed-by: Benjamin Gray <bgray@linux.ibm.com> Link: https://lore.kernel.org/linuxppc-dev/bug-207129-206035@https.bugzilla.kernel.org%2F/ Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240212064244.3924505-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-23powerpc/kasan: Fix addr error caused by page alignmentJiangfeng Xiao
[ Upstream commit 4a7aee96200ad281a5cc4cf5c7a2e2a49d2b97b0 ] In kasan_init_region, when k_start is not page aligned, at the begin of for loop, k_cur = k_start & PAGE_MASK is less than k_start, and then `va = block + k_cur - k_start` is less than block, the addr va is invalid, because the memory address space from va to block is not alloced by memblock_alloc, which will not be reserved by memblock_reserve later, it will be used by other places. As a result, memory overwriting occurs. for example: int __init __weak kasan_init_region(void *start, size_t size) { [...] /* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */ block = memblock_alloc(k_end - k_start, PAGE_SIZE); [...] for (k_cur = k_start & PAGE_MASK; k_cur < k_end; k_cur += PAGE_SIZE) { /* at the begin of for loop * block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400) * va(dcd96c00) is less than block(dcd97000), va is invalid */ void *va = block + k_cur - k_start; [...] } [...] } Therefore, page alignment is performed on k_start before memblock_alloc() to ensure the validity of the VA address. Fixes: 663c0c9496a6 ("powerpc/kasan: Fix shadow area set up for modules.") Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/1705974359-43790-1-git-send-email-xiaojiangfeng@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-23work around gcc bugs with 'asm goto' with outputsLinus Torvalds
commit 68fb3ca0e408e00db1c3f8fccdfa19e274c033be upstream. We've had issues with gcc and 'asm goto' before, and we created a 'asm_volatile_goto()' macro for that in the past: see commits 3f0116c3238a ("compiler/gcc4: Add quirk for 'asm goto' miscompilation bug") and a9f180345f53 ("compiler/gcc4: Make quirk for asm_volatile_goto() unconditional"). Then, much later, we ended up removing the workaround in commit 43c249ea0b1e ("compiler-gcc.h: remove ancient workaround for gcc PR 58670") because we no longer supported building the kernel with the affected gcc versions, but we left the macro uses around. Now, Sean Christopherson reports a new version of a very similar problem, which is fixed by re-applying that ancient workaround. But the problem in question is limited to only the 'asm goto with outputs' cases, so instead of re-introducing the old workaround as-is, let's rename and limit the workaround to just that much less common case. It looks like there are at least two separate issues that all hit in this area: (a) some versions of gcc don't mark the asm goto as 'volatile' when it has outputs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98619 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110420 which is easy to work around by just adding the 'volatile' by hand. (b) Internal compiler errors: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110422 which are worked around by adding the extra empty 'asm' as a barrier, as in the original workaround. but the problem Sean sees may be a third thing since it involves bad code generation (not an ICE) even with the manually added 'volatile'. The same old workaround works for this case, even if this feels a bit like voodoo programming and may only be hiding the issue. Reported-and-tested-by: Sean Christopherson <seanjc@google.com> Link: https://lore.kernel.org/all/20240208220604.140859-1-seanjc@google.com/ Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Uros Bizjak <ubizjak@gmail.com> Cc: Jakub Jelinek <jakub@redhat.com> Cc: Andrew Pinski <quic_apinski@quicinc.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-14Merge branch 'v6.1/standard/base' into v6.1/standard/preempt-rt/baseBruce Ashfield
2024-02-14Merge tag 'v6.1.77' into v6.1/standard/baseBruce Ashfield
This is the 6.1.77 stable release # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmXBQVYACgkQONu9yGCS # aT7nDA//Wh7+Y4VyYjHh+aYenAfLa6dbD1WvhqbgJ8ReKrMlTQ54cjN67Ws2VoPA # Yg5GdvtKCi7LYHuEqzTzbXJ7MIGrBue0NH+415/7ixYToJLagrt94jTN5bGxxntt # mxBsRLc9eInhFxk8zOJdJGHo2A/twTvCVvMGmIeBl3iIxbEYtG1Ho09NLa++Td0L # okhXfDdt5zhqef0GvqUjDqxmaP5Ua0hl848BH4FiKFF6asoagLJqH4c8xbZrVuRH # xHjHP+aA/bJDdVw0QVh8DY4qmFCcSR9ANDnBUtz2KIgE2jg+js4L6HGDbHJ+Qrgl # yMcYpxkT62ujSJ18XZR6ZQOSLVjOhIzqddgwm28X1Tnah71Qz/prpBPRBFy/SJx6 # BB4aZhWk2eflZHQ30OGAvSmcljikXLAJOUgU7Pmr8ttEQ/Sb5vPAQDnm9kJ9nLxN # HtLhLMFUOhs6nO+wlZCKFTyX/OhZukWnN1inGEKZXAeePq41Jh9ZnJErfnkeq+Dk # NVgf8XPxzo54X91JsX/G093BQ0eEZppBtP6bLzlcOSbAys9bdlTLuDqW0mQ/6XGh # xhO0OgfvsEEja+RDNKOTFMir+/iLiQmmK7TrOvnMxUJLS3ekQ6ej+Bo7RjWWpkJT # 2cnXtmByjaEwzJEKn+RnPFwib1hhkw2P0z0qIPLNNfAK4R+w5SI= # =wn4i # -----END PGP SIGNATURE----- # gpg: Signature made Mon 05 Feb 2024 03:13:10 PM EST # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
2024-02-06Merge branch 'v6.1/standard/base' into v6.1/standard/preempt-rt/baseBruce Ashfield
2024-02-06Merge tag 'v6.1.76' into v6.1/standard/baseBruce Ashfield
This is the 6.1.76 stable release # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmW64xYACgkQONu9yGCS # aT7kVA/+KKlE3UFuGmV1ZmiHagHF+oRZKSk9m97F5zgfAcEHAcTnnuikzvJHuepU # 4hPMsH+tTXafOJLh81bv7IH3RhHtvmQZPQyWUw7ysY9ms/7CZxjkuirxLWI3evUG # lre7OiApyOPkxERBfA5f9r2D1ufXC742xcAdaXrn+GSZd4nuId5f0IbHmfdNv/MV # zTt6+0qRU3TMpsUdqp0rIm/0KUXtopCDFf2fI/lIImAvN2onuiqDy+TC0FJ0ErTQ # C3wTEi1j9u6l3AO51OYm57TbKj/KmVOcQdcQyskHGHbB+7nS9z29LXQyorRUKqkv # KTs739kgG8GH0ZegTwPVPCx5t1SBzy8fuzI2c2MMVfNCT6rWJVS7brzeb7zDLuRT # 9pSr9MnoQNYMhJ3IlPvgPHKwvpP4t2el7Z8noVTRXHDjrkC238gloHwvH78/b2ao # bXO3DRKTzB4Vv/Q8YUPFmj5fhPqz5lnK6idr4r72JSlzfjxtYoPAKwYihDGxmeLN # mWikAPepLqoGg/P2ztKhV/fL9TVhJB+d2YM5op/b+pUxZtYdiJODefFF1ebBbF34 # sRG12htP7GV/MTkxC7Yu0h3vS3HWVHugHMBIXXUnqlOANMUbyAMEQW+xkdS/W5bd # QnowcQr+DT1A5b9P1bYXB7efNiHENxo/jvuJTrzZmLioy1MPqeE= # =219k # -----END PGP SIGNATURE----- # gpg: Signature made Wed 31 Jan 2024 07:17:26 PM EST # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
generated by cgit 1.2.3-korg (git 2.39.0) at 2024-07-05 06:20:59 +0000