All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corey Bryant <coreyb@linux.vnet.ibm.com>
To: Eric Blake <eblake@redhat.com>
Cc: kwolf@redhat.com, aliguori@us.ibm.com,
	stefanha@linux.vnet.ibm.com, libvir-list@redhat.com,
	qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 2/4] qapi: Add passfd QMP command
Date: Wed, 13 Jun 2012 18:07:43 -0400	[thread overview]
Message-ID: <4FD90F2F.5070401@linux.vnet.ibm.com> (raw)
In-Reply-To: <4FD8FC61.1080204@redhat.com>



On 06/13/2012 04:47 PM, Eric Blake wrote:
> On 06/13/2012 02:25 PM, Corey Bryant wrote:
>
>>> Also, getfd automatically closes a fd if an existing fdname is passed
>>> again.
>>> I don't think this is a good behavior, I think pass-fd should fail
>>> instead
>>> (note that we can't fix getfd though).
>>>
>>
>> I agree.  It makes sense to fail rather than blindly closing the
>> existing fd.  It can be closed explicitly with closefd if the user wants
>> it closed.
>
> Hmm - what happens if I do 'pass-fd name', learn that qemu is using fd
> 42, then do 'getfd name'?  I silently wipe out fd 42 and replace it with
> the new fd passed in by getfd.  Which means my use of /dev/fd/42 will
> now be broken.
>
> Obviously that means that 'getfd' should NOT be used by any application
> using 'pass-fd', and that libvirt should NOT be reusing names (I think
> the latter is already true).  But I agree that for back-compat we can't
> get rid of the current (evil) semantics of a duplicated 'getfd'.

Yes, users need to be careful and understand how the commands work.  I 
don't think it's a hard rule that 'getfd' can't be used by an 
application that uses 'pass-fd'.  If it were, we could put the fds on 
separate lists:

  struct Monitor {
      ...
      QLIST_HEAD(,mon_fd_t) fds;
+    QLIST_HEAD(,mon_fd_t) pass_fds;
  };

But I don't think this is necessary, so I'll plan on documenting them well.

>
> You may also want to mention that when using 'getfd' or 'pass-fd', there
> are some commands (like migrate) that use the fd:name protocol, and that
> a successful use of one of these commands implicitly closes the named
> fd; but that all new uses of /dev/fd/nnn leave the fd open and an
> explicit closefd must be used to avoid leaking indefinitely-opened fds
> in qemu.
>

Ok, I'll mention this too.  Thanks.

-- 
Regards,
Corey

  reply	other threads:[~2012-06-13 22:09 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-08 15:42 [Qemu-devel] [PATCH v2 0/4] file descriptor passing using passfd Corey Bryant
2012-06-08 15:42 ` [Qemu-devel] [PATCH v2 1/4] qapi: Convert getfd and closefd Corey Bryant
2012-06-13 19:41   ` Luiz Capitulino
2012-06-13 20:10     ` Corey Bryant
2012-06-13 19:42   ` Luiz Capitulino
2012-06-13 20:17     ` Corey Bryant
2012-06-13 20:41       ` Luiz Capitulino
2012-06-13 20:41       ` Eric Blake
2012-06-13 21:43         ` Corey Bryant
2012-06-08 15:42 ` [Qemu-devel] [PATCH v2 2/4] qapi: Add passfd QMP command Corey Bryant
2012-06-13 19:46   ` Luiz Capitulino
2012-06-13 20:25     ` Corey Bryant
2012-06-13 20:47       ` Eric Blake
2012-06-13 22:07         ` Corey Bryant [this message]
2012-06-14 13:28           ` Luiz Capitulino
2012-06-08 15:42 ` [Qemu-devel] [PATCH v2 3/4] osdep: Enable qemu_open to dup pre-opened fd Corey Bryant
2012-06-08 15:42 ` [Qemu-devel] [PATCH v2 4/4] block: Convert open calls to qemu_open Corey Bryant
2012-06-13 10:26   ` Kevin Wolf
2012-06-13 14:30     ` Corey Bryant
2012-06-08 17:10 ` [Qemu-devel] [PATCH v2 0/4] file descriptor passing using passfd Corey Bryant
2012-06-13 10:28 ` Kevin Wolf
2012-06-13 14:31   ` Corey Bryant
  -- strict thread matches above, loose matches on Subject: below --
2012-06-08 14:53 Corey Bryant
2012-06-08 14:53 ` [Qemu-devel] [PATCH v2 2/4] qapi: Add passfd QMP command Corey Bryant
2012-06-08 14:49 [Qemu-devel] [PATCH v2 0/4] file descriptor passing using passfd Corey Bryant
2012-06-08 14:49 ` [Qemu-devel] [PATCH v2 2/4] qapi: Add passfd QMP command Corey Bryant

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=4FD90F2F.5070401@linux.vnet.ibm.com \
    --to=coreyb@linux.vnet.ibm.com \
    --cc=aliguori@us.ibm.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@linux.vnet.ibm.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 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.