Change Details

This is a follow up to the e-mail thread about vtryrecycle. It incorrectly holds a vnode and allows the usecount to grow and if it happens it aborts recycle leaving the other thread with an incorrectly held vnode. The fix is to do everything with the vnode interlock held. For this to happen the following provisions were added: - VOP_LOCK can now ignore the interlock - vn_start_write_nb is added. it guarantees no locks will be taken. Note this effectively depends on the switch to atomics (or per-cpu) as trylocking on the mnt interlock would be very likely to fail due to contention. This also changes semantics a little bit in that non-suspendable mount points get returned with a reference held. This can be augmented later to avoid refing them in the first place OR dropping the opt out altogether, now that the bottleneck is fixed. The same treatment can be made in vlrureclaim to avoid the need to re-check anything.

This is a follow up to the e-mail thread about vtryrecycle. It incorrectly holds a vnode and allows the usecount to grow and if it happens it aborts recycle leaving the other thread with an incorrectly held vnode. The fix is to do everything with the vnode interlock held. For this to happen the following provisions were added: - VOP_LOCK can now ignore the interlock - vn_start_write_nb is added. it guarantees no locks will be taken. Note this effectively depends on the switch to atomics (or per-cpu) as trylocking on the mnt interlock would be very likely to fail due to contention. This also changes semantics a little bit in that non-suspendable mount points get returned with a reference held. This can be augmented later to avoid refing them in the first place OR dropping the opt out altogether, now that the bottleneck is fixed. Semantics change is needed since by the time we determine the mount point is not suspendable per-cpu operation can be disabled and dropping the ref would require taking the lock. The same treatment can be made in vlrureclaim to avoid the need to re-check anything.

This is a follow up to the e-mail thread about vtryrecycle. It incorrectly holds a vnode and allows the usecount to grow and if it happens it aborts recycle leaving the other thread with an incorrectly held vnode. The fix is to do everything with the vnode interlock held. For this to happen the following provisions were added: - VOP_LOCK can now ignore the interlock - vn_start_write_nb is added. it guarantees no locks will be taken. Note this effectively depends on the switch to atomics (or per-cpu) as trylocking on the mnt interlock would be very likely to fail due to contention. This also changes semantics a little bit in that non-suspendable mount points get returned with a reference held. This can be augmented later to avoid refing them in the first place OR dropping the opt out altogether, now that the bottleneck is fixed. Semantics change is needed since by the time we determine the mount point is not suspendable per-cpu operation can be disabled and dropping the ref would require taking the lock. The same treatment can be made in vlrureclaim to avoid the need to re-check anything.