From: Eric Blake <eblake@redhat.com>
To: "Marc-André Lureau" <marcandre.lureau@redhat.com>,
zhanghailiang <zhang.zhanghailiang@huawei.com>
Cc: pbonzini@redhat.com, qemu-devel@nongnu.org,
zhangchen fnst <zhangchen.fnst@cn.fujitsu.com>
Subject: Re: [Qemu-devel] [PATCH] char: Fix removing wrong GSource that be found by fd_in_tag
Date: Tue, 18 Apr 2017 08:36:29 -0500 [thread overview]
Message-ID: <be3b415e-9f51-e2e1-a06e-6d44cdc3baa3@redhat.com> (raw)
In-Reply-To: <1167061760.27389486.1492164610590.JavaMail.zimbra@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]
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,
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.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2017-04-18 13:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-14 3:41 [Qemu-devel] [PATCH] char: Fix removing wrong GSource that be found by fd_in_tag zhanghailiang
2017-04-14 10:10 ` Marc-André Lureau
2017-04-14 10:43 ` Hailiang Zhang
2017-04-18 13:36 ` Eric Blake [this message]
2017-04-19 0:40 ` Hailiang Zhang
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=be3b415e-9f51-e2e1-a06e-6d44cdc3baa3@redhat.com \
--to=eblake@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=zhang.zhanghailiang@huawei.com \
--cc=zhangchen.fnst@cn.fujitsu.com \
/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.
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 NNTP newsgroup(s).