Dev/alex/fixes v6.14 manual #1163
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The signal context of certain RISC-V extensions will be appended after struct __riscv_extra_ext_header, which already includes an empty context header. Therefore, there is no need to preserve a separate hdr for the END of signal context. Fixes: 8ee0b41 ("riscv: signal: Add sigcontext save/restore for vector") Signed-off-by: Yong-Xuan Wang <[email protected]> Reviewed-by: Zong Li <[email protected]> Reviewed-by: Andy Chiu <[email protected]> Reviewed-by: Alexandre Ghiti <[email protected]>
The init_rt_signal_env() funciton is called before the alternative patch is applied, so using the alternative-related API to check the availability of an extension within this function doesn't have the intended effect. This patch reorders the init_rt_signal_env() and apply_boot_alternatives() to get the correct signal_minsigstksz. Fixes: e92f469 ("riscv: signal: Report signal frame size to userspace via auxv") Signed-off-by: Yong-Xuan Wang <[email protected]> Reviewed-by: Zong Li <[email protected]> Reviewed-by: Alexandre Ghiti <[email protected]> Reviewed-by: Andy Chiu <[email protected]>
When working on OpenRISC support for restartable sequences I noticed and fixed these two issues with the riscv support bits. 1 The 'inc' argument to RSEQ_ASM_OP_R_DEREF_ADDV was being implicitly passed to the macro. Fix this by adding 'inc' to the list of macro arguments. 2 The inline asm input constraints for 'inc' and 'off' use "er", The riscv gcc port does not have an "e" constraint, this looks to be copied from the x86 port. Fix this by just using an "r" constraint. I have compile tested this only for riscv. However, the same fixes I use in the OpenRISC rseq selftests and everything passes with no issues. Fixes: 171586a ("selftests/rseq: riscv: Template memory ordering and percpu access mode") Signed-off-by: Stafford Horne <[email protected]> Tested-by: Charlie Jenkins <[email protected]> Reviewed-by: Charlie Jenkins <[email protected]> Reviewed-by: Mathieu Desnoyers <[email protected]> Acked-by: Shuah Khan <[email protected]>
Since commit 7caa976 ("ftrace: riscv: move from REGS to ARGS"), kprobe on ftrace is not supported by riscv. And commit 3308172 ("trace: riscv: Remove deprecated kprobe on ftrace support") removed the relevant code, but left out the documentation, so fix that. Signed-off-by: Chen Pei <[email protected]> Reviewed-by: Charlie Jenkins <[email protected]> Fixes: 3308172 ("trace: riscv: Remove deprecated kprobe on ftrace support")
Make sure the compare value in the lr/sc loop is sign extended to match what lr.w does. Fortunately, due to the compiler keeping the register contents sign extended anyway the lack of the explicit extension didn't result in wrong code so far, but this cannot be relied upon. Fixes: b90edb3 ("RISC-V: Add futex support.") Signed-off-by: Andreas Schwab <[email protected]> Reviewed-by: Alexandre Ghiti <[email protected]> Reviewed-by: Björn Töpel <[email protected]>
Sign extend also an unsigned compare value to match what lr.w is doing. Otherwise try_cmpxchg may spuriously return true when used on a u32 value that has the sign bit set, as it happens often in inode_set_ctime_current. Do this in three conversion steps. The first conversion to long is needed to avoid a -Wpointer-to-int-cast warning when arch_cmpxchg is used with a pointer type. Then convert to int and back to long to always sign extend the 32-bit value to 64-bit. Fixes: 6c58f25 ("riscv/atomic: Fix sign extension for RV64I") Signed-off-by: Andreas Schwab <[email protected]> Reviewed-by: Alexandre Ghiti <[email protected]> Tested-by: Xi Ruoyao <[email protected]> Reviewed-by: Andrew Jones <[email protected]>
Comparison of bitmaps should be done using bitmap_equal(), not memcmp(), use the former one to compare isa bitmaps. Signed-off-by: Clément Léger <[email protected]>
The use of of_property_read_bool() for non-boolean properties is deprecated in favor of of_property_present() when testing for property presence. Signed-off-by: Rob Herring (Arm) <[email protected]> Reviewed-by: Clément Léger <[email protected]>
Several functions used in unaligned access probing are only run at init time. Annotate them appropriately. Fixes: f413aae ("riscv: Set unaligned access speed at compile time") Reviewed-by: Alexandre Ghiti <[email protected]> Signed-off-by: Andrew Jones <[email protected]> Signed-off-by: Alexandre Ghiti <[email protected]> Link: https://lore.kernel.org/r/[email protected]
We shouldn't probe when we already know vector is unsupported and we should probe when we see we don't yet know whether it's supported. Furthermore, we should ensure we've set the access type to unsupported when we don't have vector at all. Fixes: e7c9d66 ("RISC-V: Report vector unaligned access speed hwprobe") Reviewed-by: Alexandre Ghiti <[email protected]> Signed-off-by: Andrew Jones <[email protected]> Signed-off-by: Alexandre Ghiti <[email protected]> Link: https://lore.kernel.org/r/[email protected]
check_vector_unaligned_access_emulated_all_cpus(), like its name suggests, will return true when all cpus emulate unaligned vector accesses. If the function returned false it may have been because vector isn't supported at all (!has_vector()) or because at least one cpu doesn't emulate unaligned vector accesses. Since false may be returned for two cases, checking for it isn't sufficient when attempting to determine if we should proceed with the vector speed check. Move the !has_vector() functionality to check_unaligned_access_all_cpus() in order for check_vector_unaligned_access_emulated_all_cpus() to return false for a single case. Fixes: e7c9d66 ("RISC-V: Report vector unaligned access speed hwprobe") Reviewed-by: Alexandre Ghiti <[email protected]> Signed-off-by: Andrew Jones <[email protected]> Signed-off-by: Alexandre Ghiti <[email protected]> Link: https://lore.kernel.org/r/[email protected]
The return value of check_unaligned_access_speed_all_cpus() is always zero, so make the function void so we don't need to concern ourselves with it. The change also allows us to tidy up check_unaligned_access_all_cpus() a bit. Reviewed-by: Clément Léger <[email protected]> Reviewed-by: Alexandre Ghiti <[email protected]> Signed-off-by: Andrew Jones <[email protected]> Signed-off-by: Alexandre Ghiti <[email protected]> Link: https://lore.kernel.org/r/[email protected]
CPU hotplug callbacks should be set up even if we detected all current cpus emulate misaligned accesses, since we want to ensure our expectations of all cpus emulating is maintained. Fixes: 6e5ce7f ("riscv: Decouple emulated unaligned accesses from access speed") Fixes: e7c9d66 ("RISC-V: Report vector unaligned access speed hwprobe") Reviewed-by: Clément Léger <[email protected]> Reviewed-by: Alexandre Ghiti <[email protected]> Signed-off-by: Andrew Jones <[email protected]> Signed-off-by: Alexandre Ghiti <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Whether or not we have RISCV_PROBE_VECTOR_UNALIGNED_ACCESS we need to set up a cpu hotplug callback to check if we have vector at all, since, when we don't have vector, we need to set vector_misaligned_access to unsupported rather than leave it the default of unknown. Fixes: e7c9d66 ("RISC-V: Report vector unaligned access speed hwprobe") Reviewed-by: Alexandre Ghiti <[email protected]> Signed-off-by: Andrew Jones <[email protected]> Signed-off-by: Alexandre Ghiti <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Correct the VEC_S macro definition to fix the implementation of vector words copy in the case of unalignment in RISC-V. Signed-off-by: Tingbo Liao <[email protected]> Fixes: e7c9d66 ("RISC-V: Report vector unaligned access speed hwprobe") Reviewed-by: Alexandre Ghiti <[email protected]> Signed-off-by: Alexandre Ghiti <[email protected]> Link: https://lore.kernel.org/r/[email protected]
The locally allocated pages are never freed up, so add the corresponding __free_pages(). Fixes: e7c9d66 ("RISC-V: Report vector unaligned access speed hwprobe") Signed-off-by: Alexandre Ghiti <[email protected]>
Signed-off-by: Alexandre Ghiti <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.