[Bug 262836] [arm64] cacheline flush instruction (dc cvau) causes SIGSEGV from userland
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 26 Mar 2022 16:12:27 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262836
Bug ID: 262836
Summary: [arm64] cacheline flush instruction (dc cvau) causes
SIGSEGV from userland
Product: Base System
Version: CURRENT
Hardware: arm64
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: arm
Assignee: freebsd-arm@FreeBSD.org
Reporter: dch@freebsd.org
Created attachment 232744
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=232744&action=edit
https://git.sr.ht/~dch/src/commit/ae9221b85d18b6816276b8401734548f03b89013.patch
building OTP-25-RC2 from source yields a segfault during build. After
some build finagling, we can narrow this down to `dc cvau` failing:
```
sudo lldb ./bin/aarch64-unknown-freebsd14.0/beam.debug.jit
(lldb) target create "./bin/aarch64-unknown-freebsd14.0/beam.debug.jit"
Current executable set to
'/tmp/otp/bin/aarch64-unknown-freebsd14.0/beam.debug.jit' (aarch64).
(lldb) run
Process 40356 launched:
'/tmp/otp/bin/aarch64-unknown-freebsd14.0/beam.debug.jit' (aarch64)
Process 40356 stopped
* thread #1, name = 'beam.debug.jit', stop reason = signal SIGSEGV: address
access protected (fault address: 0xdee00000)
frame #0: 0x0000000000769f54
beam.debug.jit`__clear_cache(start=0x00000000dee00000, end=0x00000000dee0294c)
at clear_cache.c:119:7
116 const size_t dcache_line_size = 4 << ((ctr_el0 >> 16) & 15);
117 for (addr = xstart & ~(dcache_line_size - 1); addr < xend;
118 addr += dcache_line_size)
-> 119 __asm __volatile("dc cvau, %0" ::"r"(addr));
120 }
121 __asm __volatile("dsb ish");
122
(lldb) bt
* thread #1, name = 'beam.debug.jit', stop reason = signal SIGSEGV: address
access protected (fault address: 0xdee00000)
* frame #0: 0x0000000000769f54
beam.debug.jit`__clear_cache(start=0x00000000dee00000, end=0x00000000dee0294c)
at clear_cache.c:119:7
frame #1: 0x00000000003feb60
beam.debug.jit`BeamAssembler::_codegen(this=0x00000000d4b0e000,
allocator=0x000000008b16c018, executable_ptr=<unavailable>,
writable_ptr=<unavailable>) at beam_jit_common.cpp:128:5
frame #2: 0x00000000003ea4e8
beam.debug.jit`BeamGlobalAssembler::BeamGlobalAssembler(this=0x00000000d4b0e000,
allocator=0x000000008b16c018) at beam_asm_global.cpp:71:9
frame #3: 0x00000000004034dc beam.debug.jit`::beamasm_init() at
beam_jit_main.cpp:256:15
frame #4: 0x000000000049c908 beam.debug.jit`erl_init(ncpu=32,
proc_tab_sz=262144, legacy_proc_tab=0, port_tab_sz=65536,
port_tab_sz_ignore_files=0, legacy_port_tab=0, sys_proc_outst_req_lim=64,
time_correction=1, time_warp_mode=ERTS_NO_TIME_WARP_MODE,
node_tab_delete_delay=60, db_spin_count=ERTS_DB_SPNCNT_NORMAL) at
erl_init.c:355:5
frame #5: 0x000000000049b0a8 beam.debug.jit`erl_start(argc=1,
argv=0x000000008144b690) at erl_init.c:2424:5
frame #6: 0x00000000003c0828 beam.debug.jit`main(argc=1,
argv=0x000000008144b690) at erl_main.c:30:5
frame #7: 0x00000000003c063c beam.debug.jit`__start(argc=1,
argv=0x000000008144b690, env=0x000000008144b6a0, cleanup=<unavailable>) at
crt1_c.c:72:7
frame #8: 0x0000236d2a2f60d8 ld-elf.so.1`.rtld_start at rtld_start.S:41
(lldb) x/8i $pc-16
0x769f44: 0xcb0903ea neg x10, x9
0x769f48: 0x8a00014a and x10, x10, x0
0x769f4c: 0xeb01015f cmp x10, x1
0x769f50: 0x540000a2 b.hs 0x769f64 ; <+76> at
clear_cache.c:121:3
-> 0x769f54: 0xd50b7b2a dc cvau, x10
0x769f58: 0x8b09014a add x10, x10, x9
0x769f5c: 0xeb01015f cmp x10, x1
0x769f60: 0x54ffffa3 b.lo 0x769f54 ; <+60> at
clear_cache.c:119:7
(lldb) x/8i start
0xdee00000: 0xaa1f03e2 mov x2, xzr
0xdee00004: 0xaa1903e3 mov x3, x25
0xdee00008: 0xaa1a03e4 mov x4, x26
0xdee0000c: 0xaa0403e8 mov x8, x4
0xdee00010: 0x91020269 add x9, x19, #0x80 ; =0x80
0xdee00014: 0xf100ed1f cmp x8, #0x3b ; =0x3b
0xdee00018: 0x54000240 b.eq 0xdee00060
0xdee0001c: 0x37080148 tbnz w8, #0x1, 0xdee00044
(lldb) x/8i end
0xdee0294c: 0x00000000 udf #0x0
0xdee02950: 0x00000000 udf #0x0
0xdee02954: 0x00000000 udf #0x0
0xdee02958: 0x00000000 udf #0x0
0xdee0295c: 0x00000000 udf #0x0
0xdee02960: 0x00000000 udf #0x0
0xdee02964: 0x00000000 udf #0x0
0xdee02968: 0x00000000 udf #0x0
(lldb) x/8i $x0
0xdee00000: 0xaa1f03e2 mov x2, xzr
0xdee00004: 0xaa1903e3 mov x3, x25
0xdee00008: 0xaa1a03e4 mov x4, x26
0xdee0000c: 0xaa0403e8 mov x8, x4
0xdee00010: 0x91020269 add x9, x19, #0x80 ; =0x80
0xdee00014: 0xf100ed1f cmp x8, #0x3b ; =0x3b
0xdee00018: 0x54000240 b.eq 0xdee00060
0xdee0001c: 0x37080148 tbnz w8, #0x1, 0xdee00044
(lldb) x/8i $x1
0xdee0294c: 0x00000000 udf #0x0
0xdee02950: 0x00000000 udf #0x0
0xdee02954: 0x00000000 udf #0x0
0xdee02958: 0x00000000 udf #0x0
0xdee0295c: 0x00000000 udf #0x0
0xdee02960: 0x00000000 udf #0x0
0xdee02964: 0x00000000 udf #0x0
0xdee02968: 0x00000000 udf #0x0
(lldb) x/8i $x9
error: memory read failed for 0x0
(lldb) x/8i $x10
0xdee00000: 0xaa1f03e2 mov x2, xzr
0xdee00004: 0xaa1903e3 mov x3, x25
0xdee00008: 0xaa1a03e4 mov x4, x26
0xdee0000c: 0xaa0403e8 mov x8, x4
0xdee00010: 0x91020269 add x9, x19, #0x80 ; =0x80
0xdee00014: 0xf100ed1f cmp x8, #0x3b ; =0x3b
0xdee00018: 0x54000240 b.eq 0xdee00060
0xdee0001c: 0x37080148 tbnz w8, #0x1, 0xdee00044
(lldb)
```
andrew@ produced a small patch which seems to be sufficient (attached).
It would be great to have a fix for this included in 13.1-RELEASE arm64 if
possible.
--
You are receiving this mail because:
You are the assignee for the bug.