Jeff King <peff@xxxxxxxx> 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. > > -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