Michael Haggerty <mhag...@alum.mit.edu> writes:
> The first use of a lock_file object necessarily passes through
> lock_file(). The only precondition for that function is that the
> on_list field is zero, which is satisfied by a xcalloc()ed object.
> Subsequent uses of a lock_file object must *not* zero the object.
> lock_file objects are added to the lock_file_list and never removed. So
> zeroing a lock_file object would discard the rest of the linked list.
> But subsequent uses must also pass through lock_file(), which sees that
> on_list is set, and assumes that the object is in a self-consistent
> state as left by commit_lock_file() or rollback_lock_file().
> At least that's how it is supposed to work. But lock_file objects are
> in fact not cleaned up correctly in all circumstances. The next version
> of this patch series will work to fix that.
Thanks; I see the next round already posted to the list.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html