doing the cmpxchg, where another thread can successfully get a read hold
on the lock. That shouldn't fail anyone trying trying to get a read
hold. So for read locks, never bail just because the CAS fails, only bail
if we the status bits in the lock word say we can't have it.
acquiring the rwlock recursively in some paths.
Introduce _prop_rwlock_tryrdlock() and use it in these functions, so
that the rwlock is *always* acquired once, while here add some
_PROP_RWLOCK_OWNED asserts to verify.
This definitely fixes the "locking against myself" panics.
in config register).
This fixes the continuous interrupt stream previously seen. It is now
possible to run `ifconfig gem0 up`. However, "gem0: device timeout"
messages appear and we don't appear to receive any interrupts.
Simplify the mount locking. Remove all the crud to deal with recursion on
the mount lock, and crud to deal with unmount as another weirdo lock.
Hopefully this will once and for all fix the deadlocks with this. With this
commit there are two locks on each mount:
- krwlock_t mnt_unmounting. This is used to prevent unmount across critical
sections like getnewvnode(). It's only ever read locked with rw_tryenter(),
and is only ever write locked in dounmount(). A write hold can't be taken
on this lock if the current LWP could hold a vnode lock.
- kmutex_t mnt_updating. This is taken by threads updating the mount, for
example when going r/o -> r/w, and is only present to serialize updates.
In order to take this lock, a read hold must first be taken on
mnt_unmounting, and the two need to be held across the operation.
One effect of this change: previously if an unmount failed, we would make a
half hearted attempt to back out of it gracefully, but that was unlikely to
work in a lot of cases. Now while an unmount that will be aborted is in
progress, new file operations within the mount will fail instead of being
delayed. That is unlikely to be a problem though, because if the admin
requests unmount of a file system then s(he) has made a decision to deny
access to the resource.
When we read interface flags and capabilities from the kernel, take
care not to record them in our current environment (env), but record
them in the output environment (oenv), instead. This helps us get
interface capabilities and flags right.
to support IPv6 as well as IPv4 (a work in progress).
Make the second argument of af_status() a bool instead of an int.
Exit early with an error if the operator specifies an unsupported
address family on the command line. The change should help rc
scripts to detect that IPv6 support is missing from the kernel,
with 'ifconfig lo0 inet6'.
Start using prop_dictionary_util(3).
when prop_{array,dictionary}_copyout_ioctl() is called.
Introduce _PROP_RWLOCK_OWNED() which is a KASSERT(rw_lock_held(lock))
and use it in those two functions, also acquire the rwlock in other
places where it is required now.
This fixes a LOCKDEBUG panic "locking against myself", as reported by
Geoff C. Wing in current-users@.
- sys_sync: acquire a write lock on the mount since the operation modifies
the mount structure.
- sys_fchdir: use vfs_trybusy(). If an unmount is in progress, just fail it.
- vnode and cwd locks were being taken with proc_lock held, which is bad
because proc_lock can only be held for a short period of time.
- Processes could have continually forked and escaped notice, keeping
a reference to the old directory on top of which a new mount exists.
getvnode: Use vfs_trybusy, not vfs_busy. If unmount is in progress we
could deadlock, because vnode locks can be held during getnewvnode().
dounmount() locks in the reverse order (vfs_busy -> vnode).
puffs_getvnode() was inserting vnodes into mnt_vnodelist without taking
a reference to the mount for each. When vnodes are scrubbed, refs to the
vnodes mount structure are dropped => boom.
- change sc_rev numbers to match quirk numbers used in Realtek's driver
- tweak some register definitions
Taken from Realtek's FreeBSD driver.
Untested yet on 8168C, but no bad sideeffect on older chips.
