summaryrefslogtreecommitdiffstats
path: root/sys/ufs
diff options
context:
space:
mode:
authorsnb <snb@FreeBSD.org>2009-06-25 20:40:13 +0000
committersnb <snb@FreeBSD.org>2009-06-25 20:40:13 +0000
commit5d2850ae03b3aae3b966028ceb9b1b04c7093197 (patch)
tree4037e45800143a968f40328f85b61e9f3daa55bd /sys/ufs
parent6d5618d67ce9b5926b533d242ff4e234e0f2a680 (diff)
downloadFreeBSD-src-5d2850ae03b3aae3b966028ceb9b1b04c7093197.zip
FreeBSD-src-5d2850ae03b3aae3b966028ceb9b1b04c7093197.tar.gz
Fix a bug reported by pho@ where one can induce a panic by decreasing
vfs.ufs.dirhash_maxmem below the current amount of memory used by dirhash. When ufsdirhash_build() is called with the memory in use greater than dirhash_maxmem, it attempts to free up memory by calling ufsdirhash_recycle(). If successful in freeing enough memory, ufsdirhash_recycle() leaves the dirhash list locked. But at this point in ufsdirhash_build(), the list is not explicitly unlocked after the call(s) to ufsdirhash_recycle(). When we next attempt to lock the dirhash list, we will get a "panic: _mtx_lock_sleep: recursed on non-recursive mutex dirhash list". Tested by: pho Approved by: dwmalone (mentor) MFC after: 3 weeks
Diffstat (limited to 'sys/ufs')
-rw-r--r--sys/ufs/ufs/ufs_dirhash.c5
1 files changed, 4 insertions, 1 deletions
diff --git a/sys/ufs/ufs/ufs_dirhash.c b/sys/ufs/ufs/ufs_dirhash.c
index 7f801af..e18b838 100644
--- a/sys/ufs/ufs/ufs_dirhash.c
+++ b/sys/ufs/ufs/ufs_dirhash.c
@@ -348,9 +348,12 @@ ufsdirhash_build(struct inode *ip)
int dirblocks, i, j, memreqd, nblocks, narrays, nslots, slot;
/* Take care of a decreased sysctl value. */
- while (ufs_dirhashmem > ufs_dirhashmaxmem)
+ while (ufs_dirhashmem > ufs_dirhashmaxmem) {
if (ufsdirhash_recycle(0) != 0)
return (-1);
+ /* Recycled enough memory, so unlock the list. */
+ DIRHASHLIST_UNLOCK();
+ }
/* Check if we can/should use dirhash. */
if (ip->i_size < ufs_mindirhashsize || OFSFMT(ip->i_vnode) ||
OpenPOWER on IntegriCloud