From: Jim Fehlig <jfehlig@suse.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Bamvor Jian Zhang <bjzhang@suse.com>,
Ian Campbell <Ian.Campbell@citrix.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH 2/2] libxl: fix stale timeout event callback race
Date: Wed, 12 Dec 2012 11:01:09 -0700 [thread overview]
Message-ID: <50C8C665.2030202@suse.com> (raw)
In-Reply-To: <20680.49391.646654.814456@mariner.uk.xensource.com>
Ian Jackson wrote:
> Jim Fehlig writes ("Re: [Xen-devel] [PATCH 2/2] libxl: fix stale timeout event callback race"):
>
>> Ian Jackson wrote:
>>
>>> Specifically, this code has an integer arithmetic overflow.
>>>
>> Well, this patch is removing that buggy code :).
>>
>
> I think you need to have some code somewhere which does the
> complicated arithmetic dance to avoid the integer overflow. Does your
> timer registration function have the same bug ?
>
Ah yes. I'll take care of it following your suggestion around
beforepoll_internal.
>
>> After again reading
>> libxl_event.h, I'm considering the below patch in the libvirt libxl
>> driver. The change is primarily inspired by this comment for
>> libxl_osevent_occurred_timeout:
>>
> ...
>
>> /* Implicitly, on entry to this function the timeout has been
>> * deregistered. If _occurred_timeout is called, libxl will not
>> * call timeout_deregister; if it wants to requeue the timeout it
>> * will call timeout_register again.
>> */
>>
>
> Well your patch is only correct when used with the new libxl, with my
> patches.
>
Hmm, it is not clear to me how to make the libxl driver work correctly
with libxl pre and post your patches :-/.
>
>> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
>> index 302f81c..d4055be 100644
>> --- a/src/libxl/libxl_driver.c
>> +++ b/src/libxl/libxl_driver.c
>> @@ -184,6 +184,8 @@ static void libxlTimerCallback(int timer
>> ATTRIBUTE_UNUSED, void *timer_v)
>> {
>> struct libxlOSEventHookTimerInfo *timer_info = timer_v;
>>
>> + virEventRemoveTimeout(timer_info->id);
>> + timer_info->id = -1;
>>
>
> I don't understand why you need this. Doesn't libvirt remove timers
> when they fire ? If it doesn't, do they otherwise not keep reoccurring ?
>
No, timers are not removed when they fire. And they are continuous, so
will keep firing at each timeout. They can be disabled by setting the
timeout to -1, and can be set to fire on each iteration of the event
loop by setting the timeout to 0. But they must be explicitly removed
with virEventRemoveTimeout when no longer needed.
Regards,
Jim
next prev parent reply other threads:[~2012-12-12 18:01 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-20 7:16 [PATCH] fix race condition between libvirtd event handling and libxl fd deregister Bamvor Jian Zhang
2012-11-23 9:43 ` Ian Campbell
2012-11-26 23:22 ` Jim Fehlig
2012-11-27 10:03 ` Ian Campbell
2012-11-27 19:08 ` Ian Jackson
2012-11-28 11:25 ` Ian Campbell
2012-12-06 16:11 ` 答复: " Bamvor Jian Zhang
2012-12-07 19:11 ` Ian Jackson
2012-12-07 19:15 ` [PATCH 1/2] libxl: fix stale fd event callback race Ian Jackson
2012-12-07 19:22 ` Ian Jackson
2012-12-07 19:15 ` [PATCH 2/2] libxl: fix stale timeout " Ian Jackson
2012-12-07 19:21 ` [PATCH 1/2] libxl: fix stale fd " Ian Jackson
2012-12-07 19:21 ` [PATCH 2/2] libxl: fix stale timeout " Ian Jackson
2012-12-10 10:19 ` [PATCH] fix race condition between libvirtd event handling and libxl fd deregister Ian Campbell
2012-12-10 10:37 ` Ian Jackson
2012-12-10 16:56 ` Ian Jackson
2012-12-10 16:57 ` [PATCH 1/2] libxl: fix stale fd event callback race Ian Jackson
2012-12-11 22:35 ` Jim Fehlig
2012-12-12 17:04 ` Ian Jackson
2012-12-12 17:20 ` Jim Fehlig
2012-12-10 16:57 ` [PATCH 2/2] libxl: fix stale timeout " Ian Jackson
2012-12-11 22:53 ` Jim Fehlig
2012-12-12 17:14 ` Ian Jackson
2012-12-12 17:16 ` Ian Jackson
2012-12-12 17:26 ` Jim Fehlig
2012-12-12 17:37 ` Ian Jackson
2012-12-12 18:01 ` Jim Fehlig [this message]
2012-12-13 10:29 ` Ian Campbell
2012-12-13 13:12 ` Ian Jackson
2012-12-13 15:53 ` Jim Fehlig
2012-12-13 15:58 ` Ian Jackson
2012-12-13 16:53 ` Jim Fehlig
2012-12-13 13:07 ` Ian Jackson
2012-12-13 15:41 ` Jim Fehlig
2012-12-13 15:51 ` Ian Jackson
2012-12-13 15:57 ` Jim Fehlig
2012-12-11 10:19 ` [PATCH] fix race condition between libvirtd event handling and libxl fd deregister Bamvor Jian Zhang
2012-12-11 11:20 ` Ian Jackson
2013-01-11 11:41 ` Ian Campbell
2013-01-11 17:51 ` Jim Fehlig
2013-01-15 10:40 ` Ian Campbell
2013-01-15 17:02 ` Jim Fehlig
2013-01-21 19:37 ` Jim Fehlig
2013-01-22 10:21 ` Ian Campbell
2012-12-10 23:56 ` Jim Fehlig
2012-12-11 11:18 ` Ian Jackson
2012-12-06 16:06 ` 答复: " Bamvor Jian Zhang
-- strict thread matches above, loose matches on Subject: below --
2013-01-23 16:08 [PATCH 0/2 v4] libxl: fix event races exposed by libvirt Ian Jackson
2013-01-23 16:08 ` [PATCH 2/2] libxl: fix stale timeout event callback race Ian Jackson
2013-01-23 17:48 ` Jim Fehlig
2013-01-23 18:21 [PATCH 0/2 v4.1] libxl: fix event races exposed by libvirt Ian Jackson
2013-01-23 18:21 ` [PATCH 2/2] libxl: fix stale timeout event callback race Ian Jackson
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=50C8C665.2030202@suse.com \
--to=jfehlig@suse.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=bjzhang@suse.com \
--cc=xen-devel@lists.xen.org \
/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).