|
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3, v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5, v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11, v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4, v6.11-rc3, v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4 |
|
| #
59649de9 |
| 12-Jun-2024 |
Jiaxun Yang <[email protected]> |
MIPS: Implement ieee754 NAN2008 emulation mode
Implement ieee754 NAN2008 emulation mode.
When this mode is enabled, kernel will accept ELF file compiled for both NaN 2008 and NaN legacy, but if har
MIPS: Implement ieee754 NAN2008 emulation mode
Implement ieee754 NAN2008 emulation mode.
When this mode is enabled, kernel will accept ELF file compiled for both NaN 2008 and NaN legacy, but if hardware does not have capability to match ELF's NaN mode, __own_fpu will fail for corresponding thread and fpuemu will then kick in.
This mode trade performance for correctness, while maintaining support for both NaN mode regardless of hardware capability. It is useful for multilib installation that have both types of binary exist in system.
Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Signed-off-by: Jiaxun Yang <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]>
show more ...
|
|
Revision tags: v6.10-rc3, v6.10-rc2, v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6, v6.9-rc5, v6.9-rc4, v6.9-rc3, v6.9-rc2, v6.9-rc1, v6.8, v6.8-rc7, v6.8-rc6, v6.8-rc5, v6.8-rc4, v6.8-rc3, v6.8-rc2 |
|
| #
59be5c35 |
| 26-Jan-2024 |
Xi Ruoyao <[email protected]> |
mips: Call lose_fpu(0) before initializing fcr31 in mips_set_personality_nan
If we still own the FPU after initializing fcr31, when we are preempted the dirty value in the FPU will be read out and s
mips: Call lose_fpu(0) before initializing fcr31 in mips_set_personality_nan
If we still own the FPU after initializing fcr31, when we are preempted the dirty value in the FPU will be read out and stored into fcr31, clobbering our setting. This can cause an improper floating-point environment after execve(). For example:
zsh% cat measure.c #include <fenv.h> int main() { return fetestexcept(FE_INEXACT); } zsh% cc measure.c -o measure -lm zsh% echo $((1.0/3)) # raising FE_INEXACT 0.33333333333333331 zsh% while ./measure; do ; done (stopped in seconds)
Call lose_fpu(0) before setting fcr31 to prevent this.
Closes: https://lore.kernel.org/linux-mips/[email protected]/ Fixes: 9b26616c8d9d ("MIPS: Respect the ISA level in FCSR handling") Cc: [email protected] Signed-off-by: Xi Ruoyao <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]>
show more ...
|
|
Revision tags: v6.8-rc1, v6.7, v6.7-rc8, v6.7-rc7, v6.7-rc6, v6.7-rc5, v6.7-rc4, v6.7-rc3, v6.7-rc2, v6.7-rc1, v6.6, v6.6-rc7, v6.6-rc6, v6.6-rc5, v6.6-rc4, v6.6-rc3, v6.6-rc2, v6.6-rc1, v6.5, v6.5-rc7, v6.5-rc6, v6.5-rc5, v6.5-rc4, v6.5-rc3, v6.5-rc2, v6.5-rc1, v6.4, v6.4-rc7, v6.4-rc6, v6.4-rc5, v6.4-rc4, v6.4-rc3, v6.4-rc2, v6.4-rc1, v6.3, v6.3-rc7, v6.3-rc6, v6.3-rc5, v6.3-rc4, v6.3-rc3, v6.3-rc2, v6.3-rc1, v6.2, v6.2-rc8, v6.2-rc7, v6.2-rc6, v6.2-rc5, v6.2-rc4, v6.2-rc3, v6.2-rc2, v6.2-rc1, v6.1, v6.1-rc8, v6.1-rc7, v6.1-rc6, v6.1-rc5, v6.1-rc4, v6.1-rc3, v6.1-rc2, v6.1-rc1, v6.0, v6.0-rc7, v6.0-rc6, v6.0-rc5, v6.0-rc4, v6.0-rc3, v6.0-rc2, v6.0-rc1, v5.19, v5.19-rc8, v5.19-rc7, v5.19-rc6, v5.19-rc5, v5.19-rc4, v5.19-rc3, v5.19-rc2, v5.19-rc1, v5.18, v5.18-rc7, v5.18-rc6, v5.18-rc5, v5.18-rc4, v5.18-rc3, v5.18-rc2, v5.18-rc1, v5.17, v5.17-rc8, v5.17-rc7, v5.17-rc6, v5.17-rc5, v5.17-rc4, v5.17-rc3, v5.17-rc2, v5.17-rc1, v5.16, v5.16-rc8, v5.16-rc7, v5.16-rc6, v5.16-rc5, v5.16-rc4, v5.16-rc3, v5.16-rc2, v5.16-rc1, v5.15, v5.15-rc7, v5.15-rc6, v5.15-rc5, v5.15-rc4, v5.15-rc3, v5.15-rc2, v5.15-rc1 |
|
| #
fbb1d4b3 |
| 01-Sep-2021 |
Kees Cook <[email protected]> |
MIPS: Modernize READ_IMPLIES_EXEC
I'm doing some thread necromancy of https://lore.kernel.org/lkml/202007081624.82FA0CC1EA@keescook/
x86, arm64, and arm32 adjusted their READ_IMPLIES_EXEC logic to
MIPS: Modernize READ_IMPLIES_EXEC
I'm doing some thread necromancy of https://lore.kernel.org/lkml/202007081624.82FA0CC1EA@keescook/
x86, arm64, and arm32 adjusted their READ_IMPLIES_EXEC logic to better align with the safer defaults and the interactions with other mappings, which I illustrated with this comment on x86:
/* * An executable for which elf_read_implies_exec() returns TRUE will * have the READ_IMPLIES_EXEC personality flag set automatically. * * The decision process for determining the results are: * * CPU: | lacks NX* | has NX, ia32 | has NX, x86_64 | * ELF: | | | | * ---------------------|------------|------------------|----------------| * missing PT_GNU_STACK | exec-all | exec-all | exec-none | * PT_GNU_STACK == RWX | exec-stack | exec-stack | exec-stack | * PT_GNU_STACK == RW | exec-none | exec-none | exec-none | * * exec-all : all PROT_READ user mappings are executable, except when * backed by files on a noexec-filesystem. * exec-none : only PROT_EXEC user mappings are executable. * exec-stack: only the stack and PROT_EXEC user mappings are * executable. * * *this column has no architectural effect: NX markings are ignored by * hardware, but may have behavioral effects when "wants X" collides with * "cannot be X" constraints in memory permission flags, as in * https://lkml.kernel.org/r/[email protected] * */
For MIPS, the "lacks NX" above is the "!cpu_has_rixi" check. On x86, we decided that the READ_IMPLIES_EXEC flag needed to reflect the expectations, not the architectural behavior due to bad interactions as noted above, as always returning "1" on non-NX hardware breaks some mappings.
The other part of the issue is "what does the MIPS toolchain do for PT_GNU_STACK?" The answer seems to be "by default, include PT_GNU_STACK, but mark it executable" (likely due to concerns over non-NX hardware):
$ mipsel-linux-gnu-gcc -o hello_world hello_world.c $ llvm-readelf -lW hellow_world | grep GNU_STACK GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x10
Given that older hardware doesn't support non-executable memory, it seems safe to make the "PT_GNU_STACK is absent" logic mean "assume non-executable", but this might break very old software running on modern MIPS. This situation matches the ia32-on-x86_64 logic x86 uses (which assumes needing READ_IMPLIES_EXEC in that situation). But modern toolchains on modern MIPS hardware should follow a safer default (assume NX stack).
A follow-up to this change would be to switch the MIPS toolchain to emit a non-executable PT_GNU_STACK, as this seems to be unneeded.
Cc: Thomas Bogendoerfer <[email protected]> Cc: Tiezhu Yang <[email protected]> Cc: Xuefeng Li <[email protected]> Cc: Juxin Gao <[email protected]> Cc: [email protected] Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]>
show more ...
|
|
Revision tags: v5.14, v5.14-rc7, v5.14-rc6, v5.14-rc5, v5.14-rc4, v5.14-rc3, v5.14-rc2, v5.14-rc1, v5.13, v5.13-rc7, v5.13-rc6, v5.13-rc5, v5.13-rc4, v5.13-rc3, v5.13-rc2, v5.13-rc1, v5.12, v5.12-rc8, v5.12-rc7, v5.12-rc6, v5.12-rc5, v5.12-rc4, v5.12-rc3, v5.12-rc2, v5.12-rc1, v5.12-rc1-dontuse, v5.11, v5.11-rc7, v5.11-rc6, v5.11-rc5, v5.11-rc4, v5.11-rc3, v5.11-rc2, v5.11-rc1, v5.10, v5.10-rc7, v5.10-rc6, v5.10-rc5, v5.10-rc4, v5.10-rc3, v5.10-rc2, v5.10-rc1, v5.9, v5.9-rc8, v5.9-rc7, v5.9-rc6, v5.9-rc5, v5.9-rc4, v5.9-rc3, v5.9-rc2, v5.9-rc1, v5.8, v5.8-rc7, v5.8-rc6, v5.8-rc5, v5.8-rc4, v5.8-rc3, v5.8-rc2, v5.8-rc1, v5.7, v5.7-rc7, v5.7-rc6, v5.7-rc5, v5.7-rc4, v5.7-rc3, v5.7-rc2, v5.7-rc1, v5.6, v5.6-rc7, v5.6-rc6, v5.6-rc5, v5.6-rc4, v5.6-rc3, v5.6-rc2, v5.6-rc1, v5.5, v5.5-rc7, v5.5-rc6, v5.5-rc5, v5.5-rc4, v5.5-rc3, v5.5-rc2, v5.5-rc1, v5.4, v5.4-rc8, v5.4-rc7, v5.4-rc6, v5.4-rc5, v5.4-rc4, v5.4-rc3, v5.4-rc2, v5.4-rc1, v5.3, v5.3-rc8, v5.3-rc7, v5.3-rc6, v5.3-rc5, v5.3-rc4, v5.3-rc3, v5.3-rc2, v5.3-rc1, v5.2, v5.2-rc7, v5.2-rc6, v5.2-rc5, v5.2-rc4, v5.2-rc3 |
|
| #
2874c5fd |
| 27-May-2019 |
Thomas Gleixner <[email protected]> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of th
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 3029 file(s).
Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Allison Randal <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
|
Revision tags: v5.2-rc2, v5.2-rc1, v5.1, v5.1-rc7, v5.1-rc6, v5.1-rc5, v5.1-rc4, v5.1-rc3, v5.1-rc2, v5.1-rc1, v5.0, v5.0-rc8, v5.0-rc7, v5.0-rc6, v5.0-rc5, v5.0-rc4, v5.0-rc3, v5.0-rc2, v5.0-rc1, v4.20, v4.20-rc7, v4.20-rc6, v4.20-rc5, v4.20-rc4, v4.20-rc3, v4.20-rc2 |
|
| #
ea6a3737 |
| 07-Nov-2018 |
Paul Burton <[email protected]> |
MIPS: Avoid FP ELF checks when CONFIG_MIPS_FP_SUPPORT=n
When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so we can avoid needless checks of ELF headers specifying the FP ABI or NaN enc
MIPS: Avoid FP ELF checks when CONFIG_MIPS_FP_SUPPORT=n
When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so we can avoid needless checks of ELF headers specifying the FP ABI or NaN encoding to use. Deselect CONFIG_ARCH_BINFMT_ELF_STATE in this case to avoid the need for our arch_elf_pt_proc() & arch_check_elf() functions, and stub out the mips_set_personality_nan() & mips_set_personality_fp() functions such that SET_PERSONALITY() doesn't need to worry about any of this.
Signed-off-by: Paul Burton <[email protected]> Patchwork: https://patchwork.linux-mips.org/patch/21011/ Cc: [email protected]
show more ...
|
|
Revision tags: v4.20-rc1, v4.19, v4.19-rc8, v4.19-rc7, v4.19-rc6, v4.19-rc5, v4.19-rc4, v4.19-rc3, v4.19-rc2, v4.19-rc1, v4.18, v4.18-rc8, v4.18-rc7, v4.18-rc6, v4.18-rc5, v4.18-rc4, v4.18-rc3, v4.18-rc2, v4.18-rc1, v4.17, v4.17-rc7, v4.17-rc6, v4.17-rc5, v4.17-rc4, v4.17-rc3, v4.17-rc2, v4.17-rc1, v4.16, v4.16-rc7, v4.16-rc6, v4.16-rc5, v4.16-rc4, v4.16-rc3, v4.16-rc2, v4.16-rc1, v4.15, v4.15-rc9, v4.15-rc8, v4.15-rc7, v4.15-rc6, v4.15-rc5, v4.15-rc4, v4.15-rc3, v4.15-rc2, v4.15-rc1, v4.14, v4.14-rc8, v4.14-rc7 |
|
| #
fb615d61 |
| 26-Oct-2017 |
Paul Burton <[email protected]> |
Update MIPS email addresses
MIPS will soon not be a part of Imagination Technologies, and as such many @imgtec.com email addresses will no longer be valid. This patch updates the addresses for those
Update MIPS email addresses
MIPS will soon not be a part of Imagination Technologies, and as such many @imgtec.com email addresses will no longer be valid. This patch updates the addresses for those who:
- Have 10 or more patches in mainline authored using an @imgtec.com email address, or any patches dated within the past year.
- Are still with Imagination but leaving as part of the MIPS business unit, as determined from an internal email address list.
- Haven't already updated their email address (ie. JamesH) or expressed a desire to be excluded (ie. Maciej).
- Acked v2 or earlier of this patch, which leaves Deng-Cheng, Matt & myself.
New addresses are of the form [email protected], and all verified against an internal email address list. An entry is added to .mailmap for each person such that get_maintainer.pl will report the new addresses rather than @imgtec.com addresses which will soon be dead.
Instances of the affected addresses throughout the tree are then mechanically replaced with the new @mips.com address.
Signed-off-by: Paul Burton <[email protected]> Cc: Deng-Cheng Zhu <[email protected]> Cc: Deng-Cheng Zhu <[email protected]> Acked-by: Dengcheng Zhu <[email protected]> Cc: Matt Redfearn <[email protected]> Cc: Matt Redfearn <[email protected]> Acked-by: Matt Redfearn <[email protected]> Cc: Andrew Morton <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|
| #
48c834be |
| 26-Oct-2017 |
Paul Burton <[email protected]> |
Update MIPS email addresses
MIPS will soon not be a part of Imagination Technologies, and as such many @imgtec.com email addresses will no longer be valid. This patch updates the addresses for those
Update MIPS email addresses
MIPS will soon not be a part of Imagination Technologies, and as such many @imgtec.com email addresses will no longer be valid. This patch updates the addresses for those who:
- Have 10 or more patches in mainline authored using an @imgtec.com email address, or any patches dated within the past year.
- Are still with Imagination but leaving as part of the MIPS business unit, as determined from an internal email address list.
- Haven't already updated their email address (ie. JamesH) or expressed a desire to be excluded (ie. Maciej).
- Acked v2 or earlier of this patch, which leaves Deng-Cheng, Matt & myself.
New addresses are of the form [email protected], and all verified against an internal email address list. An entry is added to .mailmap for each person such that get_maintainer.pl will report the new addresses rather than @imgtec.com addresses which will soon be dead.
Instances of the affected addresses throughout the tree are then mechanically replaced with the new @mips.com address.
Signed-off-by: Paul Burton <[email protected]> Cc: Deng-Cheng Zhu <[email protected]> Cc: Deng-Cheng Zhu <[email protected]> Acked-by: Dengcheng Zhu <[email protected]> Cc: Matt Redfearn <[email protected]> Cc: Matt Redfearn <[email protected]> Acked-by: Matt Redfearn <[email protected]> Cc: Andrew Morton <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/17540/ Signed-off-by: James Hogan <[email protected]>
show more ...
|
|
Revision tags: v4.14-rc6, v4.14-rc5, v4.14-rc4, v4.14-rc3, v4.14-rc2, v4.14-rc1, v4.13 |
|
| #
bdd1d2d3 |
| 01-Sep-2017 |
Christoph Hellwig <[email protected]> |
fs: fix kernel_read prototype
Use proper ssize_t and size_t types for the return value and count argument, move the offset last and make it an in/out argument like all other read/write helpers, and
fs: fix kernel_read prototype
Use proper ssize_t and size_t types for the return value and count argument, move the offset last and make it an in/out argument like all other read/write helpers, and make the buf argument a void pointer to get rid of lots of casts in the callers.
Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Al Viro <[email protected]>
show more ...
|
|
Revision tags: v4.13-rc7, v4.13-rc6, v4.13-rc5, v4.13-rc4, v4.13-rc3, v4.13-rc2, v4.13-rc1, v4.12, v4.12-rc7, v4.12-rc6, v4.12-rc5, v4.12-rc4, v4.12-rc3, v4.12-rc2, v4.12-rc1, v4.11, v4.11-rc8, v4.11-rc7 |
|
| #
c46f59e9 |
| 11-Apr-2017 |
James Cowgill <[email protected]> |
MIPS: Avoid BUG warning in arch_check_elf
arch_check_elf contains a usage of current_cpu_data that will call smp_processor_id() with preemption enabled and therefore triggers a "BUG: using smp_proce
MIPS: Avoid BUG warning in arch_check_elf
arch_check_elf contains a usage of current_cpu_data that will call smp_processor_id() with preemption enabled and therefore triggers a "BUG: using smp_processor_id() in preemptible" warning when an fpxx executable is loaded.
As a follow-up to commit b244614a60ab ("MIPS: Avoid a BUG warning during prctl(PR_SET_FP_MODE, ...)"), apply the same fix to arch_check_elf by using raw_current_cpu_data instead. The rationale quoted from the previous commit:
"It is assumed throughout the kernel that if any CPU has an FPU, then all CPUs would have an FPU as well, so it is safe to perform the check with preemption enabled - change the code to use raw_ variant of the check to avoid the warning."
Fixes: 46490b572544 ("MIPS: kernel: elf: Improve the overall ABI and FPU mode checks") Signed-off-by: James Cowgill <[email protected]> CC: <[email protected]> # 4.0+ Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/15951/ Signed-off-by: Ralf Baechle <[email protected]>
show more ...
|
|
Revision tags: v4.11-rc6, v4.11-rc5, v4.11-rc4, v4.11-rc3, v4.11-rc2, v4.11-rc1, v4.10, v4.10-rc8, v4.10-rc7, v4.10-rc6, v4.10-rc5, v4.10-rc4, v4.10-rc3, v4.10-rc2, v4.10-rc1, v4.9, v4.9-rc8, v4.9-rc7, v4.9-rc6, v4.9-rc5, v4.9-rc4, v4.9-rc3, v4.9-rc2, v4.9-rc1, v4.8, v4.8-rc8, v4.8-rc7, v4.8-rc6, v4.8-rc5, v4.8-rc4, v4.8-rc3, v4.8-rc2, v4.8-rc1 |
|
| #
97f2645f |
| 03-Aug-2016 |
Masahiro Yamada <[email protected]> |
tree-wide: replace config_enabled() with IS_ENABLED()
The use of config_enabled() against config options is ambiguous. In practical terms, config_enabled() is equivalent to IS_BUILTIN(), but the au
tree-wide: replace config_enabled() with IS_ENABLED()
The use of config_enabled() against config options is ambiguous. In practical terms, config_enabled() is equivalent to IS_BUILTIN(), but the author might have used it for the meaning of IS_ENABLED(). Using IS_ENABLED(), IS_BUILTIN(), IS_MODULE() etc. makes the intention clearer.
This commit replaces config_enabled() with IS_ENABLED() where possible. This commit is only touching bool config options.
I noticed two cases where config_enabled() is used against a tristate option:
- config_enabled(CONFIG_HWMON) [ drivers/net/wireless/ath/ath10k/thermal.c ]
- config_enabled(CONFIG_BACKLIGHT_CLASS_DEVICE) [ drivers/gpu/drm/gma500/opregion.c ]
I did not touch them because they should be converted to IS_BUILTIN() in order to keep the logic, but I was not sure it was the authors' intention.
Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Kees Cook <[email protected]> Cc: Stas Sergeev <[email protected]> Cc: Matt Redfearn <[email protected]> Cc: Joshua Kinard <[email protected]> Cc: Jiri Slaby <[email protected]> Cc: Bjorn Helgaas <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Markos Chandras <[email protected]> Cc: "Dmitry V. Levin" <[email protected]> Cc: yu-cheng yu <[email protected]> Cc: James Hogan <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Johannes Berg <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Al Viro <[email protected]> Cc: Will Drewry <[email protected]> Cc: Nikolay Martynov <[email protected]> Cc: Huacai Chen <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Daniel Borkmann <[email protected]> Cc: Leonid Yegoshin <[email protected]> Cc: Rafal Milecki <[email protected]> Cc: James Cowgill <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Ralf Baechle <[email protected]> Cc: Alex Smith <[email protected]> Cc: Adam Buchbinder <[email protected]> Cc: Qais Yousef <[email protected]> Cc: Jiang Liu <[email protected]> Cc: Mikko Rapeli <[email protected]> Cc: Paul Gortmaker <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: Brian Norris <[email protected]> Cc: Hidehiro Kawai <[email protected]> Cc: "Luis R. Rodriguez" <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Dave Hansen <[email protected]> Cc: "Kirill A. Shutemov" <[email protected]> Cc: Roland McGrath <[email protected]> Cc: Paul Burton <[email protected]> Cc: Kalle Valo <[email protected]> Cc: Viresh Kumar <[email protected]> Cc: Tony Wu <[email protected]> Cc: Huaitong Han <[email protected]> Cc: Sumit Semwal <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Juergen Gross <[email protected]> Cc: Jason Cooper <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: Andrea Gelmini <[email protected]> Cc: David Woodhouse <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Rabin Vincent <[email protected]> Cc: "Maciej W. Rozycki" <[email protected]> Cc: David Daney <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|
|
Revision tags: v4.7, v4.7-rc7 |
|
| #
1a770b85 |
| 08-Jul-2016 |
Paul Burton <[email protected]> |
MIPS: non-exec stack & heap when non-exec PT_GNU_STACK is present
The stack and heap have both been executable by default on MIPS until now. This patch changes the default to be non-executable, but
MIPS: non-exec stack & heap when non-exec PT_GNU_STACK is present
The stack and heap have both been executable by default on MIPS until now. This patch changes the default to be non-executable, but only for ELF binaries with a non-executable PT_GNU_STACK header present. This does apply to both the heap & the stack, despite the name PT_GNU_STACK, and this matches the behaviour of other architectures like ARM & x86.
Current MIPS toolchains do not produce the PT_GNU_STACK header, which means that we can rely upon this patch not changing the behaviour of existing binaries. The new default will only take effect for newly compiled binaries once toolchains are updated to support PT_GNU_STACK, and since those binaries are newly compiled they can be compiled expecting the change in default behaviour. Again this matches the way in which the ARM & x86 architectures handled their implementations of non-executable memory.
Signed-off-by: Paul Burton <[email protected]> Cc: Leonid Yegoshin <[email protected]> Cc: Maciej Rozycki <[email protected]> Cc: Faraz Shahbazker <[email protected]> Cc: Raghu Gandham <[email protected]> Cc: Matthew Fortune <[email protected]> Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/13765/ Signed-off-by: Ralf Baechle <[email protected]>
show more ...
|
|
Revision tags: v4.7-rc6, v4.7-rc5, v4.7-rc4, v4.7-rc3, v4.7-rc2, v4.7-rc1 |
|
| #
4939788e |
| 21-May-2016 |
Ralf Baechle <[email protected]> |
MIPS: Spelling fix lets -> let's
As noticed by Sergei in the discussion of Andrea Gelmini's patch series.
Signed-off-by: Ralf Baechle <[email protected]> Reported-by: Sergei Shtylyov <sergei.shty
MIPS: Spelling fix lets -> let's
As noticed by Sergei in the discussion of Andrea Gelmini's patch series.
Signed-off-by: Ralf Baechle <[email protected]> Reported-by: Sergei Shtylyov <[email protected]>
show more ...
|
|
Revision tags: v4.6, v4.6-rc7, v4.6-rc6, v4.6-rc5, v4.6-rc4, v4.6-rc3, v4.6-rc2, v4.6-rc1, v4.5, v4.5-rc7, v4.5-rc6, v4.5-rc5, v4.5-rc4, v4.5-rc3, v4.5-rc2, v4.5-rc1, v4.4, v4.4-rc8, v4.4-rc7, v4.4-rc6, v4.4-rc5, v4.4-rc4, v4.4-rc3, v4.4-rc2, v4.4-rc1 |
|
| #
503943e0 |
| 13-Nov-2015 |
Maciej W. Rozycki <[email protected]> |
MIPS: Add IEEE Std 754 conformance mode selection
Add an `ieee754=' kernel parameter to control IEEE Std 754 conformance mode.
Use separate flags copied from the respective CPU feature flags, and a
MIPS: Add IEEE Std 754 conformance mode selection
Add an `ieee754=' kernel parameter to control IEEE Std 754 conformance mode.
Use separate flags copied from the respective CPU feature flags, and adjusted according to the conformance mode selected, to make binaries requesting individual NaN encoding modes accepted or rejected as needed. Update the initial setting for FCSR and, in the full FPU emulation mode, its read-only mask accordingly. Accept the mode selection requested for legacy processors as well.
As with the EF_MIPS_NAN2008 ELF file header flag adjust both ABS2008 and NAN2008 bits at the same time, to match the choice made for hardware currently implemented.
Signed-off-by: Maciej W. Rozycki <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Matthew Fortune <[email protected]> Cc: [email protected] Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/11481/ Signed-off-by: Ralf Baechle <[email protected]>
show more ...
|
| #
2b5e869e |
| 13-Nov-2015 |
Maciej W. Rozycki <[email protected]> |
MIPS: ELF: Interpret the NAN2008 file header flag
Handle the EF_MIPS_NAN2008 ELF file header flag and refuse execution where there is no support in the FPU for the NaN encoding mode requested by a b
MIPS: ELF: Interpret the NAN2008 file header flag
Handle the EF_MIPS_NAN2008 ELF file header flag and refuse execution where there is no support in the FPU for the NaN encoding mode requested by a binary invoked. Ensure that the setting of the bit in the binary matches one in any intepreter used. Set the thread's initial FCSR contents according to the value of the EF_MIPS_NAN2008.
Set the values of the FCSR ABS2008 and NAN2008 bits both to the same value if possible, to take the approach taken with existing FPU hardware into account. As of now all implementations have both bits hardwired to the same value, that is both are fixed at 0 or both are fixed at 1, even though the architecture allows for implementations where the amount of control implemented with each of these two individual bits is independent of each other.
Signed-off-by: Maciej W. Rozycki <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Matthew Fortune <[email protected]> Cc: [email protected] Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/11479/ Signed-off-by: Ralf Baechle <[email protected]>
show more ...
|
| #
eb4bc076 |
| 13-Nov-2015 |
Maciej W. Rozycki <[email protected]> |
ELF: Also pass any interpreter's file header to `arch_check_elf'
Also pass any interpreter's file header to `arch_check_elf' so that any architecture handler can have a look at it if needed.
Signed
ELF: Also pass any interpreter's file header to `arch_check_elf'
Also pass any interpreter's file header to `arch_check_elf' so that any architecture handler can have a look at it if needed.
Signed-off-by: Maciej W. Rozycki <[email protected]> Acked-by: Andrew Morton <[email protected]> Acked-by: Al Viro <[email protected]> Cc: Matthew Fortune <[email protected]> Cc: [email protected] Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/11478/ Signed-off-by: Ralf Baechle <[email protected]>
show more ...
|
| #
2ed02dd4 |
| 13-Nov-2015 |
Maciej W. Rozycki <[email protected]> |
MIPS: Use a union to access the ELF file header
Rewrite `arch_elf_pt_proc' and `arch_check_elf' using a union to access the ELF file header.
Signed-off-by: Maciej W. Rozycki <[email protected]> Cc:
MIPS: Use a union to access the ELF file header
Rewrite `arch_elf_pt_proc' and `arch_check_elf' using a union to access the ELF file header.
Signed-off-by: Maciej W. Rozycki <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Matthew Fortune <[email protected]> Cc: [email protected] Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/11474/ Signed-off-by: Ralf Baechle <[email protected]>
show more ...
|
|
Revision tags: v4.3, v4.3-rc7, v4.3-rc6, v4.3-rc5, v4.3-rc4, v4.3-rc3, v4.3-rc2, v4.3-rc1, v4.2, v4.2-rc8, v4.2-rc7, v4.2-rc6, v4.2-rc5, v4.2-rc4, v4.2-rc3, v4.2-rc2, v4.2-rc1, v4.1, v4.1-rc8, v4.1-rc7, v4.1-rc6, v4.1-rc5, v4.1-rc4, v4.1-rc3 |
|
| #
620b1550 |
| 06-May-2015 |
Paul Burton <[email protected]> |
MIPS: fix FP mode selection in lieu of .MIPS.abiflags data
Commit 46490b572544 ("MIPS: kernel: elf: Improve the overall ABI and FPU mode checks") reworked the ELF FP ABI mode selection logic, but wh
MIPS: fix FP mode selection in lieu of .MIPS.abiflags data
Commit 46490b572544 ("MIPS: kernel: elf: Improve the overall ABI and FPU mode checks") reworked the ELF FP ABI mode selection logic, but when CONFIG_MIPS_O32_FP64_SUPPORT is enabled it breaks the use of binaries which have no PT_MIPS_ABIFLAGS program header & associated .MIPS.abiflags section.
A default mode is selected based upon whether the ELF contains MIPS32 or MIPS64 code, but that selection is made in arch_elf_pt_proc. arch_elf_pt_proc only executes when a PT_MIPS_ABIFLAGS program header is found. If one is not found then arch_elf_pt_proc is never called, and no default overall_fp_mode value is selected. When arch_check_elf is called, both abi0 & abi1 are MIPS_ABI_FP_UNKNOWN which leads to both prog_req & interp_req being set to none_req. none_req matches none of the conditions for mode selection at the end of arch_check_elf, so overall_fp_mode is left untouched. Finally once mips_set_personality_fp is called the BUG() in the default case is then hit & the kernel likely panics.
Fix this by moving the selection of a default overall mode to the start of arch_check_elf, which runs once per ELF executed regardless of whether it has a PT_MIPS_ABIFLAGS program header.
Signed-off-by: Paul Burton <[email protected]> Cc: Markos Chandras <[email protected]> Cc: Matthew Fortune <[email protected]> Cc: Ralf Baechle <[email protected]> Cc: [email protected] Cc: [email protected] # v4.0+ Patchwork: http://patchwork.linux-mips.org/patch/9978/ Signed-off-by: Ralf Baechle <[email protected]>
show more ...
|
|
Revision tags: v4.1-rc2, v4.1-rc1, v4.0, v4.0-rc7 |
|
| #
a49dc427 |
| 03-Apr-2015 |
Maciej W. Rozycki <[email protected]> |
MIPS: ELF: Drop `get_fp_abi'
Commit 46490b57 [MIPS: kernel: elf: Improve the overall ABI and FPU mode checks] reduced `get_fp_abi' to an elaborate pass-through. Drop it then.
Signed-off-by: Maciej
MIPS: ELF: Drop `get_fp_abi'
Commit 46490b57 [MIPS: kernel: elf: Improve the overall ABI and FPU mode checks] reduced `get_fp_abi' to an elaborate pass-through. Drop it then.
Signed-off-by: Maciej W. Rozycki <[email protected]> Cc: Markos Chandras <[email protected]> Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/9677/ Signed-off-by: Ralf Baechle <[email protected]>
show more ...
|
|
Revision tags: v4.0-rc6, v4.0-rc5, v4.0-rc4, v4.0-rc3, v4.0-rc2, v4.0-rc1, v3.19, v3.19-rc7, v3.19-rc6, v3.19-rc5, v3.19-rc4 |
|
| #
46490b57 |
| 08-Jan-2015 |
Markos Chandras <[email protected]> |
MIPS: kernel: elf: Improve the overall ABI and FPU mode checks
The previous implementation did not cover all possible FPU combinations and it silently allowed ABI incompatible objects to be loaded w
MIPS: kernel: elf: Improve the overall ABI and FPU mode checks
The previous implementation did not cover all possible FPU combinations and it silently allowed ABI incompatible objects to be loaded with the wrong ABI. For example, the previous logic would set the FP_64 ABI as the matching ABI for an FP_XX object combined with an FP_64A object. This was wrong, and the matching ABI should have been FP_64A. The previous logic is now replaced with a new one which determines the appropriate FPU mode to be used rather than the FP ABI. This has the advantage that the entire logic is much simpler since it is the FPU mode we are interested in rather than the FP ABI resulting to code simplifications. This also removes the now obsolete FP32XX_HYBRID_FPRS option.
Cc: Matthew Fortune <[email protected]> Cc: Paul Burton <[email protected]> Signed-off-by: Markos Chandras <[email protected]>
show more ...
|
| #
fd75a33e |
| 14-Jan-2015 |
James Cowgill <[email protected]> |
MIPS: ELF: fix loading o32 binaries on 64-bit kernels
Commit 90cee759f08a ("MIPS: ELF: Set FP mode according to .MIPS.abiflags") introduced checking of the .MIPS.abiflags ELF section but did so thro
MIPS: ELF: fix loading o32 binaries on 64-bit kernels
Commit 90cee759f08a ("MIPS: ELF: Set FP mode according to .MIPS.abiflags") introduced checking of the .MIPS.abiflags ELF section but did so through the native sized "elfhdr" and "elf_phdr" structures regardless whether the ELF was actually 32-bit or 64-bit. This produces wrong results when trying to use a 64-bit kernel to load o32 ELF files.
Change the uses of the generic elf structures to their 32-bit versions. Since the code bails out on any 64-bit cases, this is OK until they are implemented.
Fixes: 90cee759f08a ("MIPS: ELF: Set FP mode according to .MIPS.abiflags") Signed-off-by: James Cowgill <[email protected]> Cc: [email protected] Cc: Paul Burton <[email protected]> Reviewed-by: Maciej W. Rozycki <[email protected]> Patchwork: https://patchwork.linux-mips.org/patch/8932/ Signed-off-by: Ralf Baechle <[email protected]>
show more ...
|
|
Revision tags: v3.19-rc3, v3.19-rc2, v3.19-rc1, v3.18, v3.18-rc7, v3.18-rc6, v3.18-rc5, v3.18-rc4, v3.18-rc3, v3.18-rc2, v3.18-rc1, v3.17, v3.17-rc7, v3.17-rc6, v3.17-rc5 |
|
| #
f4af6fb2 |
| 11-Sep-2014 |
Paul Burton <[email protected]> |
MIPS: Kconfig option to better exercise/debug hybrid FPRs
The hybrid FPR scheme exists to allow for compatibility between existing FP32 code and newly compiled FP64A code. Such code should hopefully
MIPS: Kconfig option to better exercise/debug hybrid FPRs
The hybrid FPR scheme exists to allow for compatibility between existing FP32 code and newly compiled FP64A code. Such code should hopefully be rare in the real world, and for the moment is difficult to come across. All code except that built for the FP64 ABI can correctly execute using the hybrid FPR scheme, so debugging the hybrid FPR implementation can be eased by forcing all such code to use it. This is undesirable in general due to the trap & emulate overhead of the hybrid FPR implementation, but is a very useful option to have for debugging.
Signed-off-by: Paul Burton <[email protected]> Cc: [email protected] Cc: Alexander Viro <[email protected]> Cc: [email protected] Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/7680/ Signed-off-by: Ralf Baechle <[email protected]>
show more ...
|
| #
90cee759 |
| 11-Sep-2014 |
Paul Burton <[email protected]> |
MIPS: ELF: Set FP mode according to .MIPS.abiflags
This patch reads the .MIPS.abiflags section when it is present, and sets the FP mode of the task accordingly. Any loaded ELF files which do not con
MIPS: ELF: Set FP mode according to .MIPS.abiflags
This patch reads the .MIPS.abiflags section when it is present, and sets the FP mode of the task accordingly. Any loaded ELF files which do not contain a .MIPS.abiflags section will continue to observe the previous behaviour, that is FR=1 if EF_MIPS_FP64 is set else FR=0.
Signed-off-by: Paul Burton <[email protected]> Cc: [email protected] Cc: Alexander Viro <[email protected]> Cc: [email protected] Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/7681/ Signed-off-by: Ralf Baechle <[email protected]>
show more ...
|