From: Stefan Beller <sbeller@google.com>
To: Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>,
Jonathan Nieder <jrnieder@gmail.com>,
Jeff Hostetler <git@jeffhostetler.com>
Subject: Re: [PATCHv2 1/2] hashmap.h: compare function has access to a data field
Date: Fri, 30 Jun 2017 11:00:19 -0700 [thread overview]
Message-ID: <CAGZ79kbWXuC2y97+nOsgvNhCCqg=2+VgOOvTbUn1LGpH4f0=PQ@mail.gmail.com> (raw)
In-Reply-To: <xmqqh8yxs7by.fsf@gitster.mtv.corp.google.com>
On Fri, Jun 30, 2017 at 10:39 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>> diff --git a/patch-ids.c b/patch-ids.c
>> index 9c0ab9e67a..b9b2ebbad0 100644
>> --- a/patch-ids.c
>> +++ b/patch-ids.c
>> @@ -37,6 +37,7 @@ int commit_patch_id(struct commit *commit, struct diff_options *options,
>> */
>> static int patch_id_cmp(struct patch_id *a,
>> struct patch_id *b,
>> + const void *unused_keydata,
>> struct diff_options *opt)
>> {
>> if (is_null_oid(&a->patch_id) &&
>> @@ -57,7 +58,8 @@ int init_patch_ids(struct patch_ids *ids)
>> ids->diffopts.detect_rename = 0;
>> DIFF_OPT_SET(&ids->diffopts, RECURSIVE);
>> diff_setup_done(&ids->diffopts);
>> - hashmap_init(&ids->patches, (hashmap_cmp_fn)patch_id_cmp, 256);
>> + hashmap_init(&ids->patches, (hashmap_cmp_fn)patch_id_cmp,
>> + &ids->diffopts, 256);
>> return 0;
>> }
>>
>> @@ -93,7 +95,7 @@ struct patch_id *has_commit_patch_id(struct commit *commit,
>> if (init_patch_id_entry(&patch, commit, ids))
>> return NULL;
>>
>> - return hashmap_get(&ids->patches, &patch, &ids->diffopts);
>> + return hashmap_get(&ids->patches, &patch, NULL);
>> }
+cc Peff
>
> This actually makes me wonder if we can demonstrate an existing
> breakage in tests. The old code used to pass NULL to the diffopts,
> causing it to be passed down through commit_patch_id() function down
> to diff_tree_oid() or diff_root_tree_oid(). When the codepath
> triggers the issue that Peff warned about in his old article (was it
> about rehashing or something?) that makes two entries compared
> (i.e. not using keydata, because we are not comparing an existing
> entry with a key and data only to see if that already exists in the
> hashmap), wouldn't that cause ll_diff_tree_oid() that is called from
> diff_tree_oid() to dereference NULL?
>
> Thanks.
I am at a loss here after re-reading your answer over and over,
but I think you are asking if patch_id_cmp can break, as
we have a callchain like
patch_id_cmp
commit_patch_id
(diff_root_tree_oid)
diff_tree_oid
ll_diff_tree_oid
passing diff_options down there, and patch_id_cmp may have
gotten NULL.
The answer is no, it was safe. (by accident?)
That is because we never use hashmap_get_next
on the hashmap that uses patch_id_cmp as the compare
function.
hashmap_get_next is the only function that does not pass
on a keydata, any other has valid caller provided keydata.
Thanks,
Stefan
next prev parent reply other threads:[~2017-06-30 18:00 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-29 1:13 [PATCH 0/2] Introduce data field in hashmap and migrate docs to header Stefan Beller
2017-06-29 1:13 ` [PATCH 1/2] hashmap.h: compare function has access to a data field Stefan Beller
2017-06-29 18:06 ` Junio C Hamano
2017-06-29 18:11 ` Junio C Hamano
2017-06-29 18:20 ` Stefan Beller
2017-06-30 17:26 ` Junio C Hamano
2017-06-29 1:13 ` [PATCH 2/2] hashmap: migrate documentation from Documentation/technical into header Stefan Beller
2017-06-29 13:25 ` Jeff Hostetler
2017-06-29 21:18 ` Jonathan Nieder
2017-06-29 23:41 ` Stefan Beller
2017-06-29 23:53 ` [PATCHv2 0/2] Introduce data field in hashmap and migrate docs to header Stefan Beller
2017-06-29 23:53 ` [PATCHv2 1/2] hashmap.h: compare function has access to a data field Stefan Beller
2017-06-30 17:34 ` Junio C Hamano
2017-06-30 17:41 ` Stefan Beller
2017-06-30 18:47 ` Junio C Hamano
2017-06-30 18:57 ` Stefan Beller
2017-06-30 17:39 ` Junio C Hamano
2017-06-30 18:00 ` Stefan Beller [this message]
2017-06-30 18:40 ` Junio C Hamano
2017-06-29 23:53 ` [PATCHv2 2/2] hashmap: migrate documentation from Documentation/technical into header Stefan Beller
2017-06-30 19:14 ` [PATCHv3 0/3] Introduce data field in hashmap and migrate docs to header Stefan Beller
2017-06-30 19:14 ` [PATCHv3 1/3] hashmap.h: compare function has access to a data field Stefan Beller
2017-06-30 19:14 ` [PATCHv3 2/3] patch-ids.c: use hashmap correctly Stefan Beller
2017-06-30 19:50 ` Junio C Hamano
2017-07-05 9:00 ` Jeff King
2017-06-30 19:14 ` [PATCHv3 3/3] hashmap: migrate documentation from Documentation/technical into header Stefan Beller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGZ79kbWXuC2y97+nOsgvNhCCqg=2+VgOOvTbUn1LGpH4f0=PQ@mail.gmail.com' \
--to=sbeller@google.com \
--cc=git@jeffhostetler.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).