David Turner <dturner@xxxxxxxxxxxxxxxx> writes:
>> > + assert(removed == dir);
>> > + drop_ce_ref(dir->ce);
>>
>> This is curious. In remove_name_hash() you do not have the
>> corresponding assert. Why is it necessary here (or is it
>> unnecessary over there)?
>
> It is unnecessary in any case: it's an assert rather than a check for an
> expected (or even unexpected) case. That just happens to be where Keith
> first managed to track down the use-after free, so that's where he
> happened to put the assert while trying to debug it. I'm in general in
> favor of more asserts rather than fewer, so I would prefer to keep it
> in. But I can remove it if you like.
OK, it was just the inconsistency between the two made them look
curious, as if one of them is more likely to get broken, or the
patch author was not so sure about the assumption, or something.
>> > + add_ce_ref(ce);
>> > add_name_hash(istate, ce);
>> > }
>>
>> What happens to the existing entry that used to be istate->cache[nr],
>> which may or may not be 'ce' that is replacing it?
>>
>> It turns out that all three calling sites are safe, but it is not
>> immediately obvious why. Perhaps some comment in front of the
>> function is in order, to warn those who may have to add a new caller
>> or restructure the existing calling chain, that istate->cache[nr] is
>> expected not to hold a live reference when the function is called,
>> or something?
>
> Happy to add it if you want, but to me it was clear without because if
> there were a value in istate->cache[nr], that old value would be leaked.
OK, that's sort-of-cheating, but is a sound short-cut ;-).
>> > + if (old != istate->split_index->base->cache[new->index - 1]) {
>> > + struct cache_entry *ce = istate->split_index->base->cache[new->index - 1];
>> > + drop_ce_ref(ce);
>> > + }
>> > istate->split_index->base->cache[new->index - 1] = new;
>>
>> Does 'new' already have the right refcount at this point?
>
> I spoke to Keith, and he thinks we do need an add_ce_ref there. I'll fix
> that on the reroll. Duy, do you agree?
--
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