Skip to content

Finish RISC-V support #249

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 2 commits into from
May 3, 2021
Merged

Finish RISC-V support #249

merged 2 commits into from
May 3, 2021

Conversation

ojeda
Copy link
Member

@ojeda ojeda commented May 3, 2021

Finishes #225.

There were several problems:

  • No console output. This was due to missing CONFIG_SOC_VIRT
    and CONFIG_SERIAL_OF_PLATFORM.

  • Hanging QEMU. This was due to missing CONFIG_SOC_VIRT plus
    reboot not working in older QEMU versions for RISC-V.
    We provide a custom build of the latest QEMU (6.0.0, recently
    released) in https://github.com/Rust-for-Linux/ci-bin.

  • Broken boot for debug builds. Some debugging options under
    Kernel hacking do not seem to work for RISC-V (in our
    branched kernel version, that is).

Also take the chance to clean up the .configs a bit more.

ojeda added 2 commits May 3, 2021 18:02
@ojeda
Finish RISC-V support
0b9fc04 
Completes Rust-for-Linux#225.

There were several problems:

  - No console output. This was due to missing `CONFIG_SOC_VIRT`
    and `CONFIG_SERIAL_OF_PLATFORM`.

  - Hanging QEMU. This was due to missing `CONFIG_SOC_VIRT` plus
    reboot not working in older QEMU versions for RISC-V.
    We provide a custom build of the latest QEMU (6.0.0, recently
    released) in https://github.com/Rust-for-Linux/ci-bin.

  - Broken boot for debug builds. Some debugging options under
    `Kernel hacking` do not seem to work for RISC-V (in our
    branched kernel version, that is).

Also take the chance to clean up the `.config`s a bit more.

Signed-off-by: Miguel Ojeda <[email protected]>
@ojeda
docs: rust: riscv is maintained
3cbb62f 
We run it in the CI now (`riscv64` only for the moment).

Signed-off-by: Miguel Ojeda <[email protected]>
@ojeda ojeda merged commit 45ffe64 into Rust-for-Linux:rust May 3, 2021
@ojeda ojeda deleted the riscv branch May 3, 2021 16:36
@ojeda
Copy link
Member Author

ojeda commented May 3, 2021

Related: #66.

ojeda pushed a commit that referenced this pull request Mar 1, 2023
@chleroy @akpm00
kasan: fix Oops due to missing calls to kasan_arch_is_ready()
55d77ba 
On powerpc64, you can build a kernel with KASAN as soon as you build it
with RADIX MMU support.  However if the CPU doesn't have RADIX MMU, KASAN
isn't enabled at init and the following Oops is encountered.

  [    0.000000][    T0] KASAN not enabled as it requires radix!

  [    4.484295][   T26] BUG: Unable to handle kernel data access at 0xc00e000000804a04
  [    4.485270][   T26] Faulting instruction address: 0xc00000000062ec6c
  [    4.485748][   T26] Oops: Kernel access of bad area, sig: 11 [#1]
  [    4.485920][   T26] BE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
  [    4.486259][   T26] Modules linked in:
  [    4.486637][   T26] CPU: 0 PID: 26 Comm: kworker/u2:2 Not tainted 6.2.0-rc3-02590-gf8a023b0a805 #249
  [    4.486907][   T26] Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1200 0xf000005 of:SLOF,HEAD pSeries
  [    4.487445][   T26] Workqueue: eval_map_wq .tracer_init_tracefs_work_func
  [    4.488744][   T26] NIP:  c00000000062ec6c LR: c00000000062bb84 CTR: c0000000002ebcd0
  [    4.488867][   T26] REGS: c0000000049175c0 TRAP: 0380   Not tainted  (6.2.0-rc3-02590-gf8a023b0a805)
  [    4.489028][   T26] MSR:  8000000002009032 <SF,VEC,EE,ME,IR,DR,RI>  CR: 44002808  XER: 00000000
  [    4.489584][   T26] CFAR: c00000000062bb80 IRQMASK: 0
  [    4.489584][   T26] GPR00: c0000000005624d4 c000000004917860 c000000001cfc000 1800000000804a04
  [    4.489584][   T26] GPR04: c0000000003a2650 0000000000000cc0 c00000000000d3d8 c00000000000d3d8
  [    4.489584][   T26] GPR08: c0000000049175b0 a80e000000000000 0000000000000000 0000000017d78400
  [    4.489584][   T26] GPR12: 0000000044002204 c000000003790000 c00000000435003c c0000000043f1c40
  [    4.489584][   T26] GPR16: c0000000043f1c68 c0000000043501a0 c000000002106138 c0000000043f1c08
  [    4.489584][   T26] GPR20: c0000000043f1c10 c0000000043f1c20 c000000004146c40 c000000002fdb7f8
  [    4.489584][   T26] GPR24: c000000002fdb834 c000000003685e00 c000000004025030 c000000003522e90
  [    4.489584][   T26] GPR28: 0000000000000cc0 c0000000003a2650 c000000004025020 c000000004025020
  [    4.491201][   T26] NIP [c00000000062ec6c] .kasan_byte_accessible+0xc/0x20
  [    4.491430][   T26] LR [c00000000062bb84] .__kasan_check_byte+0x24/0x90
  [    4.491767][   T26] Call Trace:
  [    4.491941][   T26] [c000000004917860] [c00000000062ae70] .__kasan_kmalloc+0xc0/0x110 (unreliable)
  [    4.492270][   T26] [c0000000049178f0] [c0000000005624d4] .krealloc+0x54/0x1c0
  [    4.492453][   T26] [c000000004917990] [c0000000003a2650] .create_trace_option_files+0x280/0x530
  [    4.492613][   T26] [c000000004917a90] [c000000002050d90] .tracer_init_tracefs_work_func+0x274/0x2c0
  [    4.492771][   T26] [c000000004917b40] [c0000000001f9948] .process_one_work+0x578/0x9f0
  [    4.492927][   T26] [c000000004917c30] [c0000000001f9ebc] .worker_thread+0xfc/0x950
  [    4.493084][   T26] [c000000004917d60] [c00000000020be84] .kthread+0x1a4/0x1b0
  [    4.493232][   T26] [c000000004917e10] [c00000000000d3d8] .ret_from_kernel_thread+0x58/0x60
  [    4.495642][   T26] Code: 60000000 7cc802a6 38a00000 4bfffc78 60000000 7cc802a6 38a00001 4bfffc68 60000000 3d20a80e 7863e8c2 792907c6 <7c6348ae> 20630007 78630fe0 68630001
  [    4.496704][   T26] ---[ end trace 0000000000000000 ]---

The Oops is due to kasan_byte_accessible() not checking the readiness of
KASAN.  Add missing call to kasan_arch_is_ready() and bail out when not
ready.  The same problem is observed with ____kasan_kfree_large() so fix
it the same.

Also, as KASAN is not available and no shadow area is allocated for linear
memory mapping, there is no point in allocating shadow mem for vmalloc
memory as shown below in /sys/kernel/debug/kernel_page_tables

  ---[ kasan shadow mem start ]---
  0xc00f000000000000-0xc00f00000006ffff  0x00000000040f0000       448K         r  w       pte  valid  present        dirty  accessed
  0xc00f000000860000-0xc00f00000086ffff  0x000000000ac10000        64K         r  w       pte  valid  present        dirty  accessed
  0xc00f3ffffffe0000-0xc00f3fffffffffff  0x0000000004d10000       128K         r  w       pte  valid  present        dirty  accessed
  ---[ kasan shadow mem end ]---

So, also verify KASAN readiness before allocating and poisoning
shadow mem for VMAs.

Link: https://lkml.kernel.org/r/150768c55722311699fdcf8f5379e8256749f47d.1674716617.git.christophe.leroy@csgroup.eu
Fixes: 41b7a34 ("powerpc: Book3S 64-bit outline-only KASAN support")
Signed-off-by: Christophe Leroy <[email protected]>
Reported-by: Nathan Lynch <[email protected]>
Suggested-by: Michael Ellerman <[email protected]>
Cc: Alexander Potapenko <[email protected]>
Cc: Andrey Konovalov <[email protected]>
Cc: Andrey Ryabinin <[email protected]>
Cc: Dmitry Vyukov <[email protected]>
Cc: Vincenzo Frascino <[email protected]>
Cc: <[email protected]>	[5.19+]
Signed-off-by: Andrew Morton <[email protected]>
ojeda pushed a commit that referenced this pull request Apr 29, 2024
@saproj @storulf
mmc: moxart: fix handling of sgm->consumed, otherwise WARN_ON triggers
e027e72 
When e.g. 8 bytes are to be read, sgm->consumed equals 8 immediately after
sg_miter_next() call. The driver then increments it as bytes are read,
so sgm->consumed becomes 16 and this warning triggers in sg_miter_stop():
WARN_ON(miter->consumed > miter->length);

WARNING: CPU: 0 PID: 28 at lib/scatterlist.c:925 sg_miter_stop+0x2c/0x10c
CPU: 0 PID: 28 Comm: kworker/0:2 Tainted: G        W          6.9.0-rc5-dirty #249
Hardware name: Generic DT based system
Workqueue: events_freezable mmc_rescan
Call trace:.
 unwind_backtrace from show_stack+0x10/0x14
 show_stack from dump_stack_lvl+0x44/0x5c
 dump_stack_lvl from __warn+0x78/0x16c
 __warn from warn_slowpath_fmt+0xb0/0x160
 warn_slowpath_fmt from sg_miter_stop+0x2c/0x10c
 sg_miter_stop from moxart_request+0xb0/0x468
 moxart_request from mmc_start_request+0x94/0xa8
 mmc_start_request from mmc_wait_for_req+0x60/0xa8
 mmc_wait_for_req from mmc_app_send_scr+0xf8/0x150
 mmc_app_send_scr from mmc_sd_setup_card+0x1c/0x420
 mmc_sd_setup_card from mmc_sd_init_card+0x12c/0x4dc
 mmc_sd_init_card from mmc_attach_sd+0xf0/0x16c
 mmc_attach_sd from mmc_rescan+0x1e0/0x298
 mmc_rescan from process_scheduled_works+0x2e4/0x4ec
 process_scheduled_works from worker_thread+0x1ec/0x24c
 worker_thread from kthread+0xd4/0xe0
 kthread from ret_from_fork+0x14/0x38

This patch adds initial zeroing of sgm->consumed. It is then incremented
as bytes are read or written.

Signed-off-by: Sergei Antonov <[email protected]>
Cc: Linus Walleij <[email protected]>
Fixes: 3ee0e7c ("mmc: moxart-mmc: Use sg_miter for PIO")
Reviewed-by: Linus Walleij <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@ojeda