From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOqQK-00047c-Fr for qemu-devel@nongnu.org; Thu, 18 Oct 2012 09:46:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TOqQD-0004xy-H0 for qemu-devel@nongnu.org; Thu, 18 Oct 2012 09:46:08 -0400 Received: from e8.ny.us.ibm.com ([32.97.182.138]:44313) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOqQD-0004xi-D2 for qemu-devel@nongnu.org; Thu, 18 Oct 2012 09:46:01 -0400 Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 18 Oct 2012 09:45:59 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id C430538C8091 for ; Thu, 18 Oct 2012 09:45:55 -0400 (EDT) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q9IDjr7O205056 for ; Thu, 18 Oct 2012 09:45:54 -0400 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q9IDjqwo021073 for ; Thu, 18 Oct 2012 07:45:52 -0600 Message-ID: <5080080F.2040903@linux.vnet.ibm.com> Date: Thu, 18 Oct 2012 09:45:51 -0400 From: Corey Bryant MIME-Version: 1.0 References: <1350410912-2373-1-git-send-email-coreyb@linux.vnet.ibm.com> <507E2DD7.3090702@redhat.com> In-Reply-To: <507E2DD7.3090702@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 3/4] monitor: Prevent removing fd from set during init List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: kwolf@redhat.com, libvir-list@redhat.com, qemu-devel@nongnu.org On 10/17/2012 12:02 AM, Eric Blake wrote: > On 10/16/2012 12:08 PM, Corey Bryant wrote: >> If an fd is added to an fd set via the command line, and it is not >> referenced by another command line option (ie. -drive), then clean >> it up after QEMU initialization is complete. >> >> Signed-off-by: Corey Bryant >> --- >> v3: >> - This patch was split into it's own patch in v3 >> (eblake@redhat.com, kwolf@redhat.com) >> >> monitor.c | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) > > Reviewed-by: Eric Blake > Thanks! >> >> diff --git a/monitor.c b/monitor.c >> index 5d5de41..0dae7ac 100644 >> --- a/monitor.c >> +++ b/monitor.c >> @@ -2105,8 +2105,9 @@ static void monitor_fdset_cleanup(MonFdset *mon_fdset) >> MonFdsetFd *mon_fdset_fd_next; >> >> QLIST_FOREACH_SAFE(mon_fdset_fd, &mon_fdset->fds, next, mon_fdset_fd_next) { >> - if (mon_fdset_fd->removed || >> - (QLIST_EMPTY(&mon_fdset->dup_fds) && mon_refcount == 0)) { >> + if ((mon_fdset_fd->removed || >> + (QLIST_EMPTY(&mon_fdset->dup_fds) && mon_refcount == 0)) && >> + runstate_is_running()) { > > This condition looks sufficient for command line parsing; however, I > have to wonder if there are any long-term ill effects, such as if I > pause a guest, then close an fdset, where qemu keeps the fd open until I > continue the guest. But thinking a bit more, we never promised that > qemu would close fds right away, but only that it wouldn't leak fds by > closing them whenever qemu thinks it is convenient. > I can't think of any ill effects. I think you may be able to remove an fd or fd set followed by adding a drive using that fd set, but that is just a difference in behavior compared to when a guest is running. >> close(mon_fdset_fd->fd); >> g_free(mon_fdset_fd->opaque); >> QLIST_REMOVE(mon_fdset_fd, next); >> > -- Regards, Corey Bryant