*BSD News Article 15028


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.