aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2024-05-17x86/boot: Address clang -Wimplicit-fallthrough in vsprintf()Nathan Chancellor1-0/+2
After enabling -Wimplicit-fallthrough for the x86 boot code, clang warns: arch/x86/boot/printf.c:257:3: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough] 257 | case 'u': | ^ Clang is a little more pedantic than GCC, which does not warn when falling through to a case that is just break or return. Clang's version is more in line with the kernel's own stance in deprecated.rst, which states that all switch/case blocks must end in either break, fallthrough, continue, goto, or return. Add the missing break to silence the warning. Fixes: dd0716c2b877 ("x86/boot: Add a fallthrough annotation") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Justin Stitt <justinstitt@google.com> Link: https://lore.kernel.org/r/20240516-x86-boot-fix-clang-implicit-fallthrough-v1-1-04dc320ca07c@kernel.org Closes: https://lore.kernel.org/oe-kbuild-all/202405162054.ryP73vy1-lkp@intel.com/
2024-05-16x86/boot: Add a fallthrough annotationBorislav Petkov2-0/+2
Add implicit fallthrough checking to the decompressor code and fix this warning: arch/x86/boot/printf.c: In function ‘vsprintf’: arch/x86/boot/printf.c:248:10: warning: this statement may fall through [-Wimplicit-fallthrough=] 248 | flags |= SMALL; | ^ arch/x86/boot/printf.c:249:3: note: here 249 | case 'X': | ^~~~ This is a patch from three years ago which I found in my trees, thus the SUSE authorship still. Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20240516102240.16270-1-bp@kernel.org
2024-05-13dmaengine: idxd: add a write() method for applications to submit workNikhil Rao2-2/+90
After the patch to restrict the use of mmap() to CAP_SYS_RAWIO for the currently existing devices, most applications can no longer make use of the accelerators as in production "you don't run things as root". To keep the DSA and IAA accelerators usable, hook up a write() method so that applications can still submit work. In the write method, sufficient input validation is performed to avoid the security issue that required the mmap CAP_SYS_RAWIO check. One complication is that the DSA device allows for indirect ("batched") descriptors. There is no reasonable way to do the input validation on these indirect descriptors so the write() method will not allow these to be submitted to the hardware on affected hardware, and the sysfs enumeration of support for the opcode is also removed. Early performance data shows that the performance delta for most common cases is within the noise. Signed-off-by: Nikhil Rao <nikhil.rao@intel.com> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
2024-05-13dmaengine: idxd: add a new security check to deal with a hardware erratumArjan van de Ven3-0/+19
On Sapphire Rapids and related platforms, the DSA and IAA devices have an erratum that causes direct access (for example, by using the ENQCMD or MOVDIR64 instructions) from untrusted applications to be a security problem. To solve this, add a flag to the PCI device enumeration and device structures to indicate the presence/absence of this security exposure. In the mmap() method of the device, this flag is then used to enforce that the user has the CAP_SYS_RAWIO capability. In a future patch, a write() based method will be added that allows untrusted applications submit work to the accelerator, where the kernel can do sanity checking on the user input to ensure secure operation of the accelerator. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
2024-05-13VFIO: Add the SPR_DSA and SPR_IAX devices to the denylistArjan van de Ven3-3/+4
Due to an erratum with the SPR_DSA and SPR_IAX devices, it is not secure to assign these devices to virtual machines. Add the PCI IDs of these devices to the VFIO denylist to ensure that this is handled appropriately by the VFIO subsystem. The SPR_DSA and SPR_IAX devices are on-SOC devices for the Sapphire Rapids (and related) family of products that perform data movement and compression. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
2024-05-12Linux 6.9Linus Torvalds1-1/+1
2024-05-11selftests/harness: Handle TEST_F()'s explicit exit codesMickaël Salaün1-1/+5
If TEST_F() explicitly calls exit(code) with code different than 0, then _metadata->exit_code is set to this code (e.g. KVM_ONE_VCPU_TEST()). We need to keep in mind that _metadata->exit_code can be KSFT_SKIP while the process exit code is 0. Cc: Jakub Kicinski <kuba@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Mark Brown <broonie@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Will Drewry <wad@chromium.org> Reported-by: Sean Christopherson <seanjc@google.com> Tested-by: Sean Christopherson <seanjc@google.com> Closes: https://lore.kernel.org/r/ZjPelW6-AbtYvslu@google.com Fixes: 0710a1a73fb4 ("selftests/harness: Merge TEST_F_FORK() into TEST_F()") Link: https://lore.kernel.org/r/20240511171445.904356-11-mic@digikod.net Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-05-11selftests/harness: Fix vfork() side effectsMickaël Salaün2-25/+57
Setting the time namespace with CLONE_NEWTIME returns -EUSERS if the calling thread shares memory with another thread (because of the shared vDSO), which is the case when it is created with vfork(). Fix pidfd_setns_test by replacing test harness's vfork() call with a clone3() call with CLONE_VFORK, and an explicit sharing of the _metadata and self objects. Replace _metadata->teardown_parent with a new FIXTURE_TEARDOWN_PARENT() helper that can replace FIXTURE_TEARDOWN(). This is a cleaner approach and it enables to selectively share the fixture data between the child process running tests and the parent process running the fixture teardown. This also avoids updating several tests to not rely on the self object's copy-on-write property (e.g. storing the returned value of a fork() call). Cc: Christian Brauner <brauner@kernel.org> Cc: David S. Miller <davem@davemloft.net> Cc: Günther Noack <gnoack@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Will Drewry <wad@chromium.org> Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202403291015.1fcfa957-oliver.sang@intel.com Fixes: 0710a1a73fb4 ("selftests/harness: Merge TEST_F_FORK() into TEST_F()") Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20240511171445.904356-10-mic@digikod.net Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-05-11selftests/harness: Share _metadata between forked processesMickaël Salaün1-11/+15
Unconditionally share _metadata between all forked processes, which enables to actually catch errors which were previously ignored. This is required for a following commit replacing vfork() with clone3() and CLONE_VFORK (i.e. not sharing the full memory) . It should also be useful to share _metadata to extend expectations to test process's forks. For instance, this change identified a wrong expectation in pidfd_setns_test. Because this _metadata is used by the new XFAIL_ADD(), use a global pointer initialized in TEST_F(). This is OK because only XFAIL_ADD() use it, and XFAIL_ADD() already depends on TEST_F(). Cc: Jakub Kicinski <kuba@kernel.org> Cc: Shuah Khan <skhan@linuxfoundation.org> Cc: Will Drewry <wad@chromium.org> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20240511171445.904356-9-mic@digikod.net Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-05-11selftests/pidfd: Fix wrong expectationMickaël Salaün1-1/+1
Replace a wrong EXPECT_GT(self->child_pid_exited, 0) with EXPECT_GE(), which will be actually tested on the parent and child sides with a following commit. Cc: Shuah Khan <skhan@linuxfoundation.org> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Christian Brauner <brauner@kernel.org> Link: https://lore.kernel.org/r/20240511171445.904356-8-mic@digikod.net Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-05-11selftests/harness: Constify fixture variantsMickaël Salaün1-2/+2
FIXTURE_VARIANT_ADD() types are passed as const pointers to FIXTURE_TEARDOWN(). Make that explicit by constifying the variants declarations. Cc: Shuah Khan <skhan@linuxfoundation.org> Cc: Will Drewry <wad@chromium.org> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20240511171445.904356-7-mic@digikod.net Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-05-11selftests/landlock: Do not allocate memory in fixture dataMickaël Salaün1-22/+35
Do not allocate self->dir_path in the test process because this would not be visible in the FIXTURE_TEARDOWN() process when relying on fork()/clone3() instead of vfork(). This change is required for a following commit removing vfork() call to not break the layout3_fs.* test cases. Cc: Günther Noack <gnoack@google.com> Cc: Shuah Khan <skhan@linuxfoundation.org> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20240511171445.904356-6-mic@digikod.net Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-05-11selftests/harness: Fix interleaved scheduling leading to race conditionsMickaël Salaün1-1/+14
Fix a race condition when running several FIXTURE_TEARDOWN() managing the same resource. This fixes a race condition in the Landlock file system tests when creating or unmounting the same directory. Using clone3() with CLONE_VFORK guarantees that the child and grandchild test processes are sequentially scheduled. This is implemented with a new clone3_vfork() helper replacing the fork() call. This avoids triggering this error in __wait_for_test(): Test ended in some other way [127] Cc: Christian Brauner <brauner@kernel.org> Cc: David S. Miller <davem@davemloft.net> Cc: Günther Noack <gnoack@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Will Drewry <wad@chromium.org> Fixes: 41cca0542d7c ("selftests/harness: Fix TEST_F()'s vfork handling") Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20240511171445.904356-5-mic@digikod.net Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-05-11selftests/harness: Fix fixture teardownMickaël Salaün1-5/+9
Make sure fixture teardowns are run when test cases failed, including when _metadata->teardown_parent is set to true. Make sure only one fixture teardown is run per test case, handling the case where the test child forks. Cc: Jakub Kicinski <kuba@kernel.org> Cc: Shengyu Li <shengyu.li.evgeny@gmail.com> Cc: Shuah Khan <skhan@linuxfoundation.org> Fixes: 72d7cb5c190b ("selftests/harness: Prevent infinite loop due to Assert in FIXTURE_TEARDOWN") Fixes: 0710a1a73fb4 ("selftests/harness: Merge TEST_F_FORK() into TEST_F()") Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20240511171445.904356-4-mic@digikod.net Rule: add Link: https://lore.kernel.org/stable/20240506165518.474504-4-mic%40digikod.net Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-05-11selftests/landlock: Fix FS tests when run on a private mount pointMickaël Salaün1-1/+9
According to the test environment, the mount point of the test's working directory may be shared or not, which changes the visibility of the nested "tmp" mount point for the test's parent process calling umount("tmp"). This was spotted while running tests in containers [1], where mount points are private. Cc: Günther Noack <gnoack@google.com> Cc: Shuah Khan <skhan@linuxfoundation.org> Link: https://github.com/landlock-lsm/landlock-test-tools/pull/4 [1] Fixes: 41cca0542d7c ("selftests/harness: Fix TEST_F()'s vfork handling") Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20240511171445.904356-3-mic@digikod.net Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-05-11selftests/pidfd: Fix config for pidfd_setns_testMickaël Salaün1-0/+2
Required by switch_timens() to open /proc/self/ns/time_for_children. CONFIG_GENERIC_VDSO_TIME_NS is not available on UML, so pidfd_setns_test cannot be run successfully on this architecture. Cc: Shuah Khan <skhan@linuxfoundation.org> Fixes: 2b40c5db73e2 ("selftests/pidfd: add pidfd setns tests") Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Christian Brauner <brauner@kernel.org> Link: https://lore.kernel.org/r/20240511171445.904356-2-mic@digikod.net Signed-off-by: Mickaël Salaün <mic@digikod.net>
2024-05-11csky: Emulate one-byte cmpxchgPaul E. McKenney2-0/+11
Use the new cmpxchg_emu_u8() to emulate one-byte cmpxchg() on csky. [ paulmck: Apply kernel test robot feedback. ] [ paulmck: Drop two-byte support per Arnd Bergmann feedback. ] Co-developed-by: Yujie Liu <yujie.liu@intel.com> Signed-off-by: Yujie Liu <yujie.liu@intel.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Tested-by: Yujie Liu <yujie.liu@intel.com> Reviewed-by: Guo Ren <guoren@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: <linux-csky@vger.kernel.org>
2024-05-11Revert "drm/nouveau/firmware: Fix SG_DEBUG error with nvkm_firmware_ctor()"Dave Airlie1-12/+7
This reverts commit 52a6947bf576b97ff8e14bb0a31c5eaf2d0d96e2. This causes loading failures in [ 0.367379] nouveau 0000:01:00.0: NVIDIA GP104 (134000a1) [ 0.474499] nouveau 0000:01:00.0: bios: version 86.04.50.80.13 [ 0.474620] nouveau 0000:01:00.0: pmu: firmware unavailable [ 0.474977] nouveau 0000:01:00.0: fb: 8192 MiB GDDR5 [ 0.484371] nouveau 0000:01:00.0: sec2(acr): mbox 00000001 00000000 [ 0.484377] nouveau 0000:01:00.0: sec2(acr):load: boot failed: -5 [ 0.484379] nouveau 0000:01:00.0: acr: init failed, -5 [ 0.484466] nouveau 0000:01:00.0: init failed with -5 [ 0.484468] nouveau: DRM-master:00000000:00000080: init failed with -5 [ 0.484470] nouveau 0000:01:00.0: DRM-master: Device allocation failed: -5 [ 0.485078] nouveau 0000:01:00.0: probe with driver nouveau failed with error -50 I tried tracking it down but ran out of time this week, will revisit next week. Reported-by: Dan Moulding <dan@danm.net> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2024-05-10mailmap: add entry for Barry SongBarry Song1-0/+5
Include a .mailmap entry to synchronize with both my past and current emails. Among them, three business mailboxes are dead. Link: https://lkml.kernel.org/r/20240506042009.10854-1-21cnbao@gmail.com Signed-off-by: Barry Song <v-songbaohua@oppo.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-05-10selftests/mm: fix powerpc ARCH checkMichael Ellerman1-3/+3
In commit 0518dbe97fe6 ("selftests/mm: fix cross compilation with LLVM") the logic to detect the machine architecture in the Makefile was changed to use ARCH, and only fallback to uname -m if ARCH is unset. However the tests of ARCH were not updated to account for the fact that ARCH is "powerpc" for powerpc builds, not "ppc64". Fix it by changing the checks to look for "powerpc", and change the uname -m logic to convert "ppc64.*" into "powerpc". With that fixed the following tests now build for powerpc again: * protection_keys * va_high_addr_switch * virtual_address_range * write_to_hugetlbfs Link: https://lkml.kernel.org/r/20240506115825.66415-1-mpe@ellerman.id.au Fixes: 0518dbe97fe6 ("selftests/mm: fix cross compilation with LLVM") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Cc: Mark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org> [6.4+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-05-10drm/amdgpu: Fix comparison in amdgpu_res_cpu_visibleMichel Dänzer1-1/+1
It incorrectly claimed a resource isn't CPU visible if it's located at the very end of CPU visible VRAM. Fixes: a6ff969fe9cb ("drm/amdgpu: fix visible VRAM handling during faults") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3343 Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reported-and-Tested-by: Jeremy Day <jsday@noreason.ca> Signed-off-by: Michel Dänzer <mdaenzer@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> CC: stable@vger.kernel.org
2024-05-10drm/amdkfd: don't allow mapping the MMIO HDP page with large pagesAlex Deucher1-2/+5
We don't get the right offset in that case. The GPU has an unused 4K area of the register BAR space into which you can remap registers. We remap the HDP flush registers into this space to allow userspace (CPU or GPU) to flush the HDP when it updates VRAM. However, on systems with >4K pages, we end up exposing PAGE_SIZE of MMIO space. Fixes: d8e408a82704 ("drm/amdkfd: Expose HDP registers to user space") Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2024-05-10x86/topology/amd: Ensure that LLC ID is initializedThomas Gleixner1-9/+7
The original topology evaluation code initialized cpu_data::topo::llc_id with the die ID initialy and then eventually overwrite it with information gathered from a CPUID leaf. The conversion analysis failed to spot that particular detail and omitted this initial assignment under the assumption that each topology evaluation path will set it up. That assumption is mostly correct, but turns out to be wrong in case that the CPUID leaf 0x80000006 does not provide a LLC ID. In that case, LLC ID is invalid and as a consequence the setup of the scheduling domain CPU masks is incorrect which subsequently causes the scheduler core to complain about it during CPU hotplug: BUG: arch topology borken the CLS domain not a subset of the MC domain Cure it by reusing legacy_set_llc() and assigning the die ID if the LLC ID is invalid after all possible parsers have been tried. Fixes: f7fb3b2dd92c ("x86/cpu: Provide an AMD/HYGON specific topology parser") Reported-by: Yuezhang Mo <Yuezhang.Mo@sony.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Tested-by: Yuezhang Mo <Yuezhang.Mo@sony.com> Link: https://lore.kernel.org/r/PUZPR04MB63168AC442C12627E827368581292@PUZPR04MB6316.apcprd04.prod.outlook.com
2024-05-10gpiolib: cdev: fix uninitialised kfifoKent Gibson1-0/+14
If a line is requested with debounce, and that results in debouncing in software, and the line is subsequently reconfigured to enable edge detection then the allocation of the kfifo to contain edge events is overlooked. This results in events being written to and read from an uninitialised kfifo. Read events are returned to userspace. Initialise the kfifo in the case where the software debounce is already active. Fixes: 65cff7046406 ("gpiolib: cdev: support setting debounce") Signed-off-by: Kent Gibson <warthog618@gmail.com> Link: https://lore.kernel.org/r/20240510065342.36191-1-warthog618@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-05-10arm64: defconfig: enable Airoha platformDaniel Danzberger1-0/+1
Enables the ARCH_AIROHA config by default. Signed-off-by: Daniel Danzberger <dd@embedd.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/65737ca5506371ef84c3a055e68d280f314e3b41.1709975956.git.lorenzo@kernel.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-05-10arm64: add Airoha EN7581 platformDaniel Danzberger1-0/+7
Introduce the Kconfig entry for the Airoha EN7581 multicore architecture available in the Airoha EN7581 evaluation board. Signed-off-by: Daniel Danzberger <dd@embedd.com> Co-developed-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/d52d95db313e6a58ba997ba2181faf78a1014bcc.1709975956.git.lorenzo@kernel.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-05-10x86/amd_nb: Add new PCI IDs for AMD family 0x1aShyam Sundar S K2-0/+2
Add the new PCI Device IDs to the MISC IDs list to support new generation of AMD 1Ah family 70h Models of processors. [ bp: Massage commit message. ] Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20240510111829.969501-1-Shyam-sundar.S-k@amd.com
2024-05-10io_uring: support to inject result for NOPMing Lei2-5/+29
Support to inject result for NOP so that we can inject failure from userspace. It is very helpful for covering failure handling code in io_uring core change. With nop flags, it becomes possible to add more test features on NOP in future. Suggested-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20240510035031.78874-3-ming.lei@redhat.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-05-10io_uring: fail NOP if non-zero op flags is passed inMing Lei1-0/+2
The NOP op flags should have been checked from beginning like any other opcode, otherwise NOP may not be extended with the op flags. Given both liburing and Rust io-uring crate always zeros SQE op flags, just ignore users which play raw NOP uring interface without zeroing SQE, because NOP is just for test purpose. Then we can save one NOP2 opcode. Suggested-by: Jens Axboe <axboe@kernel.dk> Fixes: 2b188cc1bb85 ("Add io_uring IO interface") Cc: stable@vger.kernel.org Signed-off-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20240510035031.78874-2-ming.lei@redhat.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-05-10crypto: atmel-sha204a - provide the otp contentLothar Rubusch1-0/+45
Set up sysfs for the Atmel SHA204a. Provide the content of the otp zone as an attribute field on the sysfs entry. Thereby make sure that if the chip is locked, not connected or trouble with the i2c bus, the sysfs device is not set up. This is mostly already handled in atmel-i2c. Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-05-10crypto: atmel-sha204a - add reading from otp zoneLothar Rubusch3-0/+52
Provide a read function reading the otp zone. The otp zone can be used for storing serial numbers. The otp zone, as also data zone, are only accessible if the chip was locked before. Locking the chip is a post production customization and has to be done manually i.e. not by this driver. Without this step the chip is pretty much not usable, where putting or not putting data into the otp zone is optional. Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-05-10crypto: atmel-i2c - rename read functionLothar Rubusch2-4/+4
Make the memory read function name more specific to the read memory zone. The Atmel SHA204 chips provide config, otp and data zone. The implemented read function in fact only reads some fields in zone config. The function renaming allows for a uniform naming scheme when reading from other memory zones. Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-05-10crypto: atmel-i2c - add missing arg descriptionLothar Rubusch1-0/+1
Add missing description for argument hwrng. Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-05-10crypto: iaa - Use kmemdup() instead of kzalloc() and memcpy()Thorsten Blum1-4/+2
Fixes the following two Coccinelle/coccicheck warnings reported by memdup.cocci: iaa_crypto_main.c:350:19-26: WARNING opportunity for kmemdup iaa_crypto_main.c:358:18-25: WARNING opportunity for kmemdup Signed-off-by: Thorsten Blum <thorsten.blum@toblux.com> Reviewed-by: Tom Zanussi <tom.zanussi@linux.intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-05-10crypto: sahara - use 'time_left' variable with wait_for_completion_timeout()Wolfram Sang1-8/+8
There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_for_completion_timeout() causing patterns like: timeout = wait_for_completion_timeout(...) if (!timeout) return -ETIMEDOUT; with all kinds of permutations. Use 'time_left' as a variable to make the code self explaining. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-05-10crypto: api - use 'time_left' variable with wait_for_completion_killable_timeout()Wolfram Sang1-4/+4
There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_for_completion_killable_timeout() causing patterns like: timeout = wait_for_completion_killable_timeout(...) if (!timeout) return -ETIMEDOUT; with all kinds of permutations. Use 'time_left' as a variable to make the code self explaining. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-05-10crypto: caam - i.MX8ULP donot have CAAM page0 accessPankaj Gupta1-0/+3
iMX8ULP have a secure-enclave hardware IP called EdgeLock Enclave(ELE), that control access to caam controller's register page, i.e., page0. At all, if the ELE release access to CAAM controller's register page, it will release to secure-world only. Clocks are turned on automatically for iMX8ULP. There exists the caam clock gating bit, but it is not advised to gate the clock at linux, as optee-os or any other entity might be using it. Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com> Reviewed-by: Gaurav Jain <gaurav.jain@nxp.com> Reviewed-by: Horia Geanta <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-05-10crypto: caam - init-clk based on caam-page0-accessPankaj Gupta1-1/+15
CAAM clock initializat is done based on the basis of soc specific info stored in struct caam_imx_data: - caam-page0-access flag - num_clks CAAM driver needs to be aware of access rights to CAAM control page i.e., page0, to do things differently. Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com> Reviewed-by: Gaurav Jain <gaurav.jain@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-05-10crypto: starfive - Use fallback for unaligned dma accessJia Jie Ho1-5/+7
Dma address mapping fails on unaligned scatterlist offset. Use sw fallback for these cases. Signed-off-by: Jia Jie Ho <jiajie.ho@starfivetech.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-05-10crypto: starfive - Do not free stack bufferJia Jie Ho1-1/+0
RSA text data uses variable length buffer allocated in software stack. Calling kfree on it causes undefined behaviour in subsequent operations. Cc: <stable@vger.kernel.org> #6.7+ Signed-off-by: Jia Jie Ho <jiajie.ho@starfivetech.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-05-10crypto: starfive - Skip unneeded fallback allocationJia Jie Ho1-6/+4
Skip sw fallback allocation if RSA module failed to get device handle. Signed-off-by: Jia Jie Ho <jiajie.ho@starfivetech.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-05-10crypto: starfive - Skip dma setup for zeroed messageJia Jie Ho1-0/+4
Skip dma setup and mapping for AES driver if plaintext is empty. Signed-off-by: Jia Jie Ho <jiajie.ho@starfivetech.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-05-10clocksource/drivers/arm_arch_timer: Mark hisi_161010101_oem_info constStephen Boyd1-1/+1
This isn't modified at runtime. Mark it const so it can move to read-only data. Cc: dann frazier <dann.frazier@canonical.com> Cc: Hanjun Guo <hanjun.guo@linaro.org> Cc: Marc Zyngier <maz@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20240502233447.420888-1-swboyd@chromium.org
2024-05-10clocksource/drivers/timer-ti-dm: Remove an unused field in struct dmtimerChristophe JAILLET1-1/+0
In "struct dmtimer", the 'rate' field is unused. Remove it. Found with cppcheck, unusedStructMember. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/c9f7579922c587fce334a1aa9651f3189de7a00b.1714513336.git.christophe.jaillet@wanadoo.fr
2024-05-10clocksource/drivers/renesas-ostm: Avoid reprobe after successful early probeGeert Uytterhoeven1-0/+1
The Renesas OS Timer (OSTM) driver contains two probe points, of which only one should complete: 1. Early probe, using TIMER_OF_DECLARE(), to provide the sole clocksource on (arm32) RZ/A1 and RZ/A2 SoCs, 2. Normal probe, using a platform driver, to provide additional timers on (arm64 + riscv) RZ/G2L and similar SoCs. The latter is needed because using OSTM on RZ/G2L requires manipulation of its reset signal, which is not yet available at the time of early probe, causing early probe to fail with -EPROBE_DEFER. It is only enabled when building a kernel with support for the RZ/G2L family, so it does not impact RZ/A1 and RZ/A2. Hence only one probe method can complete on all affected systems. As relying on the order of initialization of subsystems inside the kernel is fragile, set the DT node's OF_POPULATED flag after a succesful early probe. This makes sure the platform driver's probe is never called after a successful early probe. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviwed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/bd027379713cbaafa21ffe9e848ebb7f475ca0e7.1710930542.git.geert+renesas@glider.be
2024-05-10clocksource/drivers/renesas-ostm: Allow OSTM driver to reprobe for RZ/V2H(P) SoCLad Prabhakar1-1/+1
The RZ/V2H(P) (R9A09G057) SoC is equipped with the Generic Timer Module, also known as OSTM. Similar to the RZ/G2L SoC, the OSTM on the RZ/V2H(P) SoC requires the reset line to be deasserted before accessing any registers. Early call to ostm_init() happens through TIMER_OF_DECLARE() which always fails with -EPROBE_DEFER, as resets are not available that early in the boot process. To address this issue on the RZ/V2H(P) SoC, enable the OSTM driver to be reprobed through the platform driver probe mechanism. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20240322151219.885832-3-prabhakar.mahadev-lad.rj@bp.renesas.com
2024-05-10dt-bindings: timer: renesas: ostm: Document Renesas RZ/V2H(P) SoCLad Prabhakar1-0/+2
Document the General Timer Module (a.k.a OSTM) block on Renesas RZ/V2H(P) ("R9A09G057") SoC, which is identical to the one found on the RZ/A1H and RZ/G2L SoCs. Add the "renesas,r9a09g057-ostm" compatible string for the RZ/V2H(P) SoC. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20240322151219.885832-2-prabhakar.mahadev-lad.rj@bp.renesas.com
2024-05-10iommu/arm-smmu: Use the correct type in nvidia_smmu_context_fault()Jason Gunthorpe1-3/+1
This was missed because of the function pointer indirection. nvidia_smmu_context_fault() is also installed as a irq function, and the 'void *' was changed to a struct arm_smmu_domain. Since the iommu_domain is embedded at a non-zero offset this causes nvidia_smmu_context_fault() to miscompute the offset. Fixup the types. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000120 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000107c9f000 [0000000000000120] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 1 PID: 47 Comm: kworker/u25:0 Not tainted 6.9.0-0.rc7.58.eln136.aarch64 #1 Hardware name: Unknown NVIDIA Jetson Orin NX/NVIDIA Jetson Orin NX, BIOS 3.1-32827747 03/19/2023 Workqueue: events_unbound deferred_probe_work_func pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : nvidia_smmu_context_fault+0x1c/0x158 lr : __free_irq+0x1d4/0x2e8 sp : ffff80008044b6f0 x29: ffff80008044b6f0 x28: ffff000080a60b18 x27: ffffd32b5172e970 x26: 0000000000000000 x25: ffff0000802f5aac x24: ffff0000802f5a30 x23: ffff0000802f5b60 x22: 0000000000000057 x21: 0000000000000000 x20: ffff0000802f5a00 x19: ffff000087d4cd80 x18: ffffffffffffffff x17: 6234362066666666 x16: 6630303078302d30 x15: ffff00008156d888 x14: 0000000000000000 x13: ffff0000801db910 x12: ffff00008156d6d0 x11: 0000000000000003 x10: ffff0000801db918 x9 : ffffd32b50f94d9c x8 : 1fffe0001032fda1 x7 : ffff00008197ed00 x6 : 000000000000000f x5 : 000000000000010e x4 : 000000000000010e x3 : 0000000000000000 x2 : ffffd32b51720cd8 x1 : ffff000087e6f700 x0 : 0000000000000057 Call trace: nvidia_smmu_context_fault+0x1c/0x158 __free_irq+0x1d4/0x2e8 free_irq+0x3c/0x80 devm_free_irq+0x64/0xa8 arm_smmu_domain_free+0xc4/0x158 iommu_domain_free+0x44/0xa0 iommu_deinit_device+0xd0/0xf8 __iommu_group_remove_device+0xcc/0xe0 iommu_bus_notifier+0x64/0xa8 notifier_call_chain+0x78/0x148 blocking_notifier_call_chain+0x4c/0x90 bus_notify+0x44/0x70 device_del+0x264/0x3e8 pci_remove_bus_device+0x84/0x120 pci_remove_root_bus+0x5c/0xc0 dw_pcie_host_deinit+0x38/0xe0 tegra_pcie_config_rp+0xc0/0x1f0 tegra_pcie_dw_probe+0x34c/0x700 platform_probe+0x70/0xe8 really_probe+0xc8/0x3a0 __driver_probe_device+0x84/0x160 driver_probe_device+0x44/0x130 __device_attach_driver+0xc4/0x170 bus_for_each_drv+0x90/0x100 __device_attach+0xa8/0x1c8 device_initial_probe+0x1c/0x30 bus_probe_device+0xb0/0xc0 deferred_probe_work_func+0xbc/0x120 process_one_work+0x194/0x490 worker_thread+0x284/0x3b0 kthread+0xf4/0x108 ret_from_fork+0x10/0x20 Code: a9b97bfd 910003fd a9025bf5 f85a0035 (b94122a1) Cc: stable@vger.kernel.org Fixes: e0976331ad11 ("iommu/arm-smmu: Pass arm_smmu_domain to internal functions") Reported-by: Jerry Snitselaar <jsnitsel@redhat.com> Closes: https://lore.kernel.org/all/jto5e3ili4auk6sbzpnojdvhppgwuegir7mpd755anfhwcbkfz@2u5gh7bxb4iv Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Jerry Snitselaar <jsnitsel@redhat.com> Acked-by: Jerry Snitselaar <jsnitsel@redhat.com> Link: https://lore.kernel.org/r/0-v1-24ce064de41f+4ac-nvidia_smmu_fault_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2024-05-10afs: Fix fileserver rotation getting stuckDavid Howells1-2/+6
Fix the fileserver rotation code in a couple of ways: (1) op->server_states is an array, not a pointer to a single record, so fix the places that access it to index it. (2) In the places that go through an address list to work out which one has the best priority, fix the loops to skip known failed addresses. Without this, the rotation algorithm may get stuck on addresses that are inaccessible or don't respond. This can be triggered manually by finding a server that advertises a non-routable address and giving it a higher priority, eg.: echo "add udp 192.168.0.0/16 3000" >/proc/fs/afs/addr_prefs if the server, say, includes the address 192.168.7.7 in its address list, and then attempting to access a volume on that server. Fixes: 495f2ae9e355 ("afs: Fix fileserver rotation") Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/r/4005300.1712309731@warthog.procyon.org.uk/ # v1 Link: https://lore.kernel.org/r/998836.1714746152@warthog.procyon.org.uk Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-05-10selftests: add F_DUPDFD_QUERY selftestsChristian Brauner1-1/+54
Add simple selftests for the new F_DUPFD_QUERY fcntl(). Signed-off-by: Christian Brauner <brauner@kernel.org>