01 Oct, 2020
1 commit
-
[ Upstream commit 66d18dbda8469a944dfec6c49d26d5946efba218 ]
Without this we get lockdep failures. They're spurious failures as SMP isn't
up when ftrace_init_nop() is called. As far as I can tell the easiest fix is
to just take the lock, which also seems like the safest fix.Signed-off-by: Palmer Dabbelt
Acked-by: Guo Ren
Signed-off-by: Palmer Dabbelt
Signed-off-by: Sasha Levin
23 Sep, 2020
1 commit
-
[ Upstream commit 21190b74bcf3a36ebab9a715088c29f59877e1f3 ]
This invalidates local TLB after modifying the page tables during early init as
it's too early to handle suprious faults as we otherwise do.Fixes: f2c17aabc917 ("RISC-V: Implement compile-time fixed mappings")
Reported-by: Syven Wang
Signed-off-by: Syven Wang
Signed-off-by: Greentime Hu
Reviewed-by: Anup Patel
[Palmer: Cleaned up the commit text]
Signed-off-by: Palmer Dabbelt
Signed-off-by: Sasha Levin
05 Aug, 2020
1 commit
-
[ Upstream commit d0d8aae64566b753c4330fbd5944b88af035f299 ]
Currently, maximum number of mapper pages are set to the pfn calculated
from the memblock size of the memblock containing kernel. This will work
until that memblock spans the entire memory. However, it will be set to
a wrong value if there are multiple memblocks defined in kernel
(e.g. with efi runtime services).Set the the maximum value to the pfn calculated from dram size.
Signed-off-by: Atish Patra
Signed-off-by: Palmer Dabbelt
Signed-off-by: Sasha Levin
29 Jul, 2020
1 commit
-
[ Upstream commit 38b7c2a3ffb1fce8358ddc6006cfe5c038ff9963 ]
While digging through the recent mmiowb preemption issue it came up that
we aren't actually preventing IO from crossing a scheduling boundary.
While it's a bit ugly to overload smp_mb__after_spinlock() with this
behavior, it's what PowerPC is doing so there's some precedent.Signed-off-by: Palmer Dabbelt
Signed-off-by: Sasha Levin
22 Jul, 2020
1 commit
-
commit 0cac21b02ba5f3095fd2dcc77c26a25a0b2432ed upstream.
With the current 8KB stack size there are frequent overflows in a 64-bit
configuration. We may split IRQ stacks off in the future, but this fixes a
number of issues right now.Signed-off-by: Andreas Schwab
Reviewed-by: Anup Patel
[Palmer: mention irqstack in the commit text]
Fixes: 7db91e57a0ac ("RISC-V: Task implementation")
Cc: stable@vger.kernel.org
Signed-off-by: Palmer Dabbelt
Signed-off-by: Greg Kroah-Hartman
01 Jul, 2020
2 commits
-
[ Upstream commit e0d17c842c0f824fd4df9f4688709fc6907201e1 ]
As per the table 4.4 of version "20190608-Priv-MSU-Ratified" of the
RISC-V instruction set manual[0], the PTE permission bit combination of
"write+exec only" is reserved for future use. Hence, don't allow such
mapping request in mmap call.An issue is been reported by David Abdurachmanov, that while running
stress-ng with "sysbadaddr" argument, RCU stalls are observed on RISC-V
specific kernel.This issue arises when the stress-sysbadaddr request for pages with
"write+exec only" permission bits and then passes the address obtain
from this mmap call to various system call. For the riscv kernel, the
mmap call should fail for this particular combination of permission bits
since it's not valid.[0]: http://dabbelt.com/~palmer/keep/riscv-isa-manual/riscv-privileged-20190608-1.pdf
Signed-off-by: Yash Shah
Reported-by: David Abdurachmanov
[Palmer: Refer to the latest ISA specification at the only link I could
find, and update the terminology.]
Signed-off-by: Palmer Dabbelt
Signed-off-by: Sasha Levin -
[ Upstream commit 6c58f25e6938c073198af8b1e1832f83f8f0df33 ]
The argument passed to cmpxchg is not guaranteed to be sign
extended, but lr.w sign extends on RV64I. This makes cmpxchg
fail on clang built kernels when __old is negative.To fix this, we just cast __old to long which sign extends on
RV64I. With this fix, clang built RISC-V kernels now boot.Link: https://github.com/ClangBuiltLinux/linux/issues/867
Signed-off-by: Nathan Huckleberry
Signed-off-by: Palmer Dabbelt
Signed-off-by: Sasha Levin
03 Jun, 2020
1 commit
-
[ Upstream commit 0502bee37cdef755d63eee60236562e5605e2480 ]
Drop static declaration to fix following build error if FRAME_POINTER disabled,
riscv64-linux-ld: arch/riscv/kernel/perf_callchain.o: in function `.L0':
perf_callchain.c:(.text+0x2b8): undefined reference to `walk_stackframe'Reported-by: Hulk Robot
Signed-off-by: Kefeng Wang
Signed-off-by: Palmer Dabbelt
Signed-off-by: Sasha Levin
20 May, 2020
1 commit
-
[ Upstream commit 3c1918c8f54166598195d938564072664a8275b1 ]
When building with the LLVM linker this error occurrs:
LD arch/riscv/kernel/vdso/vdso-syms.o
ld.lld: error: no input filesThis happens because the lld treats -R as an alias to -rpath, as opposed
to ld where -R means --just-symbols.Use the long option name for compatibility between the two.
Link: https://github.com/ClangBuiltLinux/linux/issues/805
Reported-by: Dmitry Golovin
Reviewed-by: Nick Desaulniers
Signed-off-by: Ilie Halip
Reviewed-by: Fangrui Song
Signed-off-by: Palmer Dabbelt
Signed-off-by: Sasha Levin
14 May, 2020
1 commit
-
commit c749bb2d554825e007cbc43b791f54e124dadfce upstream.
The current max_pfn equals to zero. In this case, I found it caused users
cannot get some page information through /proc such as kpagecount in v5.6
kernel because of new sanity checks. The following message is displayed by
stress-ng test suite with the command "stress-ng --verbose --physpage 1 -t
1" on HiFive unleashed board.# stress-ng --verbose --physpage 1 -t 1
stress-ng: debug: [109] 4 processors online, 4 processors configured
stress-ng: info: [109] dispatching hogs: 1 physpage
stress-ng: debug: [109] cache allocate: reducing cache level from L3 (too high) to L0
stress-ng: debug: [109] get_cpu_cache: invalid cache_level: 0
stress-ng: info: [109] cache allocate: using built-in defaults as no suitable cache found
stress-ng: debug: [109] cache allocate: default cache size: 2048K
stress-ng: debug: [109] starting stressors
stress-ng: debug: [109] 1 stressor spawned
stress-ng: debug: [110] stress-ng-physpage: started [110] (instance 0)
stress-ng: error: [110] stress-ng-physpage: cannot read page count for address 0x3fd34de000 in /proc/kpagecount, errno=0 (Success)
stress-ng: error: [110] stress-ng-physpage: cannot read page count for address 0x3fd32db078 in /proc/kpagecount, errno=0 (Success)
...
stress-ng: error: [110] stress-ng-physpage: cannot read page count for address 0x3fd32db078 in /proc/kpagecount, errno=0 (Success)
stress-ng: debug: [110] stress-ng-physpage: exited [110] (instance 0)
stress-ng: debug: [109] process [110] terminated
stress-ng: info: [109] successful run completed in 1.00s
#After applying this patch, the kernel can pass the test.
# stress-ng --verbose --physpage 1 -t 1
stress-ng: debug: [104] 4 processors online, 4 processors configured stress-ng: info: [104] dispatching hogs: 1 physpage
stress-ng: info: [104] cache allocate: using defaults, can't determine cache details from sysfs
stress-ng: debug: [104] cache allocate: default cache size: 2048K
stress-ng: debug: [104] starting stressors
stress-ng: debug: [104] 1 stressor spawned
stress-ng: debug: [105] stress-ng-physpage: started [105] (instance 0) stress-ng: debug: [105] stress-ng-physpage: exited [105] (instance 0) stress-ng: debug: [104] process [105] terminated
stress-ng: info: [104] successful run completed in 1.01s
#Cc: stable@vger.kernel.org
Signed-off-by: Vincent Chen
Reviewed-by: Anup Patel
Reviewed-by: Yash Shah
Tested-by: Yash Shah
Signed-off-by: Palmer Dabbelt
Signed-off-by: Greg Kroah-Hartman
25 Mar, 2020
3 commits
-
[ Upstream commit a160eed4b783d7b250a32f7e5787c9867abc5686 ]
When looking for the memblock where the kernel lives, we should check
that the memory range associated to the memblock entirely comprises the
kernel image and not only intersects with it.Signed-off-by: Alexandre Ghiti
Reviewed-by: Anup Patel
Signed-off-by: Palmer Dabbelt
Signed-off-by: Sasha Levin -
[ Upstream commit aa2734202acc506d09c8e641db4da161f902df27 ]
Compilation errors trigger if ARCH_SPARSEMEM_ENABLE is enabled for
a nommu kernel. Since the sparsemem model does not make sense anyway
for the nommu case, do not allow selecting this option to always use
the flatmem model.Signed-off-by: Damien Le Moal
Reviewed-by: Anup Patel
Reviewed-by: Palmer Dabbelt
Signed-off-by: Palmer Dabbelt
Signed-off-by: Sasha Levin -
[ Upstream commit 0cff8bff7af886af0923d5c91776cd51603e531f ]
The compiler uses the PIC-relative method to access static variables
instead of GOT when the code model is PIC. Therefore, the limitation of
the access range from the instruction to the symbol address is +-2GB.
Under this circumstance, the kernel cannot load a kernel module if this
module has static per-CPU symbols declared by DEFINE_PER_CPU(). The reason
is that kernel relocates the .data..percpu section of the kernel module to
the end of kernel's .data..percpu. Hence, the distance between the per-CPU
symbols and the instruction will exceed the 2GB limits. To solve this
problem, the kernel should place the loaded module in the memory area
[&_end-2G, VMALLOC_END].Signed-off-by: Vincent Chen
Suggested-by: Alexandre Ghiti
Suggested-by: Anup Patel
Tested-by: Alexandre Ghiti
Tested-by: Carlos de Paula
Signed-off-by: Palmer Dabbelt
Signed-off-by: Sasha Levin
11 Feb, 2020
1 commit
-
commit f1003b787c00fbaa4b11619c6b23a885bfce8f07 upstream.
The BPF JIT incorrectly clobbered the a0 register, and did not flag
usage of s5 register when BPF stack was being used.Fixes: 2353ecc6f91f ("bpf, riscv: add BPF JIT for RV64G")
Signed-off-by: Björn Töpel
Signed-off-by: Daniel Borkmann
Link: https://lore.kernel.org/bpf/20191216091343.23260-2-bjorn.topel@gmail.com
Signed-off-by: Greg Kroah-Hartman
06 Feb, 2020
1 commit
-
[ Upstream commit 95f4d9cced96afa9c69b3da8e79e96102c84fc60 ]
Temporary files used in the VDSO build process linger on even after make
mrproper: vdso-dummy.o.tmp, vdso.so.dbg.tmp.Delete them once they're no longer needed.
Signed-off-by: Ilie Halip
Signed-off-by: Paul Walmsley
Signed-off-by: Sasha Levin
18 Jan, 2020
1 commit
-
[ Upstream commit 1833e327a5ea1d1f356fbf6ded0760c9ff4b0594 ]
This is needed by LKDTM (crash dump test module), it calls
flush_icache_range(), which on RISC-V turns into flush_icache_all(). On
other architectures, the actual implementation is exported, so follow
that precedence and export it here too.Fixes build of CONFIG_LKDTM that fails with:
ERROR: "flush_icache_all" [drivers/misc/lkdtm/lkdtm.ko] undefined!Signed-off-by: Olof Johansson
Signed-off-by: Paul Walmsley
Signed-off-by: Sasha Levin
15 Jan, 2020
1 commit
-
commit 20bda4ed62f507ed72e30e817b43c65fdba60be7 upstream.
This is required for clone3 which passes the TLS value through a
struct rather than a register.Signed-off-by: Amanieu d'Antras
Cc: linux-riscv@lists.infradead.org
Cc: # 5.3.x
Link: https://lore.kernel.org/r/20200102172413.654385-6-amanieu@gmail.com
Signed-off-by: Christian Brauner
Signed-off-by: Greg Kroah-Hartman
12 Jan, 2020
1 commit
-
[ Upstream commit 96bc4432f5ade1045521f3b247f516b1478166bd ]
All BPF JIT compilers except RISC-V's and MIPS' enforce a 33-tail calls
limit at runtime. In addition, a test was recently added, in tailcalls2,
to check this limit.This patch updates the tail call limit in RISC-V's JIT compiler to allow
33 tail calls. I tested it using the above selftest on an emulated
RISCV64.Fixes: 2353ecc6f91f ("bpf, riscv: add BPF JIT for RV64G")
Reported-by: Mahshid Khezri
Signed-off-by: Paul Chaignon
Signed-off-by: Daniel Borkmann
Acked-by: Björn Töpel
Acked-by: Martin KaFai Lau
Link: https://lore.kernel.org/bpf/966fe384383bf23a0ee1efe8d7291c78a3fb832b.1575916815.git.paul.chaignon@gmail.com
Signed-off-by: Sasha Levin
09 Jan, 2020
1 commit
-
commit 1d8f65798240b6577d8c44d20c8ea8f1d429e495 upstream.
The condition should be logical NOT to assign the hook address to parent
address. Because the return value 0 of function_graph_enter upon
success.Fixes: e949b6db51dc (riscv/function_graph: Simplify with function_graph_enter())
Signed-off-by: Zong Li
Reviewed-by: Steven Rostedt (VMware)
Cc: stable@vger.kernel.org
Signed-off-by: Paul Walmsley
Signed-off-by: Greg Kroah-Hartman
29 Oct, 2019
1 commit
-
For legacy I/O BARs (non-MMIO BARs) to work correctly on RISC-V Linux,
we need to establish a reserved memory region for them, so that drivers
that wish to use the legacy I/O BARs can issue reads and writes against
a memory region that is mapped to the host PCIe controller's I/O BAR
mapping.Signed-off-by: Yash Shah
Signed-off-by: Paul Walmsley
28 Oct, 2019
6 commits
-
Rather than adding prototypes for C functions called only by assembly
code, mark them as __visible. This avoids adding prototypes that will
never be used by the callers. Resolves the following sparse warnings:arch/riscv/kernel/irq.c:27:29: warning: symbol 'do_IRQ' was not declared. Should it be static?
arch/riscv/kernel/ptrace.c:151:6: warning: symbol 'do_syscall_trace_enter' was not declared. Should it be static?
arch/riscv/kernel/ptrace.c:165:6: warning: symbol 'do_syscall_trace_exit' was not declared. Should it be static?
arch/riscv/kernel/signal.c:295:17: warning: symbol 'do_notify_resume' was not declared. Should it be static?
arch/riscv/kernel/traps.c:92:1: warning: symbol 'do_trap_unknown' was not declared. Should it be static?
arch/riscv/kernel/traps.c:94:1: warning: symbol 'do_trap_insn_misaligned' was not declared. Should it be static?
arch/riscv/kernel/traps.c:96:1: warning: symbol 'do_trap_insn_fault' was not declared. Should it be static?
arch/riscv/kernel/traps.c:98:1: warning: symbol 'do_trap_insn_illegal' was not declared. Should it be static?
arch/riscv/kernel/traps.c:100:1: warning: symbol 'do_trap_load_misaligned' was not declared. Should it be static?
arch/riscv/kernel/traps.c:102:1: warning: symbol 'do_trap_load_fault' was not declared. Should it be static?
arch/riscv/kernel/traps.c:104:1: warning: symbol 'do_trap_store_misaligned' was not declared. Should it be static?
arch/riscv/kernel/traps.c:106:1: warning: symbol 'do_trap_store_fault' was not declared. Should it be static?
arch/riscv/kernel/traps.c:108:1: warning: symbol 'do_trap_ecall_u' was not declared. Should it be static?
arch/riscv/kernel/traps.c:110:1: warning: symbol 'do_trap_ecall_s' was not declared. Should it be static?
arch/riscv/kernel/traps.c:112:1: warning: symbol 'do_trap_ecall_m' was not declared. Should it be static?
arch/riscv/kernel/traps.c:124:17: warning: symbol 'do_trap_break' was not declared. Should it be static?
arch/riscv/kernel/smpboot.c:136:24: warning: symbol 'smp_callin' was not declared. Should it be static?Based on a suggestion from Luc Van Oostenryck.
This version includes changes based on feedback from Christoph Hellwig
.Signed-off-by: Paul Walmsley
Cc: Luc Van Oostenryck
Reviewed-by: Christoph Hellwig # for do_syscall_trace_* -
The __user annotations were removed from the {save,restore}_fp_state()
function signatures by commit 007f5c358957 ("Refactor FPU code in
signal setup/return procedures"), but should be present, and sparse
warns when they are not applied. Add them back in.This change should have no functional impact.
Signed-off-by: Paul Walmsley
Fixes: 007f5c358957 ("Refactor FPU code in signal setup/return procedures")
Cc: Alan Kao
Reviewed-by: Christoph Hellwig -
sparse identifies several missing prototypes caused by missing
preprocessor include directives:arch/riscv/kernel/cpufeature.c:16:6: warning: symbol 'has_fpu' was not declared. Should it be static?
arch/riscv/kernel/process.c:26:6: warning: symbol 'arch_cpu_idle' was not declared. Should it be static?
arch/riscv/kernel/reset.c:15:6: warning: symbol 'pm_power_off' was not declared. Should it be static?
arch/riscv/kernel/syscall_table.c:15:6: warning: symbol 'sys_call_table' was not declared. Should it be static?
arch/riscv/kernel/traps.c:149:13: warning: symbol 'trap_init' was not declared. Should it be static?
arch/riscv/kernel/vdso.c:54:5: warning: symbol 'arch_setup_additional_pages' was not declared. Should it be static?
arch/riscv/kernel/smp.c:64:6: warning: symbol 'arch_match_cpu_phys_id' was not declared. Should it be static?
arch/riscv/kernel/module-sections.c:89:5: warning: symbol 'module_frob_arch_sections' was not declared. Should it be static?
arch/riscv/mm/context.c:42:6: warning: symbol 'switch_mm' was not declared. Should it be static?Fix by including the appropriate header files in the appropriate
source files.This patch should have no functional impact.
Signed-off-by: Paul Walmsley
Reviewed-by: Christoph Hellwig -
Several functions and arrays which are only used in the files in which
they are declared are missing "static" qualifiers. Warnings for these
symbols are reported by sparse:arch/riscv/kernel/vdso.c:28:18: warning: symbol 'vdso_data' was not declared. Should it be static?
arch/riscv/mm/sifive_l2_cache.c:145:12: warning: symbol 'sifive_l2_init' was not declared. Should it be static?Resolve these warnings by marking them as static.
This version incorporates feedback from Greentime Hu
.Signed-off-by: Paul Walmsley
Reviewed-by: Christoph Hellwig
Cc: Greentime Hu -
sparse complains loudly when string literals associated with
preprocessor directives are split into multiple, separately quoted
strings across different lines:arch/riscv/mm/init.c:341:9: error: Expected ; at the end of type declaration
arch/riscv/mm/init.c:341:9: error: got "not use absolute addressing."
arch/riscv/mm/init.c:358:9: error: Trying to use reserved word 'do' as identifier
arch/riscv/mm/init.c:358:9: error: Expected ; at end of declaration
[ ... ]It turns out this doesn't compile. The existing Linux practice for
this situation is simply to use a single long line. So, fix by
concatenating the strings.This patch should have no functional impact.
This version incorporates changes based on feedback from Luc Van
Oostenryck .Signed-off-by: Paul Walmsley
Reviewed-by: Luc Van Oostenryck
Reviewed-by: Christoph Hellwig
Link: https://lore.kernel.org/linux-riscv/CAAhSdy2nX2LwEEAZuMtW_ByGTkHO6KaUEvVxRnba_ENEjmFayQ@mail.gmail.com/T/#mc1a58bc864f71278123d19a7abc083a9c8e37033
Fixes: 387181dcdb6c1 ("RISC-V: Always compile mm/init.c with cmodel=medany and notrace")
Cc: Anup Patel -
Add prototypes for assembly language functions defined in head.S,
and include these prototypes into C source files that call those
functions.This patch resolves the following warnings from sparse:
arch/riscv/kernel/setup.c:39:10: warning: symbol 'hart_lottery' was not declared. Should it be static?
arch/riscv/kernel/setup.c:42:13: warning: symbol 'parse_dtb' was not declared. Should it be static?
arch/riscv/kernel/smpboot.c:33:6: warning: symbol '__cpu_up_stack_pointer' was not declared. Should it be static?
arch/riscv/kernel/smpboot.c:34:6: warning: symbol '__cpu_up_task_pointer' was not declared. Should it be static?
arch/riscv/mm/fault.c:25:17: warning: symbol 'do_page_fault' was not declared. Should it be static?This change should have no functional impact.
Signed-off-by: Paul Walmsley
26 Oct, 2019
1 commit
-
If we always compile the get_break_insn_length inline function we can
remove the ifdefs and let dead code elimination take care of the warn
branch that is now unreadable because the report_bug stub always
returns BUG_TRAP_TYPE_BUG.Signed-off-by: Christoph Hellwig
Reviewed-by: Anup Patel
Signed-off-by: Paul Walmsley
24 Oct, 2019
4 commits
-
Remove various not required ifdefs and externs.
Signed-off-by: Christoph Hellwig
Reviewed-by: Anup Patel
Signed-off-by: Paul Walmsley -
Using CONFIG_SPARSEMEM_VMEMMAP instead of CONFIG_SPARSEMEM to fix
following build issue.riscv64-linux-ld: arch/riscv/mm/init.o: in function 'vmemmap_populate':
init.c:(.meminit.text+0x8): undefined reference to 'vmemmap_populate_basepages'Cc: Logan Gunthorpe
Fixes: d95f1a542c3d ("RISC-V: Implement sparsemem")
Signed-off-by: Kefeng Wang
Reviewed-by: Logan Gunthorpe
Signed-off-by: Paul Walmsley -
With CONFIG_SPARSEMEM and !CONFIG_SPARSEMEM_VMEMMAP,
arch/riscv/include/asm/pgtable.h: In function ‘mk_pte’:
include/asm-generic/memory_model.h:64:14: error: implicit declaration of function ‘page_to_section’; did you mean ‘present_section’? [-Werror=implicit-function-declaration]
int __sec = page_to_section(__pg); \
^~~~~~~~~~~~~~~Fixed by changing mk_pte() from inline function to macro.
Cc: Logan Gunthorpe
Fixes: d95f1a542c3d ("RISC-V: Implement sparsemem")
Signed-off-by: Kefeng Wang
[paul.walmsley@sifive.com: fixed checkpatch errors]
Signed-off-by: Paul Walmsley -
Failed to compile Fedora/RISCV kernel (5.4-rc3+) with sparsemem enabled:
fs/proc/kcore.c: In function 'read_kcore':
fs/proc/kcore.c:510:8: error: implicit declaration of function 'kern_addr_valid'; did you mean 'virt_addr_valid'? [-Werror=implicit-function-declaration]
510 | if (kern_addr_valid(start)) {
| ^~~~~~~~~~~~~~~
| virt_addr_validLooking at other architectures I don't see kern_addr_valid being guarded by
CONFIG_FLATMEM.Fixes: d95f1a542c3d ("RISC-V: Implement sparsemem")
Signed-off-by: David Abdurachmanov
Tested-by: David Abdurachmanov
Reviewed-by: Logan Gunthorpe
Signed-off-by: Paul Walmsley
16 Oct, 2019
1 commit
-
This patch fixes the virtual address layout in pgtable.h. The virtual
address of FIXADDR_START and VMEMMAP_START should not be overlapped.Fixes: d95f1a542c3d ("RISC-V: Implement sparsemem")
Signed-off-by: Greentime Hu
Reviewed-by: Anup Patel
[paul.walmsley@sifive.com: fixed patch description]
Signed-off-by: Paul Walmsley
15 Oct, 2019
3 commits
-
Remove a confusing comment on our local_flush_tlb_all()
implementation. Per an internal discussion with Andrew, while it's
true that the fence.i is not necessary, it's not the case that an
sfence.vma implies a fence.i. We also drop the section about
"flush[ing] the entire local TLB" to better align with the language in
section 4.2.1 "Supervisor Memory-Management Fence Instruction" of the
RISC-V Privileged Specification v20190608.Fixes: c901e45a999a1 ("RISC-V: `sfence.vma` orderes the instruction cache")
Reported-by: Alan Kao
Cc: Palmer Dabbelt
Cc: Andrew Waterman
Signed-off-by: Paul Walmsley -
Add a default "stdout-path" to the kernel DTS file, as is present in many
of the board DTS files elsewhere in the kernel tree. With this line
present, earlyconsole can be enabled by simply passing "earlycon" on the
kernel command line. No specific device details are necessary, since the
kernel will use the stdout-path as the default.Signed-off-by: Paul Walmsley
Reviewed-by: Atish Patra -
To make the code more straightforward, replace the switch statement
with an if statement.Suggested-by: Paul Walmsley
Signed-off-by: Vincent Chen
[paul.walmsley@sifive.com: cleaned up patch description; updated to
apply]
Link: https://lore.kernel.org/linux-riscv/20190927224711.GI4700@infradead.org/
Link: https://lore.kernel.org/linux-riscv/CABvJ_xiHJSB7P5QekuLRP=LBPzXXghAfuUpPUYb=a_HbnOQ6BA@mail.gmail.com/
Link: https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org/thread/VDCU2WOB6KQISREO4V5DTXEI2M7VOV55/
Cc: Christoph Hellwig
Signed-off-by: Paul Walmsley
10 Oct, 2019
1 commit
-
Since the enabling and disabling of IRQs within preempt_schedule_irq()
is contained in a need_resched() loop, we don't need the outer arch
code loop.Reviewed-by: Palmer Dabbelt
Signed-off-by: Valentin Schneider
Cc: Albert Ou
Cc: linux-riscv@lists.infradead.org
Signed-off-by: Paul Walmsley
08 Oct, 2019
3 commits
-
For the kernel space, all ebreak instructions are determined at compile
time because the kernel space debugging module is currently unsupported.
Hence, it should be treated as a bug if an ebreak instruction which does
not belong to BUG_TRAP_TYPE_WARN or BUG_TRAP_TYPE_BUG is executed in
kernel space. For the userspace, debugging module or user problem may
intentionally insert an ebreak instruction to trigger a SIGTRAP signal.
To approach the above two situations, the do_trap_break() will direct
the BUG_TRAP_TYPE_NONE ebreak exception issued in kernel space to die()
and will send a SIGTRAP to the trapped process only when the ebreak is
in userspace.Signed-off-by: Vincent Chen
Reviewed-by: Christoph Hellwig
[paul.walmsley@sifive.com: fixed checkpatch issue]
Signed-off-by: Paul Walmsley -
On RISC-V, when the kernel runs code on behalf of a user thread, and the
kernel executes a WARN() or WARN_ON(), the user thread will be sent
a bogus SIGTRAP. Fix the RISC-V kernel code to not send a SIGTRAP when
a WARN()/WARN_ON() is executed.Signed-off-by: Vincent Chen
Reviewed-by: Christoph Hellwig
[paul.walmsley@sifive.com: fixed subject]
Signed-off-by: Paul Walmsley -
When the CONFIG_GENERIC_BUG is disabled by disabling CONFIG_BUG, if a
kernel thread is trapped by BUG(), the whole system will be in the
loop that infinitely handles the ebreak exception instead of entering the
die function. To fix this problem, the do_trap_break() will always call
the die() to deal with the break exception as the type of break is
BUG_TRAP_TYPE_BUG.Signed-off-by: Vincent Chen
Reviewed-by: Christoph Hellwig
Signed-off-by: Paul Walmsley
02 Oct, 2019
1 commit
-
This fixes an error with how the FDT blob is reserved in memblock.
An incorrect physical address calculation exposed the FDT header to
unintended corruption, which typically manifested with of_fdt_raw_init()
faulting during late boot after fdt_totalsize() returned a wrong value.
Systems with smaller physical memory sizes more frequently trigger this
issue, as the kernel is more likely to allocate from the DMA32 zone
where bbl places the DTB after the kernel image.Commit 671f9a3e2e24 ("RISC-V: Setup initial page tables in two stages")
changed the mapping of the DTB to reside in the fixmap area.
Consequently, early_init_fdt_reserve_self() cannot be used anymore in
setup_bootmem() since it relies on __pa() to derive a physical address,
which does not work with dtb_early_va that is no longer a valid kernel
logical address.The reserved[0x1] region shows the effect of the pointer underflow
resulting from the __pa(initial_boot_params) offset subtraction:[ 0.000000] MEMBLOCK configuration:
[ 0.000000] memory size = 0x000000001fe00000 reserved size = 0x0000000000a2e514
[ 0.000000] memory.cnt = 0x1
[ 0.000000] memory[0x0] [0x0000000080200000-0x000000009fffffff], 0x000000001fe00000 bytes flags: 0x0
[ 0.000000] reserved.cnt = 0x2
[ 0.000000] reserved[0x0] [0x0000000080200000-0x0000000080c2dfeb], 0x0000000000a2dfec bytes flags: 0x0
[ 0.000000] reserved[0x1] [0xfffffff080100000-0xfffffff080100527], 0x0000000000000528 bytes flags: 0x0With the fix applied:
[ 0.000000] MEMBLOCK configuration:
[ 0.000000] memory size = 0x000000001fe00000 reserved size = 0x0000000000a2e514
[ 0.000000] memory.cnt = 0x1
[ 0.000000] memory[0x0] [0x0000000080200000-0x000000009fffffff], 0x000000001fe00000 bytes flags: 0x0
[ 0.000000] reserved.cnt = 0x2
[ 0.000000] reserved[0x0] [0x0000000080200000-0x0000000080c2dfeb], 0x0000000000a2dfec bytes flags: 0x0
[ 0.000000] reserved[0x1] [0x0000000080e00000-0x0000000080e00527], 0x0000000000000528 bytes flags: 0x0Fixes: 671f9a3e2e24 ("RISC-V: Setup initial page tables in two stages")
Signed-off-by: Albert Ou
Tested-by: Bin Meng
Reviewed-by: Anup Patel
Signed-off-by: Paul Walmsley
