qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] char: Fix removing wrong GSource that be found


From: Hailiang Zhang
Subject: Re: [Qemu-devel] [PATCH] char: Fix removing wrong GSource that be found by fd_in_tag
Date: Wed, 19 Apr 2017 08:40:31 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

On 2017/4/18 21:36, Eric Blake wrote:
On 04/14/2017 05:10 AM, Marc-André Lureau wrote:
Hi

----- Original Message -----
We use fd_in_tag to find a GSource, fd_in_tag is return value of
g_source_attach(GSource *source, GMainContext *context), the return
value is unique only in the same context, so we may get the same
values with different 'context' parameters.

It is no problem to find the right fd_in_tag by using
  g_main_context_find_source_by_id(GMainContext *context, guint source_id)
while there is only one default main context.

But colo-compare tries to create/use its own context, and if we pass wrong
'context' parameter with right fd_in_tag, we will find a wrong GSource
to handle. We tied to fix the related codes in commit b43dec, but it didn't
tied->tried

Please use a bit longer commit sha1, or full sha1, it will likely conflict 
otherwise in the future.
6 chars is indeed short, 7 is git's default as usually long enough,
although I've encountered collisions that require 8 chars.  [And google
has proved that you can have a collision across the entire hash,

Thanks for your explanation.  I didn't notice that before,
I have been always using the 6 chars hash to get the commit ...

although that is harder to generate.] I generally use 8 or so when
writing commit messages.  Fortunately, even if a collision is introduces
later, someone that is motivated enough can still resolve the collision
by filtering out any collisions that resolve to non-commits, and among
the remaining colliding SHA1 focus on the one that has a commit date
which predates the message with the reference.

Agreed, but I'd better to update the comment to make it clearer. thanks.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]