From: Corey Bryant <coreyb@linux.vnet.ibm.com>
To: Eric Blake <eblake@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
aliguori@us.ibm.com, stefanha@linux.vnet.ibm.com,
libvir-list@redhat.com, Jeff Cody <jcody@redhat.com>,
qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>,
pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH v3 0/5] file descriptor passing using pass-fd
Date: Wed, 20 Jun 2012 12:24:35 -0400 [thread overview]
Message-ID: <4FE1F943.40509@linux.vnet.ibm.com> (raw)
In-Reply-To: <4FE1E3FF.50702@redhat.com>
On 06/20/2012 10:53 AM, Eric Blake wrote:
> On 06/20/2012 07:31 AM, Corey Bryant wrote:
>
>>
>> It sounds like the flow would be:
>> 'pass-fd drive-virtio1' of O_RDONLY fd --> guest gets fd 21
>
> No -f, so qemu errors out if an fd named 'drive-virtio1' already exists;
> otherwise it succeeds, and returns the fd assigned by SCM_RIGHTS as well
> as adding the name to its internal list.
>
>> 'pass-fd -f drive-virtio1' of O_WRONLY fd --> guest gets fd 21?
>
> -f says to fail if 'drive-virtio1' does not already exist in the
> internal list. Otherwise, this is a reopen attempt, and the fd passed
> in by SCM_RIGHTS (let's assume it is 23 at this time) is then passed
> through dup2() to overwrite the fd already associated with
> 'drive-virtio1' (21 in this case), then the SCM_RIGHTS fd (23) is
> closed. In this way, the name 'drive-virtio1' remains associated with
> fd 21, but we have reopened it with different mode. At this point, code
> that wants to reopen /dev/fd/21 with a new mode will see the new
> permissions on the reassigned fd. And yes, it means that libvirt would
> not be allowed to call 'closefd drive-virtio1' until the block device
> for drive-virtio1 is no longer around, whether or not the /dev/fd/nn
> reuses the fd as-is or whether it dup()s the fd to something else (say
> 22) for use by the block device.
>
That makes sense. Thanks for the explanation.
Essentially dup2(23, 21) will give fd 21 the new access mode. I assume
we can go ahead and close fd 23 after the dup2?
I'll go ahead and add this support in the next version of the patch
series if there are no objections.
--
Regards,
Corey
>>
>> But I'm not clear as to how you would retain file descriptor 21 in the
>> guest when using 'pass-fd -f drive-virtio1'. The fd is created as a
>> result of passing via SCM_RIGHTS, which assigns the next available fd.
>> We don't have control over what fd is assigned, do we?
>
> The use of -f says that 'pass-fd' uses dup2() to reuse an existing fd.
>
prev parent reply other threads:[~2012-06-20 16:32 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-14 15:55 [Qemu-devel] [PATCH v3 0/5] file descriptor passing using pass-fd Corey Bryant
2012-06-14 15:55 ` [Qemu-devel] [PATCH v3 1/5] qapi: Convert getfd and closefd Corey Bryant
2012-06-14 15:55 ` [Qemu-devel] [PATCH v3 2/5] qapi: Add pass-fd QMP command Corey Bryant
2012-06-15 14:32 ` Luiz Capitulino
2012-06-15 15:04 ` Corey Bryant
2012-06-15 15:14 ` Luiz Capitulino
2012-06-15 15:29 ` Corey Bryant
2012-06-15 16:26 ` Luiz Capitulino
2012-06-14 15:55 ` [Qemu-devel] [PATCH v3 3/5] osdep: Enable qemu_open to dup pre-opened fd Corey Bryant
2012-06-15 15:16 ` Eric Blake
2012-06-15 18:16 ` Corey Bryant
2012-06-15 18:42 ` Eric Blake
2012-06-15 19:02 ` Corey Bryant
2012-06-15 18:46 ` Kevin Wolf
2012-06-15 19:19 ` Corey Bryant
2012-06-15 20:00 ` Eric Blake
2012-06-15 20:49 ` Corey Bryant
2012-06-18 8:10 ` Kevin Wolf
2012-06-19 13:59 ` Corey Bryant
2012-06-14 15:55 ` [Qemu-devel] [PATCH v3 4/5] block: Convert open calls to qemu_open Corey Bryant
2012-06-15 14:36 ` Luiz Capitulino
2012-06-15 15:10 ` Corey Bryant
2012-06-15 15:21 ` Eric Blake
2012-06-15 18:32 ` Corey Bryant
2012-06-14 15:55 ` [Qemu-devel] [PATCH v3 5/5] block: Prevent /dev/fd/X filename from being detected as floppy Corey Bryant
2012-06-15 14:38 ` Luiz Capitulino
2012-06-15 15:12 ` Corey Bryant
2012-06-19 15:46 ` [Qemu-devel] [PATCH v3 0/5] file descriptor passing using pass-fd Eric Blake
2012-06-19 15:57 ` Kevin Wolf
2012-06-19 16:14 ` Eric Blake
2012-06-20 7:25 ` Kevin Wolf
2012-06-20 8:31 ` Daniel P. Berrange
2012-06-20 11:24 ` Eric Blake
2012-06-20 13:31 ` Corey Bryant
2012-06-20 14:53 ` Eric Blake
2012-06-20 16:24 ` 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=4FE1F943.40509@linux.vnet.ibm.com \
--to=coreyb@linux.vnet.ibm.com \
--cc=aliguori@us.ibm.com \
--cc=eblake@redhat.com \
--cc=jcody@redhat.com \
--cc=kwolf@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=libvir-list@redhat.com \
--cc=pbonzini@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 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).