diff options
author | David Gwynne <dlg@cvs.openbsd.org> | 2025-01-02 01:19:23 +0000 |
---|---|---|
committer | David Gwynne <dlg@cvs.openbsd.org> | 2025-01-02 01:19:23 +0000 |
commit | 89afd0943e7da8a2ff9f23a03e704d1aa29f1e39 (patch) | |
tree | 2ba8e745272f5aa8f0a92ad2ca2dd898fd50f64a /distrib/sets/lists/game/md.mac68k | |
parent | a7de3934889bfeb168d1ec3a3e61507b5f2a148f (diff) |
bluhm found that vfs_busy interacts badly with the rwlock change i
committed. the reason for this is that vfs_busy can call rw_enter with
RW_SLEEPFAIL, and while a thread is sleeping with SLEEPFAIL set, another
thread can actually destroy the mount the first thread is sleeping on.
destroy here means it actually frees the memory.
this works because current rwlocks do not touch the rwlock memory after
they sleep, they check the flag in the argument that was passed to it.
new rwlocks assume the rwlock they're sleeping on still exists after
they sleep, and updates some accounting after waking up. this is
incompatible with the subtle semantics that vfs is providing on top of
an rwlock.
this diff adds reference counting to struct mount. one ref is used by
the existing vfs_mount_alloc and vfs_mount free lifetime of the
mountpoint, but lets vfs_busy take a ref to the memory so it won't get
freed out from underneath it.
this also gets rid of the RW_SLEEPFAIL use in vfs_busy. the only reason
i can see that vfs_busy should fail to let a thread keep the rwlock
ownership is if the mount has been destroyed. vfs_mount_free sets a flag
that vfs_busy checks to see if that's the case or not.
this is the smallest change i could come up with to make vfs_busy safe
with the new rwlocks. i would suggest that in the future we should look
at having things take the struct mount ref before calling vfs_busy, but
that's a much bigger change.
ok claudio@ beck@ bluhm@
Diffstat (limited to 'distrib/sets/lists/game/md.mac68k')
0 files changed, 0 insertions, 0 deletions