summaryrefslogtreecommitdiffstats
path: root/lib
diff options
context:
space:
mode:
authorkato <kato@FreeBSD.org>1997-04-15 12:56:57 +0000
committerkato <kato@FreeBSD.org>1997-04-15 12:56:57 +0000
commit071dc96075f3cb2f7f7b3861b0789616980c63c6 (patch)
treec87ed121be06d8d0709ca6154816546061200293 /lib
parent5d4c6d9502cbade0217bea3469418701486ce290 (diff)
downloadFreeBSD-src-071dc96075f3cb2f7f7b3861b0789616980c63c6.zip
FreeBSD-src-071dc96075f3cb2f7f7b3861b0789616980c63c6.tar.gz
Quick-hack to avoid `lock against myself' panic. It is not the real
fix! The ufs_link() assumes that vnode is not unlocked and tries to lock it in certain case. Because union_link calls VOP_LINK after locking vnode, vn_lock in ufs_link causes above panic. Currently, I don't know the real fix for a locking violation in union_link, but I think it is important to avoid panic. A vnode is unlocked before calling VOP_LINK and is locked after it if the vnode is not union fs. Even though panic went away, the process that access the union fs in which link was made will hang-up. Hang-up can be easily reproduced by following operation: mount -t union a b cd b ln foo bar ls
Diffstat (limited to 'lib')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud