- Jul 11, 2023
-
-
Olga Kornievskaia authored
[ Upstream commit c907e72f ] When the client received NFS4ERR_BADSESSION, it schedules recovery and start the state manager thread which in turn freezes the session table and does not allow for any new requests to use the no-longer valid session. However, it is possible that before the state manager thread runs, a new operation would use the released slot that received BADSESSION and was therefore not updated its sequence number. Such re-use of the slot can lead the application errors. Fixes: 5c441544 ("NFSv4.x: Handle bad/dead sessions correctly in nfs41_sequence_process()") Signed-off-by:
Olga Kornievskaia <kolga@netapp.com> Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Qi Zheng authored
[ Upstream commit 7f7ab336 ] Currently, the list_lru::shrinker_id corresponding to the nfs4_xattr shrinkers is wrong: >>> prog["nfs4_xattr_cache_lru"].shrinker_id (int)0 >>> prog["nfs4_xattr_entry_lru"].shrinker_id (int)0 >>> prog["nfs4_xattr_large_entry_lru"].shrinker_id (int)0 >>> prog["nfs4_xattr_cache_shrinker"].id (int)18 >>> prog["nfs4_xattr_entry_shrinker"].id (int)19 >>> prog["nfs4_xattr_large_entry_shrinker"].id (int)20 This is not what we expect, which will cause these shrinkers not to be found in shrink_slab_memcg(). We should assign shrinker::id before calling list_lru_init_memcg(), so that the corresponding list_lru::shrinker_id will be assigned the correct value like below: >>> prog["nfs4_xattr_cache_lru"].shrinker_id (int)16 >>> prog["nfs4_xattr_entry_lru"].shrinker_id (int)17 >>> prog["nfs4_xattr_large_entry_lru"].shrinker_id (int)18 >>> prog["nfs4_xattr_cache_shrinker"].id (int)16 >>> prog["nfs4_xattr_entry_shrinker"].id (int)17 >>> prog["nfs4_xattr_large_entry_shrinker"].id (int)18 So just do it. Fixes: 95ad37f9 ("NFSv4.2: add client side xattr caching.") Signed-off-by:
Qi Zheng <zhengqi.arch@bytedance.com> Signed-off-by:
-
Hareshx Sankar Raj authored
[ Upstream commit d776b254 ] The callback function for RSA frees the memory allocated for the source and destination buffers before unmapping them. This sequence is wrong. Change the cleanup sequence to unmap the buffers before freeing them. Fixes: 3dfaf007 ("crypto: qat - remove dma_free_coherent() for RSA") Signed-off-by:
Hareshx Sankar Raj <hareshx.sankar.raj@intel.com> Co-developed-by:
Bolemx Sivanagaleela <bolemx.sivanagaleela@intel.com> Signed-off-by:
Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Hareshx Sankar Raj authored
[ Upstream commit eb7713f5 ] The callback function for DH frees the memory allocated for the destination buffer before unmapping it. This sequence is wrong. Change the cleanup sequence to unmap the buffer before freeing it. Fixes: 029aa462 ("crypto: qat - remove dma_free_coherent() for DH") Signed-off-by:
-
Masahiro Yamada authored
[ Upstream commit 92e2921e ] ASM_NL is useful not only in *.S files but also in .c files for using inline assembler in C code. On ARC, however, ASM_NL is evaluated inconsistently. It is expanded to a backquote (`) in *.S files, but a semicolon (;) in *.c files because arch/arc/include/asm/linkage.h defines it inside #ifdef __ASSEMBLY__, so the definition for C code falls back to the default value defined in include/linux/linkage.h. If ASM_NL is used in inline assembler in .c files, it will result in wrong assembly code because a semicolon is not an instruction separator, but the start of a comment for ARC. Move ASM_NL (also __ALIGN and __ALIGN_STR) out of the #ifdef. Fixes: 9df62f05 ("arch: use ASM_NL instead of ';' for assembler new line character in the macro") Fixes: 8d92e992 ("ARC: define __ALIGN_STR and __ALIGN symbols for ARC") Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 3a3f1e57 ] The > comparison should be >= to prevent an out of bounds array access. Fixes: 52dc0595 ("modpost: handle relocations mismatch in __ex_table.") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by:
-
Stephan Müller authored
[ Upstream commit d2365976 ] With the update of the permanent and intermittent health errors, the actual indicator for the health test indicates a potential error only for the one offending time stamp gathered in the current iteration round. The next iteration round will "overwrite" the health test result. Thus, the entropy collection loop in jent_gen_entropy checks for the health test failure upon each loop iteration. However, the initialization operation checked for the APT health test once for an APT window which implies it would not catch most errors. Thus, the check for all health errors is now invoked unconditionally during each loop iteration for the startup test. With the change, the error JENT_ERCT becomes unused as all health errors are only reported with the JENT_HEALTH return code. This allows the removal of the error indicator. Fixes: 3fde2fe9 ("crypto: jitter - permanent and intermittent health errors" ) Reported-by:
Joachim Vandersmissen <git@jvdsn.com> Signed-off-by:
Stephan Mueller <smueller@chronox.de> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit efbc7764 ] Commit df8fc4e9 ("kbuild: Enable -fstrict-flex-arrays=3") uncovered a type mismatch in cesa 3des support that leads to a memcpy beyond the end of a structure: In function 'fortify_memcpy_chk', inlined from 'mv_cesa_des3_ede_setkey' at drivers/crypto/marvell/cesa/cipher.c:307:2: include/linux/fortify-string.h:583:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 583 | __write_overflow_field(p_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is probably harmless as the actual data that is copied has the correct type, but clearly worth fixing nonetheless. Fixes: 4ada4839 ("crypto: marvell/cesa - add Triple-DES support") Cc: Kees Cook <keescook@chromium.org> Cc: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Masahiro Yamada authored
[ Upstream commit 56a24b8c ] addend_arm_rel() processes R_ARM_PC24, R_ARM_CALL, R_ARM_JUMP24 in a wrong way. Here, test code. [test code for R_ARM_JUMP24] .section .init.text,"ax" bar: bx lr .section .text,"ax" .globl foo foo: b bar [test code for R_ARM_CALL] .section .init.text,"ax" bar: bx lr .section .text,"ax" .globl foo foo: push {lr} bl bar pop {pc} If you compile it with ARM multi_v7_defconfig, modpost will show the symbol name, (unknown). WARNING: modpost: vmlinux.o: section mismatch in reference: foo (section: .text) -> (unknown) (section: .init.text) (You need to use GNU linker instead of LLD to reproduce it.) Fix the code to make modpost show the correct symbol name. I imported (with adjustment) sign_extend32() from include/linux/bitops.h. The '+8' is the compensation for pc-relative instruction. It is documented in "ELF for the Arm Architecture" [1]. "If the relocation is pc-relative then compensation for the PC bias (the PC value is 8 bytes ahead of the executing instruction in Arm state and 4 bytes in Thumb state) must be encoded in the relocation by the object producer." [1]: https://github.com/ARM-software/abi-aa/blob/main/aaelf32/aaelf32.rst Fixes: 56a974fa ("kbuild: make better section mismatch reports on arm") Fixes: 6e2e340b ("ARM: 7324/1: modpost: Fix section warnings for ARM for many compilers") Signed-off-by:
-
Masahiro Yamada authored
[ Upstream commit b7c63520 ] addend_arm_rel() processes R_ARM_ABS32 in a wrong way. Here, test code. [test code 1] #include <linux/init.h> int __initdata foo; int get_foo(void) { return foo; } If you compile it with ARM versatile_defconfig, modpost will show the symbol name, (unknown). WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> (unknown) (section: .init.data) (You need to use GNU linker instead of LLD to reproduce it.) If you compile it for other architectures, modpost will show the correct symbol name. WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> foo (section: .init.data) For R_ARM_ABS32, addend_arm_rel() sets r->r_addend to a wrong value. I just mimicked the code in arch/arm/kernel/module.c. However, there is more difficulty for ARM. Here, test code. [test code 2] #include <linux/init.h> int __initdata foo; int get_foo(void) { return foo; } int __initdata bar; int get_bar(void) { return bar; } With this commit applied, modpost will show the following messages for ARM versatile_defconfig: WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> foo (section: .init.data) WARNING: modpost: vmlinux.o: section mismatch in reference: get_bar (section: .text) -> foo (section: .init.data) The reference from 'get_bar' to 'foo' seems wrong. I have no solution for this because it is true in assembly level. In the following output, relocation at 0x1c is no longer associated with 'bar'. The two relocation entries point to the same symbol, and the offset to 'bar' is encoded in the instruction 'r0, [r3, #4]'. Disassembly of section .text: 00000000 <get_foo>: 0: e59f3004 ldr r3, [pc, #4] @ c <get_foo+0xc> 4: e5930000 ldr r0, [r3] 8: e12fff1e bx lr c: 00000000 .word 0x00000000 00000010 <get_bar>: 10: e59f3004 ldr r3, [pc, #4] @ 1c <get_bar+0xc> 14: e5930004 ldr r0, [r3, #4] 18: e12fff1e bx lr 1c: 00000000 .word 0x00000000 Relocation section '.rel.text' at offset 0x244 contains 2 entries: Offset Info Type Sym.Value Sym. Name 0000000c 00000c02 R_ARM_ABS32 00000000 .init.data 0000001c 00000c02 R_ARM_ABS32 00000000 .init.data When find_elf_symbol() gets into a situation where relsym->st_name is zero, there is no guarantee to get the symbol name as written in C. I am keeping the current logic because it is useful in many architectures, but the symbol name is not always correct depending on the optimization. I left some comments in find_tosym(). Fixes: 56a974fa ("kbuild: make better section mismatch reports on arm") Signed-off-by:
-
Randy Dunlap authored
[ Upstream commit b04b076f ] Fix build warnings when DEBUG_FS is not enabled by using an empty do-while loop instead of a value: In file included from ../drivers/crypto/nx/nx.c:27: ../drivers/crypto/nx/nx.c: In function 'nx_register_algs': ../drivers/crypto/nx/nx.h:173:33: warning: statement with no effect [-Wunused-value] 173 | #define NX_DEBUGFS_INIT(drv) (0) ../drivers/crypto/nx/nx.c:573:9: note: in expansion of macro 'NX_DEBUGFS_INIT' 573 | NX_DEBUGFS_INIT(&nx_driver); ../drivers/crypto/nx/nx.c: In function 'nx_remove': ../drivers/crypto/nx/nx.h:174:33: warning: statement with no effect [-Wunused-value] 174 | #define NX_DEBUGFS_FINI(drv) (0) ../drivers/crypto/nx/nx.c:793:17: note: in expansion of macro 'NX_DEBUGFS_FINI' 793 | NX_DEBUGFS_FINI(&nx_driver); Also, there is no need to build nx_debugfs.o when DEBUG_FS is not enabled, so change the Makefile to accommodate that. Fixes: ae0222b7 ("powerpc/crypto: nx driver code supporting nx encryption") Fixes: aef7b31c ("powerpc/crypto: Build files for the nx device driver") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Breno Leitão <leitao@debian.org> Cc: Nayna Jain <nayna@linux.ibm.com> Cc: Paulo Flabiano Smorigo <pfsmorigo@gmail.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: linux-crypto@vger.kernel.org Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by:
-
Masahiro Yamada authored
[ Upstream commit d0acc76a ] find_extable_entry_size() is completely broken. It has awesome comments about how to calculate sizeof(struct exception_table_entry). It was based on these assumptions: - struct exception_table_entry has two fields - both of the fields have the same size Then, we came up with this equation: (offset of the second field) * 2 == (size of struct) It was true for all architectures when commit 52dc0595 ("modpost: handle relocations mismatch in __ex_table.") was applied. Our mathematics broke when commit 548acf19 ("x86/mm: Expand the exception table logic to allow new handling options") introduced the third field. Now, the definition of exception_table_entry is highly arch-dependent. For x86, sizeof(struct exception_table_entry) is apparently 12, but find_extable_entry_size() sets extable_entry_size to 8. I could fix it, but I do not see much value in this code. extable_entry_size is used just for selecting a slightly different error message. If the first field ("insn") references to a non-executable section, The relocation at %s+0x%lx references section "%s" which is not executable, IOW it is not possible for the kernel to fault at that address. Something is seriously wrong and should be fixed. If the second field ("fixup") references to a non-executable section, The relocation at %s+0x%lx references section "%s" which is not executable, IOW the kernel will fault if it ever tries to jump to it. Something is seriously wrong and should be fixed. Merge the two error messages rather than adding even more complexity. Change fatal() to error() to make it continue running and catch more possible errors. Fixes: 548acf19 ("x86/mm: Expand the exception table logic to allow new handling options") Signed-off-by:
-
Herbert Xu authored
[ Upstream commit ac52578d ] The virtio rng device kicks off a new entropy request whenever the data available reaches zero. When a new request occurs at the end of a read operation, that is, when the result of that request is only needed by the next reader, then there is a race between the writing of the new data and the next reader. This is because there is no synchronisation whatsoever between the writer and the reader. Fix this by writing data_avail with smp_store_release and reading it with smp_load_acquire when we first enter read. The subsequent reads are safe because they're either protected by the first load acquire, or by the completion mechanism. Also remove the redundant zeroing of data_idx in random_recv_done (data_idx must already be zero at this point) and data_avail in request_entropy (ditto). Reported-by:
<syzbot+726dc8c62c3536431ceb@syzkaller.appspotmail.com> Fixes: f7f510ec ("virtio: An entropy device, as suggested by hpa.") Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Eric Farman authored
[ Upstream commit ff598081 ] The pointer to mdev_bus_compat_class is statically defined at the top of mdev_core, and was originally (commit 7b96953b ("vfio: Mediated device Core driver") serialized by the parent_list_lock. The blamed commit removed this mutex, leaving the pointer initialization unserialized. As a result, the creation of multiple MDEVs in parallel (such as during boot) can encounter errors during the creation of the sysfs entries, such as: [ 8.337509] sysfs: cannot create duplicate filename '/class/mdev_bus' [ 8.337514] vfio_ccw 0.0.01d8: MDEV: Registered [ 8.337516] CPU: 13 PID: 946 Comm: driverctl Not tainted 6.4.0-rc7 #20 [ 8.337522] Hardware name: IBM 3906 M05 780 (LPAR) [ 8.337525] Call Trace: [ 8.337528] [<0000000162b0145a>] dump_stack_lvl+0x62/0x80 [ 8.337540] [<00000001622aeb30>] sysfs_warn_dup+0x78/0x88 [ 8.337549] [<00000001622aeca6>] sysfs_create_dir_ns+0xe6/0xf8 [ 8.337552] [<0000000162b04504>] kobject_add_internal+0xf4/0x340 [ 8.337557] [<0000000162b04d48>] kobject_add+0x78/0xd0 [ 8.337561] [<0000000162b04e0a>] kobject_create_and_add+0x6a/0xb8 [ 8.337565] [<00000001627a110e>] class_compat_register+0x5e/0x90 [ 8.337572] [<000003ff7fd815da>] mdev_register_parent+0x102/0x130 [mdev] [ 8.337581] [<000003ff7fdc7f2c>] vfio_ccw_sch_probe+0xe4/0x178 [vfio_ccw] [ 8.337588] [<0000000162a7833c>] css_probe+0x44/0x80 [ 8.337599] [<000000016279f4da>] really_probe+0xd2/0x460 [ 8.337603] [<000000016279fa08>] driver_probe_device+0x40/0xf0 [ 8.337606] [<000000016279fb78>] __device_attach_driver+0xc0/0x140 [ 8.337610] [<000000016279cbe0>] bus_for_each_drv+0x90/0xd8 [ 8.337618] [<00000001627a00b0>] __device_attach+0x110/0x190 [ 8.337621] [<000000016279c7c8>] bus_rescan_devices_helper+0x60/0xb0 [ 8.337626] [<000000016279cd48>] drivers_probe_store+0x48/0x80 [ 8.337632] [<00000001622ac9b0>] kernfs_fop_write_iter+0x138/0x1f0 [ 8.337635] [<00000001621e5e14>] vfs_write+0x1ac/0x2f8 [ 8.337645] [<00000001621e61d8>] ksys_write+0x70/0x100 [ 8.337650] [<0000000162b2bdc4>] __do_syscall+0x1d4/0x200 [ 8.337656] [<0000000162b3c828>] system_call+0x70/0x98 [ 8.337664] kobject: kobject_add_internal failed for mdev_bus with -EEXIST, don't try to register things with the same name in the same directory. [ 8.337668] kobject: kobject_create_and_add: kobject_add error: -17 [ 8.337674] vfio_ccw: probe of 0.0.01d9 failed with error -12 [ 8.342941] vfio_ccw_mdev aeb9ca91-10c6-42bc-a168-320023570aea: Adding to iommu group 2 Move the initialization of the mdev_bus_compat_class pointer to the init path, to match the cleanup in module exit. This way the code in mdev_register_parent() can simply link the new parent to it, rather than determining whether initialization is required first. Fixes: 89345d51 ("vfio/mdev: embedd struct mdev_parent in the parent data structure") Reported-by:
Alexander Egorenkov <egorenar@linux.ibm.com> Signed-off-by:
Eric Farman <farman@linux.ibm.com> Reviewed-by:
Kevin Tian <kevin.tian@intel.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by:
Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20230626133642.2939168-1-farman@linux.ibm.com Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Xinghui Li authored
[ Upstream commit 0c0206dc ] The ret variable in the vmd_enable_domain() function was used uninitialized when printing a warning message upon failure of the pci_reset_bus() function. Thus, fix the issue by assigning ret with the value returned from pci_reset_bus() before referencing it in the warning message. This was detected by Smatch: drivers/pci/controller/vmd.c:931 vmd_enable_domain() error: uninitialized symbol 'ret'. [kwilczynski: drop the second patch from the series, add missing reported by tag, commit log] Fixes: 0a584655 ("PCI: vmd: Fix secondary bus reset for Intel bridges") Link: https://lore.kernel.org/all/202305270219.B96IiIfv-lkp@intel.com Link: https://lore.kernel.org/linux-pci/20230420094332.1507900-2-korantwork@gmail.com Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
Xinghui Li <korantli@tencent.com> Signed-off-by:
Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by:
Nirmal Patel <nirmal.patel@linux.intel.com> Signed-off-by:
-
Yoshihiro Shimoda authored
[ Upstream commit 880d51c7 ] In pci_epf_test_init_dma_chan() epf_test->dma_chan_rx is assigned from dma_request_channel() with DMA_DEV_TO_MEM as filter.dma_mask. However, in pci_epf_test_data_transfer() if the dir is DMA_DEV_TO_MEM, epf->dma_chan_rx should be used but instead we are using epf_test->dma_chan_tx. Fix it. Link: https://lore.kernel.org/r/20230412063447.2841177-1-yoshihiro.shimoda.uh@renesas.com Fixes: 8353813c ("PCI: endpoint: Enable DMA tests for endpoints with DMA capabilities") Tested-by:
Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Lorenzo Pieralisi <lpieralisi@kernel.org> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Frank Li <Frank.Li@nxp.com> Signed-off-by:
-
Shunsuke Mie authored
[ Upstream commit 37587673 ] vNTB driver and NTB driver have same Kconfig prompt. Changed to make it distinguishable. Link: https://lore.kernel.org/r/20230202103832.2038286-1-mie@igel.co.jp Fixes: e35f56bb ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by:
Shunsuke Mie <mie@igel.co.jp> Signed-off-by:
Manivannan Sadhasivam <mani@kernel.org> Signed-off-by:
-
Namhyung Kim authored
[ Upstream commit e4ef3ef1 ] The task-analyzer.py script (actually every other scripts too) requires PERF_EXEC_PATH env to find dependent libraries and scripts. For scripts test to run correctly, it needs to set PERF_EXEC_PATH to the perf tool source directory. Instead of blindly update the env, let's check the directory structure to make sure it points to the correct location. Fixes: e8478b84 ("perf test: add new task-analyzer tests") Cc: Petar Gligoric <petar.gligoric@rohde-schwarz.com> Cc: Hagen Paul Pfeifer <hagen@jauu.net> Cc: Aditya Gupta <adityag@linux.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Ingo Molnar <mingo@kernel.org> Acked-by:
Ian Rogers <irogers@google.com> Signed-off-by:
Namhyung Kim <namhyung@kernel.org> Signed-off-by:
-
Aneesh Kumar K.V authored
[ Upstream commit c8eebc4a ] Without this fix, the last subsection vmemmap can end up in memory even if the namespace is created with -M mem and has sufficient space in the altmap area. Fixes: cf387d96 ("libnvdimm/altmap: Track namespace boundaries in altmap") Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Tested-by:
Sachin Sant <sachinp@linux.ibm.com <mailto:sachinp@linux.ibm.com>> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230616110826.344417-6-aneesh.kumar@linux.ibm.com Signed-off-by:
-
Aneesh Kumar K.V authored
[ Upstream commit 0da90af4 ] On memory unplug reduce DirectMap page count correctly. root@ubuntu-guest:# grep Direct /proc/meminfo DirectMap4k: 0 kB DirectMap64k: 0 kB DirectMap2M: 115343360 kB DirectMap1G: 0 kB Before fix: root@ubuntu-guest:# ndctl disable-namespace all disabled 1 namespace root@ubuntu-guest:# grep Direct /proc/meminfo DirectMap4k: 0 kB DirectMap64k: 0 kB DirectMap2M: 115343360 kB DirectMap1G: 0 kB After fix: root@ubuntu-guest:# ndctl disable-namespace all disabled 1 namespace root@ubuntu-guest:# grep Direct /proc/meminfo DirectMap4k: 0 kB DirectMap64k: 0 kB DirectMap2M: 104857600 kB DirectMap1G: 0 kB Fixes: a2dc009a ("powerpc/mm/book3s/radix: Add mapping statistics") Signed-off-by:
-
Tiezhu Yang authored
[ Upstream commit 58b1294d ] thread.bad_cause is saved in arch_uprobe_pre_xol(), it should be restored in arch_uprobe_{post,abort}_xol() accordingly, otherwise the save operation is meaningless, this change is similar with x86 and powerpc. Signed-off-by:
Tiezhu Yang <yangtiezhu@loongson.cn> Acked-by:
Oleg Nesterov <oleg@redhat.com> Reviewed-by:
Guo Ren <guoren@kernel.org> Fixes: 74784081 ("riscv: Add uprobes supported") Link: https://lore.kernel.org/r/1682214146-3756-1-git-send-email-yangtiezhu@loongson.cn Signed-off-by:
Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by:
-
Xi Pardee authored
[ Upstream commit 9682cfd1 ] Fix the IP name errors in the register maps used by the following debugfs attributes in the Meteor Lake SOC-M PMC. pfear_sts lpm_sts ltr_show Fixes: c5ad454a ("platform/x86: intel/pmc/core: Add Meteor Lake support to pmc core driver") Signed-off-by:
Xi Pardee <xi.pardee@intel.com> Signed-off-by:
Rajvi Jingar <rajvi.jingar@linux.intel.com> Reviewed-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20230613225347.2720665-2-rajvi.jingar@linux.intel.com Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Aditya Gupta authored
[ Upstream commit b684c09f ] ppc_save_regs() skips one stack frame while saving the CPU register states. Instead of saving current R1, it pulls the previous stack frame pointer. When vmcores caused by direct panic call (such as `echo c > /proc/sysrq-trigger`), are debugged with gdb, gdb fails to show the backtrace correctly. On further analysis, it was found that it was because of mismatch between r1 and NIP. GDB uses NIP to get current function symbol and uses corresponding debug info of that function to unwind previous frames, but due to the mismatching r1 and NIP, the unwinding does not work, and it fails to unwind to the 2nd frame and hence does not show the backtrace. GDB backtrace with vmcore of kernel without this patch: --------- (gdb) bt #0 0xc0000000002a53e8 in crash_setup_regs (oldregs=<optimized out>, newregs=0xc000000004f8f8d8) at ./arch/powerpc/include/asm/kexec.h:69 #1 __crash_kexec (regs=<optimized out>) at kernel/kexec_core.c:974 #2 0x0000000000000063 in ?? () #3 0xc000000003579320 in ?? () --------- Further analysis revealed that the mismatch occurred because "ppc_save_regs" was saving the previous stack's SP instead of the current r1. This patch fixes this by storing current r1 in the saved pt_regs. GDB backtrace with vmcore of patched kernel: -------- (gdb) bt #0 0xc0000000002a53e8 in crash_setup_regs (oldregs=0x0, newregs=0xc00000000670b8d8) at ./arch/powerpc/include/asm/kexec.h:69 #1 __crash_kexec (regs=regs@entry=0x0) at kernel/kexec_core.c:974 #2 0xc000000000168918 in panic (fmt=fmt@entry=0xc000000001654a60 "sysrq triggered crash\n") at kernel/panic.c:358 #3 0xc000000000b735f8 in sysrq_handle_crash (key=<optimized out>) at drivers/tty/sysrq.c:155 #4 0xc000000000b742cc in __handle_sysrq (key=key@entry=99, check_mask=check_mask@entry=false) at drivers/tty/sysrq.c:602 #5 0xc000000000b7506c in write_sysrq_trigger (file=<optimized out>, buf=<optimized out>, count=2, ppos=<optimized out>) at drivers/tty/sysrq.c:1163 #6 0xc00000000069a7bc in pde_write (ppos=<optimized out>, count=<optimized out>, buf=<optimized out>, file=<optimized out>, pde=0xc00000000362cb40) at fs/proc/inode.c:340 #7 proc_reg_write (file=<optimized out>, buf=<optimized out>, count=<optimized out>, ppos=<optimized out>) at fs/proc/inode.c:352 #8 0xc0000000005b3bbc in vfs_write (file=file@entry=0xc000000006aa6b00, buf=buf@entry=0x61f498b4f60 <error: Cannot access memory at address 0x61f498b4f60>, count=count@entry=2, pos=pos@entry=0xc00000000670bda0) at fs/read_write.c:582 #9 0xc0000000005b4264 in ksys_write (fd=<optimized out>, buf=0x61f498b4f60 <error: Cannot access memory at address 0x61f498b4f60>, count=2) at fs/read_write.c:637 #10 0xc00000000002ea2c in system_call_exception (regs=0xc00000000670be80, r0=<optimized out>) at arch/powerpc/kernel/syscall.c:171 #11 0xc00000000000c270 in system_call_vectored_common () at arch/powerpc/kernel/interrupt_64.S:192 -------- Nick adds: So this now saves regs as though it was an interrupt taken in the caller, at the instruction after the call to ppc_save_regs, whereas previously the NIP was there, but R1 came from the caller's caller and that mismatch is what causes gdb's dwarf unwinder to go haywire. Signed-off-by:
Aditya Gupta <adityag@linux.ibm.com> Fixes: d16a58f8 ("powerpc: Improve ppc_save_regs()") Reivewed-by:
Nicholas Piggin <npiggin@gmail.com> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit f4f913c9 ] Currently pointer iov is being dereferenced before the null check of iov which can lead to null pointer dereference errors. Fix this by moving the iov null check before the dereferencing. Detected using cppcheck static analysis: linux/arch/powerpc/platforms/powernv/pci-sriov.c:597:12: warning: Either the condition '!iov' is redundant or there is possible null pointer dereference: iov. [nullPointerRedundantCheck] num_vfs = iov->num_vfs; ^ Fixes: 052da31d ("powerpc/powernv/sriov: De-indent setup and teardown") Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
Stanley Chu authored
[ Upstream commit 0fef6bb7 ] In MCQ mode, when a device command uses a hardware queue shared with other commands, a race condition may occur in the following scenario: 1. A device command is completed in CQx with CQE entry "e". 2. The interrupt handler copies the "cqe" pointer to "hba->dev_cmd.cqe" and completes "hba->dev_cmd.complete". 3. The "ufshcd_wait_for_dev_cmd()" function is awakened and retrieves the OCS value from "hba->dev_cmd.cqe". However, there is a possibility that the CQE entry "e" will be overwritten by newly completed commands in CQx, resulting in an incorrect OCS value being received by "ufshcd_wait_for_dev_cmd()". To avoid this race condition, the OCS value should be immediately copied to the struct "lrb" of the device command. Then "ufshcd_wait_for_dev_cmd()" can retrieve the OCS value from the struct "lrb". Fixes: 57b1c0ef ("scsi: ufs: core: mcq: Add support to allocate multiple queues") Suggested-by:
Can Guo <quic_cang@quicinc.com> Signed-off-by:
Stanley Chu <stanley.chu@mediatek.com> Link: https://lore.kernel.org/r/20230610021553.1213-2-powen.kao@mediatek.com Tested-by:
Po-Wen Kao <powen.kao@mediatek.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Bart Van Assche authored
[ Upstream commit 72554035 ] ufshcd_add_command_trace() traces SCSI commands. Remove a ufshcd_add_command_trace() call from a code path that is not related to SCSI commands. Signed-off-by:
Avri Altman <avri.altman@wdc.com> Reviewed-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
-
Namhyung Kim authored
[ Upstream commit ed4090a2 ] When it runs multiple times with -r option, it missed to reset the aggregation counters and the values were added up. The aggregation count has the values to be printed in the end. It should reset the counters at the beginning of each run. But the current code does that only when -I/--interval-print option is given. Fixes: 91f85f98 ("perf stat: Display event stats using aggr counts") Reported-by:
Jiri Olsa <jolsa@kernel.org> Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Claudiu Beznea authored
[ Upstream commit f6fd5d4f ] devm_kasprintf() returns a pointer to dynamically allocated memory. Pointer could be NULL in case allocation fails. Check pointer validity. Identified with coccinelle (kmerr.cocci script). Fixes: 77618084 ("pinctrl: introduce driver for Atmel PIO4 controller") Depends-on: 1c4e5c47 ("pinctrl: at91: use devm_kasprintf() to avoid potential leaks") Depends-on: 5a8f9cf2 ("pinctrl: at91-pio4: use proper format specifier for unsigned int") Signed-off-by:
Claudiu Beznea <claudiu.beznea@microchip.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Claudiu Beznea authored
[ Upstream commit 310cd4c2 ] devm_kasprintf() returns a pointer to dynamically allocated memory. Pointer could be NULL in case allocation fails. Check pointer validity. Identified with coccinelle (kmerr.cocci script). Fixes: 7e5ea974 ("pinctrl: pinctrl-microchip-sgpio: Add pinctrl driver for Microsemi Serial GPIO") Signed-off-by:
-
Xiaolei Wang authored
[ Upstream commit 9063777c ] The config passed in by pad wakeup is 1, when num_configs is 1, Configuration [1] should not be fetched, which will be detected by KASAN as a memory out of bounds condition. Modify to get configs[1] when num_configs is 2. Fixes: f60c9eac ("gpio: mxc: enable pad wakeup on i.MX8x platforms") Signed-off-by:
Xiaolei Wang <xiaolei.wang@windriver.com> Reviewed-by:
Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20230504233736.3766296-1-xiaolei.wang@windriver.com Signed-off-by:
-
Nicholas Piggin authored
[ Upstream commit b4bda59b ] The refcount on mm is dropped before the coprocessor is detached. Reported-by:
Sachin Sant <sachinp@linux.ibm.com> Fixes: 7bc6f71b ("powerpc/vas: Define and use common vas_window struct") Fixes: b22f2d88 ("powerpc/pseries/vas: Integrate API with open/close windows") Signed-off-by:
-
Ian Rogers authored
[ Upstream commit 99d48500 ] Found by leak sanitizer: ``` ==1632594==ERROR: LeakSanitizer: detected memory leaks Direct leak of 21 byte(s) in 1 object(s) allocated from: #0 0x7f2953a7077b in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:439 #1 0x556701d6fbbf in perf_env__read_cpuid util/env.c:369 #2 0x556701d70589 in perf_env__cpuid util/env.c:465 #3 0x55670204bba2 in x86__is_amd_cpu arch/x86/util/env.c:14 #4 0x5567020487a2 in arch__post_evsel_config arch/x86/util/evsel.c:83 #5 0x556701d8f78b in evsel__config util/evsel.c:1366 #6 0x556701ef5872 in evlist__config util/record.c:108 #7 0x556701cd6bcd in test__PERF_RECORD tests/perf-record.c:112 #8 0x556701cacd07 in run_test tests/builtin-test.c:236 #9 0x556701cacfac in test_and_print tests/builtin-test.c:265 #10 0x556701cadddb in __cmd_test tests/builtin-test.c:402 #11 0x556701caf2aa in cmd_test tests/builtin-test.c:559 #12 0x556701d3b557 in run_builtin tools/perf/perf.c:323 #13 0x556701d3bac8 in handle_internal_command tools/perf/perf.c:377 #14 0x556701d3be90 in run_argv tools/perf/perf.c:421 #15 0x556701d3c3f8 in main tools/perf/perf.c:537 #16 0x7f2952a46189 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 SUMMARY: AddressSanitizer: 21 byte(s) leaked in 1 allocation(s). ``` Fixes: f7b58cbd ("perf mem/c2c: Add load store event mappings for AMD") Signed-off-by:
Ravi Bangoria <ravi.bangoria@amd.com> Tested-by:
-
Ravi Bangoria authored
[ Upstream commit 0cd1ca46 ] There are multiple places where x86 specific code determines AMD vs Intel arch and acts based on that. Consolidate those checks into a single function. Signed-off-by:
-
Michal Wilczynski authored
[ Upstream commit 966cca72 ] Currently rbtn_add() in case of failure is leaking resources. Fix this by adding a proper rollback. Move devm_kzalloc() before rbtn_acquire(), so it doesn't require rollback in case of failure. While at it, remove unnecessary assignment of NULL to device->driver_data and unnecessary whitespace, plus add a break for the default case in a switch. Suggested-by:
Pali Rohár <pali@kernel.org> Fixes: 817a5cdb ("dell-rbtn: Dell Airplane Mode Switch driver") Signed-off-by:
Michal Wilczynski <michal.wilczynski@intel.com> Reviewed-by:
Rafael J. Wysocki <rafael@kernel.org> Reviewed-by:
-
Aditya Gupta authored
[ Upstream commit c3ac3b07 ] Test "perf script task-analyzer tests" fails in environment with missing libtraceevent support, as perf record fails to create the perf.data file, which further tests depend on. Instead, when perf is not compiled with libtraceevent support, skip those tests instead of failing them, by checking the output of `perf record --dry-run` to see if it prints the error "libtraceevent is necessary for tracepoint support" For the following output, perf compiled with: `make NO_LIBTRACEEVENT=1` Before the patch: 108: perf script task-analyzer tests : test child forked, pid 24105 failed to open perf.data: No such file or directory (try 'perf record' first) FAIL: "invokation of perf script report task-analyzer command failed" Error message: "" FAIL: "test_basic" Error message: "Failed to find required string:'Comm'." failed to open perf.data: No such file or directory (try 'perf record' first) FAIL: "invokation of perf script report task-analyzer --ns --rename-comms-by-tids 0:random command failed" Error message: "" FAIL: "test_ns_rename" Error message: "Failed to find required string:'Comm'." failed to open perf.data: No such file or directory (try 'perf record' first) <...> perf script task-analyzer tests: FAILED! With this patch, the script instead returns 2 signifying SKIP, and after the patch: 108: perf script task-analyzer tests : test child forked, pid 26010 libtraceevent is necessary for tracepoint support WARN: Skipping tests. No libtraceevent support test child finished with -2 perf script task-analyzer tests: Skip Fixes: e8478b84 ("perf test: Add new task-analyzer tests") Signed-off-by:
Athira Rajeev <atrajeev@linux.vnet.ibm.com> Signed-off-by:
Kajol Jain <kjain@linux.ibm.com> Signed-off-by:
-
Aditya Gupta authored
[ Upstream commit 5c4396ef ] ${$1} gives bad substitution error on sh, bash, and zsh. This seems like a typo, and this patch modifies it to $1, since that is what it's usage looks like from wherever `check_exec_0` is called. This issue due to ${$1} caused all function calls to give error in `find_str_or_fail` line, and so no test runs completely. But 'perf test "perf script task-analyzer tests"' wrongly reports that tests passed with the status OK, which is wrong considering the tests didn't even run completely Fixes: e8478b84 ("perf test: add new task-analyzer tests") Signed-off-by:
-
Namhyung Kim authored
[ Upstream commit 3abfcfd8 ] The die_get_varname() returns "(unknown_type)" string if it failed to find a type for the variable. But it had a space before the opening parenthesis and it made the closing parenthesis cut off due to the off-by-one in the string length (14). Signed-off-by:
-
Mark Pearson authored
[ Upstream commit f999e23c ] Fix issues identified in dytc_profile_refresh identified by lkp-tests. drivers/platform/x86/thinkpad_acpi.c:10538 dytc_profile_refresh() error: uninitialized symbol 'funcmode'. drivers/platform/x86/thinkpad_acpi.c:10531 dytc_profile_refresh() error: uninitialized symbol 'output'. drivers/platform/x86/thinkpad_acpi.c:10537 dytc_profile_refresh() error: uninitialized symbol 'output'. These issues should not lead to real problems in the field as the refresh function should only be called if MMC or PSC mode enabled. But good to fix. Thanks to Dan Carpenter and the lkp-tests project for flagging these. Reported-by:
Mark Pearson <mpearson-lenovo@squebb.ca> Link: https://lore.kernel.org/r/20230606151804.8819-1-mpearson-lenovo@squebb.ca Reviewed-by:
-
Arnaldo Carvalho de Melo authored
[ Upstream commit 36d3e413 ] When printing output we may want to generate per event files, where the --per-event-dump option should be used, creating perf.data.EVENT.dump files instead of printing to stdout. The callback thar processes event thus expects that evsel->priv->fp should point to either the per-event FILE descriptor or to stdout. The a3af66f5 ("perf script: Fix crash because of missing evsel->priv") changeset fixed a case where evsel->priv wasn't setup, thus set to NULL, causing a segfault when trying to access evsel->priv->fp. But it did it for the non --per-event-dump case by allocating a 'struct perf_evsel_script' just to set its ->fp to stdout. Since evsel->priv is only freed when --per-event-dump is used, we ended up with a memory leak, detected using ASAN. Fix it by using the same method as perf_script__setup_per_event_dump(), and reuse that static 'struct perf_evsel_script'. Also check if evsel_script__new() failed. Fixes: a3af66f5 ("perf script: Fix crash because of missing evsel->priv") Reported-by:
-
Christophe Leroy authored
[ Upstream commit a03b1a0b ] Looking at generated code for handle_signal32() shows calls to a function called __unsafe_save_user_regs.constprop.0 while user access is open. And that __unsafe_save_user_regs.constprop.0 function has two nops at the begining, allowing it to be traced, which is unexpected during user access open window. The solution could be to mark __unsafe_save_user_regs() no trace, but to be on the safe side the most efficient is to flag it __always_inline as already done for function __unsafe_restore_general_regs(). The function is relatively small and only called twice, so the size increase will remain in the noise. Do the same with save_tm_user_regs_unsafe() as it may suffer the same issue. Fixes: ef75e731 ("powerpc/signal32: Transform save_user_regs() and save_tm_user_regs() in 'unsafe' version") Signed-off-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by:
-
