On Tue, Apr 01, 2014 at 05:58:13PM +0200, Michael Haggerty wrote: > If the call to adjust_shared_perm() fails, lock_file returns -1, which > to the caller looks like any other failure to lock the file. So in > this case, roll back the lockfile before returning so that the lock > file is deleted immediately and the lockfile object is left in a > predictable state that (namely, unlocked). Previously, the lockfile > was retained until process cleanup in this situation. Another nice find. I wondered if we could test this, but I think it would be hard to trigger. The obvious reason for adjust_shared_perm to fail is that you do not have permissions on the file, but by definition you just created it. So I doubt this ever comes up in practice short of weird races (somebody dropping the "x" bit from an intermediate directory between the open() and chmod() or something). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html