15331d4399
Neither is Fedora-specific. A different host and a freshly built
userland simply drove code that Windows never reached.
tools/mkfs.c did not compile at all. The DT_UNKNOWN/DT_DIR/DT_REG
fallbacks sat above <dirent.h>, so on glibc -- which spells them as
enumerators -- the #ifndef asked before the header was read, always
answered "missing", and then the header's own enum expanded to
`enum { 0 = 0, ... }`. Move the fallbacks below the include. The
include cannot move up instead: it has to follow the #undef that ends
the `#define dirent schfs_dirent` block.
getstackpcs() page-faulted. It dereferenced rbp[1] without validating
rbp, and the guard rejected 0xffffffff -- dead code on x86-64, already
caught by the KERNBASE test -- while the value that actually turns up
is all-ones, which is above KERNBASE. rbp[1] then wrapped to 0x7 and
took trap 14. `cp` panicked the kernel every time. Bound rbp from
above and require 8-byte alignment.
That second one masks other bugs: getcallerpcs() runs on every lock
acquisition and again from the trap handler, so a walker that can
fault replaces a real diagnosis with a bogus one.
Baseline on the Fedora laptop is now green: make ports, make,
make schfs-check including the round-trip that had never run, and
bootcheck at 27/27 plus 108 [ok] across the extended suites.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.6 KiB
| name | description | metadata | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| schos-fedora-move-bugs | The two latent bugs the Fedora move exposed on 2026-08-09 — mkfs.c's DT_* ordering and the faulting stack walker in getstackpcs |
|
Moving to the Fedora laptop (schos-linux-machine) found two bugs that had been latent for a long time. Neither is Fedora-specific; a different host and a freshly built userland simply drove code Windows never reached.
1. tools/mkfs.c would not compile at all
The DT_UNKNOWN / DT_DIR / DT_REG fallbacks sat above #include <dirent.h>, with the other compatibility shims. glibc spells those as
enumerators (with matching macros), so #ifndef DT_UNKNOWN asked before the
header was read, always answered "missing", and defined them — after which the
header's own enum { DT_UNKNOWN = 0, ... } expanded to enum { 0 = 0, ... }
and died on a syntax error pointing at the #define, not the cause.
The fallbacks now live below the include, with a comment saying why.
<dirent.h> cannot move up instead: it has to follow the #undef dirent that
ends the #define dirent schfs_dirent block, or it defines xv6's struct
dirent rather than the host's. mingw-w64 never hit this because it genuinely
lacks the constants.
2. The stack walker page-faulted, in kernel/core/spinlock.c
Symptom: cp panicked the kernel with unexpected trap 14 ... cr2=0x7.
getstackpcs() walked the frame chain and dereferenced rbp[1] without
validating rbp. The guard rejected 0, anything below KERNBASE, and
0xffffffff — but the value that actually turns up is all-ones,
0xffffffffffffffff, which is above KERNBASE and passed. rbp[1] then
wrapped to address 0x7, exactly the reported cr2. The 0xffffffff test was
dead code on x86-64: it is far below KERNBASE, so the previous check already
caught it.
Fixed by bounding rbp from above (> (addr_t)-16) and requiring 8-byte
alignment, rather than naming another magic constant.
Why this one matters more than it looks. getcallerpcs() runs on every
lock acquisition and again from the trap handler, so a walker that can fault
replaces a real diagnosis with a second, more confusing one. A backtrace helper
must never be able to fault.
Why it surfaced now: make ports rebuilt toybox, and the new cp is not
the stale binary that had been staged in sysroot/. It drove
fileread → ilock → acquiresleep → acquire → getcallerpcs on a path
the old one did not. Rebuilding a stale userland is itself a test.