<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/riscv/kernel, branch linux-5.13.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.13.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.13.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2021-09-03T08:22:47Z</updated>
<entry>
<title>riscv: Ensure the value of FP registers in the core dump file is up to date</title>
<updated>2021-09-03T08:22:47Z</updated>
<author>
<name>Vincent Chen</name>
</author>
<published>2021-08-03T09:27:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9e04475feb82cf8e21032336420b5787851f0d87'/>
<id>urn:sha1:9e04475feb82cf8e21032336420b5787851f0d87</id>
<content type='text'>
commit 379eb01c21795edb4ca8d342503bd2183a19ec3a upstream.

The value of FP registers in the core dump file comes from the
thread.fstate. However, kernel saves the FP registers to the thread.fstate
only before scheduling out the process. If no process switch happens
during the exception handling process, kernel will not have a chance to
save the latest value of FP registers to thread.fstate. It will cause the
value of FP registers in the core dump file may be incorrect. To solve this
problem, this patch force lets kernel save the FP register into the
thread.fstate if the target task_struct equals the current.

Signed-off-by: Vincent Chen &lt;vincent.chen@sifive.com&gt;
Reviewed-by: Jisheng Zhang &lt;jszhang@kernel.org&gt;
Fixes: b8c8a9590e4f ("RISC-V: Add FP register ptrace support for gdb.")
Cc: stable@vger.kernel.org
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>riscv: Fix a number of free'd resources in init_resources()</title>
<updated>2021-08-26T12:35:18Z</updated>
<author>
<name>Petr Pavlu</name>
</author>
<published>2021-08-07T17:54:50Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2d1704c3fe301972c8e139f37561eaed8153cdf8'/>
<id>urn:sha1:2d1704c3fe301972c8e139f37561eaed8153cdf8</id>
<content type='text'>
[ Upstream commit aa3e1ba32e553e611a58145c2eb349802feaa6eb ]

Function init_resources() allocates a boot memory block to hold an array of
resources which it adds to iomem_resource. The array is filled in from its
end and the function then attempts to free any unused memory at the
beginning. The problem is that size of the unused memory is incorrectly
calculated and this can result in releasing memory which is in use by
active resources. Their data then gets corrupted later when the memory is
reused by a different part of the system.

Fix the size of the released memory to correctly match the number of unused
resource entries.

Fixes: ffe0e5261268 ("RISC-V: Improve init_resources()")
Signed-off-by: Petr Pavlu &lt;petr.pavlu@suse.com&gt;
Reviewed-by: Sunil V L &lt;sunilvl@ventanamicro.com&gt;
Acked-by: Nick Kossifidis &lt;mick@ics.forth.gr&gt;
Tested-by: Sunil V L &lt;sunilvl@ventanamicro.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>riscv: kexec: do not add '-mno-relax' flag if compiler doesn't support it</title>
<updated>2021-08-18T07:06:50Z</updated>
<author>
<name>Changbin Du</name>
</author>
<published>2021-07-22T02:17:15Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=33d2301ad61b388b9341938b9ada1be87868893c'/>
<id>urn:sha1:33d2301ad61b388b9341938b9ada1be87868893c</id>
<content type='text'>
commit 030d6dbf0c2e5fdf23ad29557f0c87a882993e26 upstream.

The RISC-V special option '-mno-relax' which to disable linker relaxations
is supported by GCC8+. For GCC7 and lower versions do not support this
option.

Fixes: fba8a8674f68 ("RISC-V: Add kexec support")
Signed-off-by: Changbin Du &lt;changbin.du@gmail.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>riscv: stacktrace: Fix NULL pointer dereference</title>
<updated>2021-08-12T11:32:05Z</updated>
<author>
<name>Jisheng Zhang</name>
</author>
<published>2021-07-16T13:40:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=747d62a533b557acf4d44ebefb4cd9c225e7fe8f'/>
<id>urn:sha1:747d62a533b557acf4d44ebefb4cd9c225e7fe8f</id>
<content type='text'>
[ Upstream commit 78d9d8005e4556448f398d876f29d0ca7ab8e398 ]

When CONFIG_FRAME_POINTER=y, calling dump_stack() can always trigger
NULL pointer dereference panic similar as below:

[    0.396060] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc5+ #47
[    0.396692] Hardware name: riscv-virtio,qemu (DT)
[    0.397176] Call Trace:
[    0.398191] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000960
[    0.399487] Oops [#1]
[    0.399739] Modules linked in:
[    0.400135] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc5+ #47
[    0.400570] Hardware name: riscv-virtio,qemu (DT)
[    0.400926] epc : walk_stackframe+0xc4/0xdc
[    0.401291]  ra : dump_backtrace+0x30/0x38
[    0.401630] epc : ffffffff80004922 ra : ffffffff8000496a sp : ffffffe000f3bd00
[    0.402115]  gp : ffffffff80cfdcb8 tp : ffffffe000f30000 t0 : ffffffff80d0b0cf
[    0.402602]  t1 : ffffffff80d0b0c0 t2 : 0000000000000000 s0 : ffffffe000f3bd60
[    0.403071]  s1 : ffffffff808bc2e8 a0 : 0000000000001000 a1 : 0000000000000000
[    0.403448]  a2 : ffffffff803d7088 a3 : ffffffff808bc2e8 a4 : 6131725dbc24d400
[    0.403820]  a5 : 0000000000001000 a6 : 0000000000000002 a7 : ffffffffffffffff
[    0.404226]  s2 : 0000000000000000 s3 : 0000000000000000 s4 : 0000000000000000
[    0.404634]  s5 : ffffffff803d7088 s6 : ffffffff808bc2e8 s7 : ffffffff80630650
[    0.405085]  s8 : ffffffff80912a80 s9 : 0000000000000008 s10: ffffffff804000fc
[    0.405388]  s11: 0000000000000000 t3 : 0000000000000043 t4 : ffffffffffffffff
[    0.405616]  t5 : 000000000000003d t6 : ffffffe000f3baa8
[    0.405793] status: 0000000000000100 badaddr: 0000000000000960 cause: 000000000000000d
[    0.406135] [&lt;ffffffff80004922&gt;] walk_stackframe+0xc4/0xdc
[    0.407032] [&lt;ffffffff8000496a&gt;] dump_backtrace+0x30/0x38
[    0.407797] [&lt;ffffffff803d7100&gt;] show_stack+0x40/0x4c
[    0.408234] [&lt;ffffffff803d9e5c&gt;] dump_stack+0x90/0xb6
[    0.409019] [&lt;ffffffff8040423e&gt;] ptdump_init+0x20/0xc4
[    0.409681] [&lt;ffffffff800015b6&gt;] do_one_initcall+0x4c/0x226
[    0.410110] [&lt;ffffffff80401094&gt;] kernel_init_freeable+0x1f4/0x258
[    0.410562] [&lt;ffffffff803dba88&gt;] kernel_init+0x22/0x148
[    0.410959] [&lt;ffffffff800029e2&gt;] ret_from_exception+0x0/0x14
[    0.412241] ---[ end trace b2ab92c901b96251 ]---
[    0.413099] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

The reason is the task is NULL when we finally call walk_stackframe()
the NULL is passed from __dump_stack():

|static void __dump_stack(void)
|{
|        dump_stack_print_info(KERN_DEFAULT);
|        show_stack(NULL, NULL, KERN_DEFAULT);
|}

Fix this issue by checking "task == NULL" case in walk_stackframe().

Fixes: eac2f3059e02 ("riscv: stacktrace: fix the riscv stacktrace when CONFIG_FRAME_POINTER enabled")
Signed-off-by: Jisheng Zhang &lt;jszhang@kernel.org&gt;
Reviewed-by: Atish Patra &lt;atish.patra@wdc.com&gt;
Tested-by: Wende Tan &lt;twd2.me@gmail.com&gt;
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>sched/core: Initialize the idle task with preemption disabled</title>
<updated>2021-07-14T15:06:21Z</updated>
<author>
<name>Valentin Schneider</name>
</author>
<published>2021-05-12T09:46:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=24c79a7e54ccfa29fb8cbf7ed8d1e48ff1ec6e3d'/>
<id>urn:sha1:24c79a7e54ccfa29fb8cbf7ed8d1e48ff1ec6e3d</id>
<content type='text'>
[ Upstream commit f1a0a376ca0c4ef1fc3d24e3e502acbb5b795674 ]

As pointed out by commit

  de9b8f5dcbd9 ("sched: Fix crash trying to dequeue/enqueue the idle thread")

init_idle() can and will be invoked more than once on the same idle
task. At boot time, it is invoked for the boot CPU thread by
sched_init(). Then smp_init() creates the threads for all the secondary
CPUs and invokes init_idle() on them.

As the hotplug machinery brings the secondaries to life, it will issue
calls to idle_thread_get(), which itself invokes init_idle() yet again.
In this case it's invoked twice more per secondary: at _cpu_up(), and at
bringup_cpu().

Given smp_init() already initializes the idle tasks for all *possible*
CPUs, no further initialization should be required. Now, removing
init_idle() from idle_thread_get() exposes some interesting expectations
with regards to the idle task's preempt_count: the secondary startup always
issues a preempt_disable(), requiring some reset of the preempt count to 0
between hot-unplug and hotplug, which is currently served by
idle_thread_get() -&gt; idle_init().

Given the idle task is supposed to have preemption disabled once and never
see it re-enabled, it seems that what we actually want is to initialize its
preempt_count to PREEMPT_DISABLED and leave it there. Do that, and remove
init_idle() from idle_thread_get().

Secondary startups were patched via coccinelle:

  @begone@
  @@

  -preempt_disable();
  ...
  cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);

Signed-off-by: Valentin Schneider &lt;valentin.schneider@arm.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Acked-by: Peter Zijlstra &lt;peterz@infradead.org&gt;
Link: https://lore.kernel.org/r/20210512094636.2958515-1-valentin.schneider@arm.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>riscv: xip: support runtime trap patching</title>
<updated>2021-06-10T23:16:06Z</updated>
<author>
<name>Vitaly Wool</name>
</author>
<published>2021-05-31T08:53:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5e63215c2f64079fbd011df5005c8bea63f149c2'/>
<id>urn:sha1:5e63215c2f64079fbd011df5005c8bea63f149c2</id>
<content type='text'>
RISCV_ERRATA_ALTERNATIVE patches text at runtime which is currently
not possible when the kernel is executed from the flash in XIP mode.
Since runtime patching concerns only traps at the moment, let's just
have all the traps reside in RAM anyway if RISCV_ERRATA_ALTERNATIVE
is set. Thus, these functions will be patch-able even when the .text
section is in flash.

Signed-off-by: Vitaly Wool &lt;vitaly.wool@konsulko.com&gt;
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
</content>
</entry>
<entry>
<title>RISC-V: Fix memblock_free() usages in init_resources()</title>
<updated>2021-06-02T04:16:42Z</updated>
<author>
<name>Wende Tan</name>
</author>
<published>2021-05-22T17:49:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=da2d48808fbd1eddefefe245c6c0e92a9195df8b'/>
<id>urn:sha1:da2d48808fbd1eddefefe245c6c0e92a9195df8b</id>
<content type='text'>
`memblock_free()` takes a physical address as its first argument.
Fix the wrong usages in `init_resources()`.

Fixes: ffe0e526126884cf036a6f724220f1f9b4094fd2 ("RISC-V: Improve init_resources()")
Fixes: 797f0375dd2ef5cdc68ac23450cbae9a5c67a74e ("RISC-V: Do not allocate memblock while iterating reserved memblocks")
Signed-off-by: Wende Tan &lt;twd2.me@gmail.com&gt;
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
</content>
</entry>
<entry>
<title>riscv: kexec: Fix W=1 build warnings</title>
<updated>2021-05-23T05:05:30Z</updated>
<author>
<name>Jisheng Zhang</name>
</author>
<published>2021-05-08T16:44:43Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bab0d47c0ebb50ae0bcfa4e84986a60113bf7d6b'/>
<id>urn:sha1:bab0d47c0ebb50ae0bcfa4e84986a60113bf7d6b</id>
<content type='text'>
Fixes the following W=1 build warning(s):

In file included from include/linux/kexec.h:28,
                 from arch/riscv/kernel/machine_kexec.c:7:
arch/riscv/include/asm/kexec.h:45:1: warning: ‘extern’ is not at beginning of declaration [-Wold-style-declaration]
   45 | const extern unsigned char riscv_kexec_relocate[];
      | ^~~~~
arch/riscv/include/asm/kexec.h:46:1: warning: ‘extern’ is not at beginning of declaration [-Wold-style-declaration]
   46 | const extern unsigned int riscv_kexec_relocate_size;
      | ^~~~~
arch/riscv/kernel/machine_kexec.c:125:6: warning: no previous prototype for ‘machine_shutdown’ [-Wmissing-prototypes]
  125 | void machine_shutdown(void)
      |      ^~~~~~~~~~~~~~~~
arch/riscv/kernel/machine_kexec.c:147:1: warning: no previous prototype for ‘machine_crash_shutdown’ [-Wmissing-prototypes]
  147 | machine_crash_shutdown(struct pt_regs *regs)
      | ^~~~~~~~~~~~~~~~~~~~~~
arch/riscv/kernel/machine_kexec.c:23: warning: Function parameter or member 'image' not described in 'kexec_image_info'
arch/riscv/kernel/machine_kexec.c:53: warning: Function parameter or member 'image' not described in 'machine_kexec_prepare'
arch/riscv/kernel/machine_kexec.c:114: warning: Function parameter or member 'image' not described in 'machine_kexec_cleanup'
arch/riscv/kernel/machine_kexec.c:148: warning: Function parameter or member 'regs' not described in 'machine_crash_shutdown'
arch/riscv/kernel/machine_kexec.c:167: warning: Function parameter or member 'image' not described in 'machine_kexec'

Signed-off-by: Jisheng Zhang &lt;jszhang@kernel.org&gt;
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
</content>
</entry>
<entry>
<title>riscv: kprobes: Fix build error when MMU=n</title>
<updated>2021-05-23T05:04:58Z</updated>
<author>
<name>Jisheng Zhang</name>
</author>
<published>2021-05-08T15:43:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=02ccdeed1817a587161ad091887e11ac8a2586b2'/>
<id>urn:sha1:02ccdeed1817a587161ad091887e11ac8a2586b2</id>
<content type='text'>
lkp reported a randconfig failure:

arch/riscv/kernel/probes/kprobes.c:90:22: error: use of undeclared identifier 'PAGE_KERNEL_READ_EXEC'

We implemented the alloc_insn_page() to allocate PAGE_KERNEL_READ_EXEC
page for kprobes insn page for STRICT_MODULE_RWX. But if MMU=n, we
should fall back to the generic weak alloc_insn_page() by generic
kprobe subsystem.

Fixes: cdd1b2bd358f ("riscv: kprobes: Implement alloc_insn_page()")
Signed-off-by: Jisheng Zhang &lt;jszhang@kernel.org&gt;
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
</content>
</entry>
<entry>
<title>riscv: stacktrace: fix the riscv stacktrace when CONFIG_FRAME_POINTER enabled</title>
<updated>2021-05-23T01:59:20Z</updated>
<author>
<name>Chen Huang</name>
</author>
<published>2021-04-29T07:03:48Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=eac2f3059e02382d91f8c887462083841d6ea2a3'/>
<id>urn:sha1:eac2f3059e02382d91f8c887462083841d6ea2a3</id>
<content type='text'>
As [1] and [2] said, the arch_stack_walk should not to trace itself, or it will
leave the trace unexpectedly when called. The example is when we do "cat
/sys/kernel/debug/page_owner", all pages' stack is the same.

arch_stack_walk+0x18/0x20
stack_trace_save+0x40/0x60
register_dummy_stack+0x24/0x5e
init_page_owner+0x2e

So we use __builtin_frame_address(1) as the first frame to be walked. And mark
the arch_stack_walk() noinline.

We found that pr_cont will affact pages' stack whose task state is RUNNING when
testing "echo t &gt; /proc/sysrq-trigger". So move the place of pr_cont and mark
the function dump_backtrace() noinline.

Also we move the case when task == NULL into else branch, and test for it in
"echo c &gt; /proc/sysrq-trigger".

[1] https://lore.kernel.org/lkml/20210319184106.5688-1-mark.rutland@arm.com/
[2] https://lore.kernel.org/lkml/20210317142050.57712-1-chenjun102@huawei.com/

Signed-off-by: Chen Huang &lt;chenhuang5@huawei.com&gt;
Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
Cc: stable@vger.kernel.org
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
</content>
</entry>
</feed>
