Return to BSD News archive
Xref: sserve comp.bugs.4bsd:1942 comp.os.386bsd.bugs:549 Newsgroups: comp.bugs.4bsd,comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!saimiri.primate.wisc.edu!usenet.coe.montana.edu!news.u.washington.edu!ns1.nodak.edu!plains.NoDak.edu!tinguely From: tinguely@plains.NoDak.edu (Mark Tinguely) Subject: Re: flock broken - I could use some help Sender: usenet@ns1.nodak.edu (Usenet login) Message-ID: <C5y3z0.oKo@ns1.nodak.edu> Date: Fri, 23 Apr 1993 16:47:24 GMT References: <C5t8wH.Hs@moxie.hou.tx.us> <1993Apr21.184636.1121@cs.few.eur.nl> <1993Apr22.183734.4448@wotan.compaq.com> Nntp-Posting-Host: plains.nodak.edu Organization: North Dakota State University Lines: 37 In article <1993Apr22.183734.4448@wotan.compaq.com> hackney@wotan.compaq.com (Greg Hackney) writes: > >I wrote: >>> It appears that flock() is causing panic's and reboots. >>> Below is some test code to make it fail. > >In article <1993Apr21.184636.1121@cs.few.eur.nl> pk@cs.few.eur.nl writes: > >> The problem is a dangling pointer left in the lockf structure belonging to >> the current lock holder. >> ------- ufs_lockf.c ------- >> *** /tmp/da16367 Wed Apr 21 20:36:22 1993 >> --- ufs/ufs_lockf.c Wed Apr 21 20:35:47 1993 > >I applied your code fragment to ufs_lockf.c. However it didn't solve the >problem, as my system still panics and reboots using the aforementioned >test code. It appears the problem is complicated by the unlock in close(). By keeping the lockfile open by another process, you master/slave example does not crash my machine. I appears the lock of the slave stays around because closef() purposely does not remove the lock. when master ends, the slave lock gets freed twice. first in the unlocking of the master, the slave lock is placed into the ip->i_lockf and the the slave lock is scheduled to be awoken, also in the exit of master, close() is called and since the file count is now zero, closef() is called. closef() sends a unlock, freeing the lock. I am not sure why closef() purposely does not unlock the advisory lock. But if that can't be changed for some reason, after the tsleep, we better check if the lock has already been freed (ip->i_lockf may help here). This is just a progress report in case anyone wants to also look into the problem. I also will give more information when I have it. --mark.