int r = lk->locked; // before
int r = lk->locked && lk->pid == myproc()->pid; // after
Seven callers, and every one of them is an assertion of the form
if (!holdingsleep(&b->lock)) panic("brelse");
whose entire purpose is to catch a process releasing a lock it never took.
Answering the weaker question disarms all of them: iunlock() on an inode locked
by another process, and brelse() on somebody else's buffer, both sailed through
and unlocked it underneath the real holder. Two processes then believe they hold
the same inode, and the corruption surfaces somewhere else entirely -- which is
exactly the shape of bug these panics exist to prevent.
Found while hunting the ls -lR hang. It is not proven to be that hang's cause,
and the instrumentation in the next commits says it is probably not. It is a
real defect regardless, and it re-arms the detector that would catch the rest.
myproc() is null on the boot path before the scheduler runs and acquiresleep()
stores 0 for that case, so this compares the same way rather than dereferencing
null. Checked that nothing touches a buffer that early, so the stricter
assertion cannot fire spuriously on boot.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2
An x86-64 operating system built from xv6, now largely rewritten: SMP,
a copy-on-write root filesystem (SchFS), PCI/USB/virtio drivers, a TTF
rasteriser, and a Linux-numbered syscall ABI.
No history before this point -- the tree was never under version control.
This commit exists so the rename that follows has something to undo to.
