linux/arch/mips/kernel/unaligned.c, branch v5.6

MIPS: make CPU_HAS_LOAD_STORE_LR opt-out

2020-01-22T18:16:47Z

CPU_HAS_LOAD_STORE_LR was introduced in 932afdeec18b ("MIPS: Add Kconfig variable for CPUs with unaligned load/store instructions") to make code in kernel/unaligned.c and lib/mem{cpy,set}.S more intuitive and give a possibility to easily add new CPUs without these instruction sets in future. Hovewer, this variant is not optimal for mainly two reasons: * For now, we have 20+ CPUs with such instructions and only two (MIPS R6) without. It will obviously be more effective and straightforward to have an option for these two rather than for the rest. * You can easily miss the fact that you need to select this option when adding a new CPU, while all processors lacking these sets are well-known, so the probability of missing something is way much lower. We can address both points by turning CPU_HAS_LOAD_STORE_LR into opt-out CPU_NO_LOAD_STORE_LR. This also makes MIPS root Kconfig more clear and understandable. Signed-off-by: Alexander Lobakin Signed-off-by: Paul Burton Cc: Ralf Baechle Cc: Alexandre Belloni Cc: Microchip Linux Driver Support Cc: Will Deacon Cc: Greg Kroah-Hartman Cc: Masahiro Yamada Cc: Paul Walmsley Cc: Michal Simek Cc: Allison Randal Cc: Thomas Gleixner Cc: Eric W. Biederman Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org

signal: Remove task parameter from force_sig

2019-05-27T14:36:28Z

All of the remaining callers pass current into force_sig so remove the task parameter to make this obvious and to make misuse more difficult in the future. This also makes it clear force_sig passes current into force_sig_info. Signed-off-by: "Eric W. Biederman"

MIPS: MemoryMapID (MMID) Support

2019-02-04T18:56:41Z

Introduce support for using MemoryMapIDs (MMIDs) as an alternative to Address Space IDs (ASIDs). The major difference between the two is that MMIDs are global - ie. an MMID uniquely identifies an address space across all coherent CPUs. In contrast ASIDs are non-global per-CPU IDs, wherein each address space is allocated a separate ASID for each CPU upon which it is used. This global namespace allows a new GINVT instruction be used to globally invalidate TLB entries associated with a particular MMID across all coherent CPUs in the system, removing the need for IPIs to invalidate entries with separate ASIDs on each CPU. The allocation scheme used here is largely borrowed from arm64 (see arch/arm64/mm/context.c). In essence we maintain a bitmap to track available MMIDs, and MMIDs in active use at the time of a rollover to a new MMID version are preserved in the new version. The allocation scheme requires efficient 64 bit atomics in order to perform reasonably, so this support depends upon CONFIG_GENERIC_ATOMIC64=n (ie. currently it will only be included in MIPS64 kernels). The first, and currently only, available CPU with support for MMIDs is the MIPS I6500. This CPU supports 16 bit MMIDs, and so for now we cap our MMIDs to 16 bits wide in order to prevent the bitmap growing to absurd sizes if any future CPU does implement 32 bit MMIDs as the architecture manuals suggest is recommended. When MMIDs are in use we also make use of GINVT instruction which is available due to the global nature of MMIDs. By executing a sequence of GINVT & SYNC 0x14 instructions we can avoid the overhead of an IPI to each remote CPU in many cases. One complication is that GINVT will invalidate wired entries (in all cases apart from type 0, which targets the entire TLB). In order to avoid GINVT invalidating any wired TLB entries we set up, we make sure to create those entries using a reserved MMID (0) that we never associate with any address space. Also of note is that KVM will require further work in order to support MMIDs & GINVT, since KVM is involved in allocating IDs for guests & in configuring the MMU. That work is not part of this patch, so for now when MMIDs are in use KVM is disabled. Signed-off-by: Paul Burton Cc: linux-mips@vger.kernel.org

mips: kernel: no need to check return value of debugfs_create functions

2019-01-22T19:17:20Z

When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Cc: Ralf Baechle Cc: Paul Burton Cc: James Hogan Cc: Yangtao Li Cc: Andrew Morton Cc: Mike Rapoport Cc: Mathieu Malaterre Cc: Huacai Chen Cc: Marcin Nowakowski Cc: Yasha Cherikovsky Cc: linux-mips@vger.kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Paul Burton

Remove 'type' argument from access_ok() function

2019-01-04T02:57:57Z

Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument of the user address range verification function since we got rid of the old racy i386-only code to walk page tables by hand. It existed because the original 80386 would not honor the write protect bit when in kernel mode, so you had to do COW by hand before doing any user access. But we haven't supported that in a long time, and these days the 'type' argument is a purely historical artifact. A discussion about extending 'user_access_begin()' to do the range checking resulted this patch, because there is no way we're going to move the old VERIFY_xyz interface to that model. And it's best done at the end of the merge window when I've done most of my merges, so let's just get this done once and for all. This patch was mostly done with a sed-script, with manual fix-ups for the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form. There were a couple of notable cases: - csky still had the old "verify_area()" name as an alias. - the iter_iov code had magical hardcoded knowledge of the actual values of VERIFY_{READ,WRITE} (not that they mattered, since nothing really used it) - microblaze used the type argument for a debug printout but other than those oddities this should be a total no-op patch. I tried to fix up all architectures, did fairly extensive grepping for access_ok() uses, and the changes are trivial, but I may have missed something. Any missed conversion should be trivially fixable, though. Signed-off-by: Linus Torvalds

MIPS: Fix do_ade() closing brace indentation

2018-11-10T01:20:01Z

A closing brace in do_ade() has misleading indentation; fix it. Signed-off-by: Paul Burton Patchwork: https://patchwork.linux-mips.org/patch/21066/ Cc: linux-mips@linux-mips.org

MIPS: unaligned: Remove FP & MSA code when unsupported

2018-11-09T18:23:17Z

When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so remove support for floating point instructions from emulate_load_store_insn() & emulate_load_store_microMIPS(). This code should not be needed & relies upon access to FPU state in struct task_struct which will later be removed. Similarly & for the same reasons, when CONFIG_CPU_HAS_MSA=n remove support for MSA instructions. Since MSA support depends upon FP support this is implied when CONFIG_MIPS_FP_SUPPORT=n. Signed-off-by: Paul Burton Patchwork: https://patchwork.linux-mips.org/patch/21020/ Cc: linux-mips@linux-mips.org

MIPS: Ensure emulated FP sets PF_USED_MATH

2018-11-09T18:23:14Z

Emulated floating point instructions don't ensure that the PF_USED_MATH flag is set for the task. This results in a couple of inconsistencies: - ptrace will return the default initial state of FP registers rather than the values actually stored in struct thread_struct, hiding state that has been updated by emulated floating point instructions. - If a task migrates to a CPU with an FPU after having emulated floating point instructions then its floating point register state will be reset to the default ~0 bit pattern, losing state from the emulated instructions. Fix this by calling init_fp_ctx() from fpu_emulator_cop1Handler() to consistently initialize FP state if it was previously uninitialized, setting the PF_USED_MATH flag in the process. All callers of fpu_emulator_cop1Handler() either call lose_fpu(1) before it in order to save any live FPU registers to struct thread_struct, or in the case of do_cpu() already know that the task does not own an FPU so lose_fpu(1) would be a no-op. Since we know that saving FP context will be unnecessary in the case where FP context was just initialized we move this call into fpu_emulator_cop1Handler() too, providing consistency & avoiding needless duplication. Calls to own_fpu(1) are common after return from fpu_emulator_cop1Handler() too, but this would not be a no-op in the do_cpu() case so these are left as-is. A potential future improvement could be to have fpu_emulator_cop1Handler() restore FPU state automatically only if it saved it, though this may not be optimal if some callers are better off without their current calls to own_fpu(1). One potential example of this could be mipsr2_decoder() which as-is could end up saving & restoring FP context repeatedly & unnecessarily if emulating multiple FP instructions. Signed-off-by: Paul Burton Patchwork: https://patchwork.linux-mips.org/patch/21003/ Cc: linux-mips@linux-mips.org

MIPS: Add Kconfig variable for CPUs with unaligned load/store instructions

2018-09-26T20:38:18Z

MIPSR6 CPUs do not support unaligned load/store instructions (LWL, LWR, SWL, SWR and LDL, LDR, SDL, SDR for 64bit). Currently the MIPS tree has some special cases to avoid these instructions, and the code is testing for !CONFIG_CPU_MIPSR6. This patch declares a new Kconfig variable: CONFIG_CPU_HAS_LOAD_STORE_LR. This variable indicates that the CPU supports these instructions. Then, the patch does the following: - Carefully selects this option on all CPUs except MIPSR6. - Switches all the special cases to test for the new variable, and inverts the logic: '#ifndef CONFIG_CPU_MIPSR6' turns into '#ifdef CONFIG_CPU_HAS_LOAD_STORE_LR' and vice-versa. Also, when this variable is NOT selected (e.g. MIPSR6), CONFIG_GENERIC_CSUM will default to 'y', to compile generic C checksum code (instead of special assembly code that uses the unsupported instructions). This commit should not affect any existing CPU, and is required for future Lexra CPU support, that misses these instructions too. Signed-off-by: Yasha Cherikovsky Signed-off-by: Paul Burton Patchwork: https://patchwork.linux-mips.org/patch/20808/ Cc: Ralf Baechle Cc: Paul Burton Cc: James Hogan Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org

MIPS: Declare various variables & functions static

2017-08-29T13:21:55Z

We currently have various variables & functions which are only used within a single translation unit, but which we don't declare static. This causes various sparse warnings of the form: arch/mips/kernel/mips-r2-to-r6-emul.c:49:1: warning: symbol 'mipsr2emustats' was not declared. Should it be static? arch/mips/kernel/unaligned.c:1381:11: warning: symbol 'reg16to32st' was not declared. Should it be static? arch/mips/mm/mmap.c:146:15: warning: symbol 'arch_mmap_rnd' was not declared. Should it be static? Fix these & others by declaring various affected variables & functions static, avoiding the sparse warnings & redundant symbols. [ralf@linux-mips.org: Add Marcin's build fix.] Signed-off-by: Paul Burton Cc: linux-mips@linux-mips.org Cc: trivial@kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17176/ Signed-off-by: Ralf Baechle