All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jim Fehlig <jfehlig@suse.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Bamvor Jian Zhang <bjzhang@suse.com>
Subject: Re: [PATCH] fix race condition between libvirtd event handling and libxl fd deregister
Date: Mon, 26 Nov 2012 16:22:50 -0700	[thread overview]
Message-ID: <50B3F9CA.4030208@suse.com> (raw)
In-Reply-To: <1353663822.13542.183.camel@zakaz.uk.xensource.com>

Ian Campbell wrote:
> On Tue, 2012-11-20 at 07:16 +0000, Bamvor Jian Zhang wrote:
>   
>> the race condition may be encounted at the following senaro:
>> (1), xenlight will remove fd handle just after the transfer is done according to
>> the buffer pointer. This action will first mark fd handle deleted in libvirtd
>> then remove fd handler from list in libxl. To mark the fd deleted in libvirtd,
>> the libvirt event loop mutex must be acquired.
>>
>> (2), meanwhile in the libvirt event dispatch process, libvirt will check the fd
>> deleted flag while holding the event loop mutex. At this time, "(1)" may be
>> blocked from marking the deleted flag. Then libvirt release its mutex temperary
>> to run the dispatcher callback. But this callback need xenlight lock(CTX_LOCK)
>> which is held by xenlight fd deregister function. So, libvirtd will continue to
>> run this callback after fd deregister exit which means xenlight has been marked
>> deleted flag, removed this fd handler and set ev->fd as -1. after
>> libxl__ev_fd_deregister exit, it is time for callback running. but
>> unfortunately, this callback has been removed as I mentioned above.
>>
>> reference the following graph:
>> libvirt event dispatch                  xenlight transfer done
>>        |                              enter libxl__ev_fd_deregister
>>        |                                     CTX_LOCK
>>        |                                         |
>>        |                                         |
>>        |                              enter osevent_fd_deregister
>>        |                                         |
>>        |                              enter virEventRemoveHandle
>>        |                                waiting virMutexLock
>> check handler delete flag                        |
>> virMutexUnlock                                   |
>>        |                                    virMutexLock
>> enter libxl_osevent_occurred_fd                  |
>> waiting CTX_LOCK                          mark delete flag
>>        |                                   virMutexUnlock
>>        |                                         |
>>        |                                exit virEventRemoveHandle
>>        |                                exit osevent_fd_deregister
>>        |                                         |
>>        |                                remove fd handler from list
>>        |                                   set ev->fd as -1
>>        |                                     CTX_UNLOCK
>>    CTX_LOCK
>> assert(fd==ev->fd) //lead to crash
>> call back in libxl
>>    CTX_UNLOCK
>> exit libxl_osevent_occurred_fd
>>     
>
> This all seems pretty plausible to me, but I'd like to have an Ack from
> Ian J before I commit.
>   

FYI, I hit the race again today on a test machine without this patch,
and no longer encountered the race after applying the patch.  So

    Tested-by: Jim Fehlig <jfehlig@suse.com>

If ACK'ed by Ian J., can this also be added to 4.2-testing?

Thanks!
Jim

>   
>> at the same time, i found the times of file handler register is less
>> than the times of file handler deregister. is that right? seems that
>> it will be better if the register and deregister is paired.
>>     
>
> How many extra file handles are we talking about?
>
> Presumably some long lived file handles will stay around until you call
> libxl_ctx_free for the ctx. Or are you doing this and saying you are
> seeing leaked fd's?
>
>   
>> Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com>
>>     
>
>   
>> diff -r 321f8487379b -r 0451e6041bdd tools/libxl/libxl_event.c
>> --- a/tools/libxl/libxl_event.c	Thu Nov 15 10:25:29 2012 +0000
>> +++ b/tools/libxl/libxl_event.c	Tue Nov 20 14:56:04 2012 +0800
>> @@ -1018,11 +1018,15 @@ void libxl_osevent_occurred_fd(libxl_ctx
>>      CTX_LOCK;
>>      assert(!CTX->osevent_in_hook);
>>  
>> +    if (!libxl__ev_fd_isregistered(ev)) {
>> +        DBG("ev_fd=%p deregister unregistered",ev);
>> +        goto out;
>> +    }
>>      assert(fd == ev->fd);
>>      revents &= ev->events;
>>      if (revents)
>>          ev->func(egc, ev, fd, ev->events, revents);
>> -
>> +out:
>>      CTX_UNLOCK;
>>      EGC_FREE;
>>  }
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>     
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>   

  reply	other threads:[~2012-11-26 23:22 UTC|newest]

Thread overview: 47+ 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 [this message]
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
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

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=50B3F9CA.4030208@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.