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, libvir-list@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [libvirt] [PATCH v2 3/3] qemu-config: Add new -add-fd command line option
Date: Thu, 11 Oct 2012 13:49:52 -0400	[thread overview]
Message-ID: <507706C0.3060000@linux.vnet.ibm.com> (raw)
In-Reply-To: <5076EDF4.1010301@redhat.com>



On 10/11/2012 12:04 PM, Eric Blake wrote:
> On 10/10/2012 04:31 PM, Eric Blake wrote:
>
>> Another missing validation check is for duplicate use.  With the monitor
>> command, you ALWAYS have a unique fd (thanks to SCM_RIGHTS).  But with
>> the command line, I can type 'qemu -add-fd fd=4,set=1 -add-fd
>> fd=4,set=2'.  Oops - I've now corrupted your set layout, unless you
>> validate that every fd requested in -add-fd does not already reside in
>> any existing set.
>>
>> Thinking aloud:
>> On the other hand, being able to pass in one fd to multiple sets MIGHT
>> be useful; in the SCM_RIGHTS monitor command case, I can pass the same
>> fd from the management perspective into multiple sets, even though in
>> qemu's perspective, there will be multiple fds created (one per call).
>> Perhaps instead of directly adding the inherited fd to a set, and having
>> to then sweep all sets to check for duplicates, it might make sense to
>> add dup(fd) to a set, so that if I call:
>>
>> qemu -add-fd fd=4,set=1 -add-fd fd=4,set=2 -add-fd fd=5,set=2
>>
>> what REALLY happens is that qemu adds dup(4)==6 to set 1, dup(4)==7 to
>> set 2, and dup(5)==8 to set 3.  Then, after all ALL -add-fd have been
>> processed, qemu then does another pass through them calling close(4) and
>> close(5) (to avoid holding the original fds open indefinitely if the
>> corresponding sets are discarded).
>
> Another idea: a hybrid approach - the _first_ -add-fd 4 directly adds 4
> to the set, all other -add-fd 4 end up adding dup(4) instead (well,
> fcntl(F_DUPFD_CLOEXEC), but you get the picture).  That is, do the
> duplicate scanning, and if there is no duplicate, use the fd directly;
> if there IS a duplicate, then put a unique fd number as a copy into the
> remaining sets.  That way, you don't have to do a final close() sweep
> across the -add-fd arguments passed on the command line, and you still
> don't have to worry about duplicated fds across multiple sets causing
> mayhem in qemu_close().
>

This would simplify the code, but I wonder if it would be confusing to 
users when they call query-fdsets and only see a single fd 4.  It may 
make more sense to dup all fds that are passed with -add-fd, and then it 
basically works the same as the QMP add-fd via SCM_RIGHTS.

On a somewhat related note, one major difference between the QMP add-fd 
and  command line -add-fd, is that -add-fd doesn't return the fd that 
was added.  So opaque strings will be even more important when passing 
fds on the command line.

-- 
Regards,
Corey Bryant

      parent reply	other threads:[~2012-10-11 17:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-10 14:20 [Qemu-devel] [PATCH v2 0/3] command line fd passing using fd sets Corey Bryant
2012-10-10 14:20 ` [Qemu-devel] [PATCH v2 1/3] monitor: Allow add-fd to any specified fd set Corey Bryant
2012-10-10 21:49   ` Eric Blake
2012-10-11 14:29     ` Corey Bryant
2012-10-10 14:20 ` [Qemu-devel] [PATCH v2 2/3] monitor: Enable adding an inherited fd to an " Corey Bryant
2012-10-10 22:01   ` Eric Blake
2012-10-11 14:30     ` Corey Bryant
2012-10-11 11:25   ` Kevin Wolf
2012-10-11 15:04     ` Corey Bryant
2012-10-12  8:30       ` Kevin Wolf
2012-10-10 14:20 ` [Qemu-devel] [PATCH v2 3/3] qemu-config: Add new -add-fd command line option Corey Bryant
2012-10-10 22:31   ` Eric Blake
2012-10-11 14:45     ` Corey Bryant
2012-10-11 15:55       ` Eric Blake
2012-10-11 17:36         ` Corey Bryant
2012-10-11 16:04     ` [Qemu-devel] [libvirt] " Eric Blake
2012-10-11 16:11       ` Eric Blake
2012-10-11 17:49       ` Corey Bryant [this message]

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=507706C0.3060000@linux.vnet.ibm.com \
    --to=coreyb@linux.vnet.ibm.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=qemu-devel@nongnu.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.