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>
Fri, 17 Aug 2012 00:40:38 +0000 (17:40 -0700)
commit87f32d7cb3198c80dd8299ecdd884e86d5ac69f9
tree4a2e92d674f3c75c0f87d3c9b8548e06f9e1a864
parentab3e1edd524fbb06adf34b8a5d37c2789a379c4f
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