kernel - Fix shared lock bug in kern_mutex.c
* When the last exclusive lock is unlocked or when downgrading an exclusive
lock to a shared lock, pending shared links must be processed. The
last 'lock count' is transfered to the first link, thus preventing the
lock from getting ripped out from under the transfer code.
* However, when multiple shared links are pending, it is possible for the
first recipient link to wakeup and release its lock before the unlock/drop
code is able to finish its scan, which places the lock in an unexpected
state. The lock count was only being incremented within the link scan
loop, once at a time.
* Fix the problem by applying a lock count representing ALL pending
shared lock links after the first one before processing the first link.
This ensures that the lock remains in a shared-lock state while the loop
is running.
* This fixes a race that can occur in HAMMER2.