From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hua Zhong Subject: Re: [Linux-cluster] Re: GFS, what's remaining Date: Sun, 4 Sep 2005 11:03:21 -0700 Message-ID: <924c288305090411038aa80f8@mail.gmail.com> References: <20050901104620.GA22482@redhat.com> <200509040022.37102.phillips@istop.com> <20050903214653.1b8a8cb7.akpm@osdl.org> <200509040240.08467.phillips@istop.com> <20050904002828.3d26f64c.akpm@osdl.org> <20050904080102.GY8684@ca-server1.us.oracle.com> <20050904011805.68df8dde.akpm@osdl.org> <20050904091118.GZ8684@ca-server1.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Return-path: To: linux clustering , Andrew Morton , phillips@istop.com, wim.coekaerts@oracle.com, linux-fsdevel@vger.kernel.org, ak@suse.de, linux-kernel@vger.kernel.org In-Reply-To: <20050904091118.GZ8684@ca-server1.us.oracle.com> Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org > takelock domainxxx lock1 > do sutff > droplock domainxxx lock1 > > When someone kills the shell, the lock is leaked, becuase droplock isn't > called. Why not open the lock resource (or the lock space) instead of individual locks as file? It then looks like this: open lock space file takelock lockresource lock1 do stuff droplock lockresource lock1 close lock space file Then if you are killed the ->release of lock space file should take care of cleaning up all the locks