Commit ee424b8
committed
runtime-fix #2: route __storeload_barrier to userland path under FSTACK
amd64 __storeload_barrier() uses `lock; addl $0,%gs:OFFSETOF_MONITORBUF`
when _KERNEL is defined, which accesses the per-CPU segment via the %gs
selector. That selector is set up by the FreeBSD kernel for in-kernel
threads, but never initialized for userland processes — so when F-Stack
runs the same instruction it dereferences an unmapped address and the
process dies with SIGSEGV.
After fix #1 unblocked uma_startup1, the next crash surfaced in
smr_create() (PC at +150 -> `lock addl $0x0,%gs:0x100`), with the stack:
smr_create -> zone_ctor -> uma_zcreate -> filelistinit -> mi_startup
The userland branch of __storeload_barrier already exists (uses
`lock; addl $0,-8(%rsp)` against the redzone, which is safe and equally
serializing on x86). Just include FSTACK in the predicate that selects
the userland implementation:
#if defined(_KERNEL) && !defined(FSTACK)
... %gs-based variant ...
#else /* !_KERNEL || FSTACK */
... rsp-based variant ...
#endif
Verified by disassembling libfstack.ro::smr_create after a clean rebuild:
the instruction is now `lock addl $0x0,-0x8(%rsp)` instead of
`lock addl $0x0,%gs:0x100`.1 parent 424f8a9 commit ee424b8
1 file changed
Lines changed: 9 additions & 3 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
322 | 322 | | |
323 | 323 | | |
324 | 324 | | |
325 | | - | |
| 325 | + | |
326 | 326 | | |
327 | 327 | | |
328 | | - | |
| 328 | + | |
| 329 | + | |
| 330 | + | |
| 331 | + | |
| 332 | + | |
| 333 | + | |
| 334 | + | |
329 | 335 | | |
330 | | - | |
| 336 | + | |
331 | 337 | | |
332 | 338 | | |
333 | 339 | | |
| |||
0 commit comments