[ovs-dev] Bug#681880: [bug 681880 1/3] lockfile: Fix hang locking through a dangling symlink.

[Bastian Blank]

On Fri, Jul 27, 2012 at 10:21:10AM -0700, Ben Pfaff wrote:
> On Fri, Jul 27, 2012 at 10:28:08AM +0200, Bastian Blank wrote:
> > I was unclear. You should first use realpath(3) on the database filename
> > and calculate the lock file from there. Otherwise there may be several
> > lock files for the same db.
> No.  We create a symlink for the lock file.  There is only one lock
> file, at the target of the symlink.

If it is a symlink, several lock files may exist.

> > Also, I see no lstat or realpath calls, so using symlinks is not safe
> > anyway. The daemon does not know the real location to calculate the lock
> > and temp file locations.
> It does not need to calculate the real location, because there is a
> symlink for the database file and a symlink for the lock file.

And how does compating the db work if the process does not know the real
location? rename(2) overwrites symlinks not the target.

> > This is no real problem. Obtaining an exclusive lock for the complete
> > file, not only parts, may include the right to replace it. This just
> > needs to be documented.
> Locking is an implementation detail.  There is no need to document it.

If you expect locking, it is not longer implementation detail but part
of the spec. Otherwise locking is optional.

> > However the current solution alows for a disappearing lock file and
> > may corrupt the database in this case.
> The lock file is never deleted.

You are working on a real, not a perfect system. Stuff can disappear by
the hand of the admin, especially if it is empty and apperantly unused.
And this does not get better with this symlink stunt.

Lets say, this package looks way too enterprisey:
- NIH
- Does not respect existing setup by the admin.
- Expects that nothing goes wrong and uses the way with maximum damage
  if this does not hold.

Bastian

-- 
Love sometimes expresses itself in sacrifice.
		-- Kirk, "Metamorphosis", stardate 3220.3