kernel - Change lockmgr LK_SHARED behavior to fix improper recursion return
authorMatthew Dillon <dillon@apollo.backplane.com>
Fri, 17 Aug 2012 00:40:38 +0000 (17:40 -0700)
committerMatthew Dillon <dillon@apollo.backplane.com>
Tue, 21 Aug 2012 03:59:42 +0000 (20:59 -0700)
commit9ca02554035fbdd8bb6afb48e3c2d0cafd981883
tree010795455b4c3153b9454010610cc5cd505dc343
parent4d289d94806fbaf2b1d0d81acf036409bdd0e735
kernel - Change lockmgr LK_SHARED behavior to fix improper recursion return

* When obtaining a LK_SHARED lock in a situation where you already own the
  lock LK_EXCLUSIVE, lockmgr would downgrade the lock to shared.

  This creates a very serious problem when large procedural recursions get
  a lock that is already being held exclusively but request a shared lock.
  When these recursions return the original top level will find its lock is
  no longer exclusive.

* This problem occured with vnode locks when a VOP_WRITE operation on a mmap'd
  space causes a VM fault which then turns around and issues a read().
  When the fault returns the vnode wound up locked shared instead of
  exclusive.

* Fix the problem by NOT downgrading an exclusive lock to shared when
  recursing on LK_SHARED.  Simply add another count to the exclusive
  lock.
sys/kern/kern_lock.c
sys/vfs/ufs/ffs_rawread.c