xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Jim Fehlig <jfehlig@suse.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [PATCH 2/2] libxl: fix stale timeout event callback race
Date: Thu, 13 Dec 2012 08:41:05 -0700	[thread overview]
Message-ID: <50C9F711.400@suse.com> (raw)
In-Reply-To: <20681.54029.391833.313611@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:
>>     
>>> 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 :-/.
>>     
>
> This should be straightforward I think, except for the deregistration
> race bug which is unavoidable with the old libxl.  Simply correctly
> implementing both the deregistration callback and the modification
> callback ought to do it.
>   

Yes, after thinking about it some more, I agree.

As for the modify callback, do you agree that it is fine to ignore the
timeval parameter and just update the timer in libvirt's event loop to
fire immediately?  I.e. always treat the timeval parameter as containing
{0,0} regardless of "old" or "new" libxl?  I think my patch here is correct

http://lists.xen.org/archives/html/xen-devel/2012-12/msg00985.html

>   
>>>> @@ -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.
>>     
>
> Right.  Well then yes you need to call virEventRemoveTimeout here.
> But that applies to both old and new libxl.
>   

Right.

Thanks for the help with getting this issue resolved!

Jim

  reply	other threads:[~2012-12-13 15:41 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
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 [this message]
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=50C9F711.400@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).