Jeff King <p...@peff.net> writes:
> So for a moment, lk->filename contains the name of the valuable file we
> are locking. If we get a signal at that moment, do we accidentally
> delete it in remove_lock_file?
> I think the answer is "no", because we check lk->owner before deleting,
> which will not match our pid (it should generally be zero due to xcalloc
> or static initialization, though perhaps we should clear it here).
That "generally be zero" no longer holds since 2/22, no?
> But that makes me wonder about the case of a reused lock. It will have
> lk->owner set from a previous invocation, and would potentially suffer
> from this problem. In other words, I think the change you are
> introducing does not have the problem, but the existing code does. :-/
Yes, I tend to agree.
> I didn't reproduce it experimentally, though. We should be able to just
> lk->owner = 0;
> before the initial strcpy to fix it, I would think.
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