From: Corey Bryant <coreyb@linux.vnet.ibm.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: supriyak@linux.vnet.ibm.com, stefanha@gmail.com,
jcody@redhat.com, qemu-devel@nongnu.org, pbonzini@redhat.com,
eblake@redhat.com
Subject: Re: [Qemu-devel] [PATCH 3/7] block: raw-posix image file reopen
Date: Thu, 06 Sep 2012 11:34:00 -0400 [thread overview]
Message-ID: <5048C268.402@linux.vnet.ibm.com> (raw)
In-Reply-To: <50486B7C.2000406@redhat.com>
On 09/06/2012 05:23 AM, Kevin Wolf wrote:
> Am 05.09.2012 18:43, schrieb Jeff Cody:
>>>> + }
>>>> +
>>>> + int fcntl_flags = O_APPEND | O_ASYNC | O_NONBLOCK;
>>>> +#ifdef O_NOATIME
>>>> + fcntl_flags |= O_NOATIME;
>>>> +#endif
>>>> + if ((raw_s->open_flags & ~fcntl_flags) == (s->open_flags & ~fcntl_flags)) {
>>>> + /* dup the original fd */
>>>> + /* TODO: use qemu fcntl wrapper */
>>>> + raw_s->fd = fcntl(s->fd, F_DUPFD_CLOEXEC, 0);
>>>> + if (raw_s->fd == -1) {
>>>> + ret = -1;
>>>> + goto error;
>>>> + }
>>>> + ret = fcntl_setfl(raw_s->fd, raw_s->open_flags);
>>>> + } else {
>>>> + raw_s->fd = qemu_open(state->bs->filename, raw_s->open_flags, 0644);
>>>> + if (raw_s->fd == -1) {
>>>> + ret = -1;
>>>> + }
>>>
>>> Ignoring this part for now, with qemu_dup_flags() it's going to look a
>>> bit different. In particular, I'm hoping that we don't get a second
>>> fcntl_flags enumeration here, but can just fall back to qemu_open()
>>> whenever qemu_dup_flags() fails.
>>
>> That will require modification to qemu_dup_flags()... I believe
>> qemu_dup_flags() silently filters out fcntl incompatible flags.
>>
>> Maybe it would be best to create a small helper function in osdep.c, that
>> fetches the fcntl_flags. Then qemu_dup_flags() and this function would
>> use the same helper to fetch fcntl_flags. The results of that would
>> determine if we call qemu_dup_flags() or qemu_open().
>>
>> Although, I do think it makes sense to always try qemu_open() if
>> qemu_dup_flags() fails for some reason.
I'm curious why you can't always call qemu_open().
Some things to consider so that fd passing doesn't break when a reopen
occurs. Mainly all the concerns revolve around how fd passing keeps
track of references to fd sets (note: adding and removing fd set
references is all done in qemu_open and qemu_close).
* When reopening, qemu_open needs to be called before qemu_close. This
will prevent the reference list for an fdset from becoming empty. If
qemu_close is called before qemu_open, the reference list can become
empty, and the fdset could be cleaned up before the qemu_open. Then
qemu_open would fail.
* qemu_open/qemu_close need to be used rather than open/close so that
the references for fd passing are properly accounted for.
* I don't think you want to call qemu_dup_flags directly since it
doesn't update the reference list for fd passing. Only qemu_open and
qemu_close update the reference list.
>
> If we can modify qemu_dup_flags() to fail if it can't provide the right
> set of flags, then I think we should do it - and I think we can. Even
> for the existing cases with fd passing it shouldn't break anything, but
> only add an additional safety check.
>
> And if touching the function motivates Corey to write some fd passing
> test cases so that you can't break it, even better. ;-)
:) Sorry, I do plan to do this soon. I've just been side-tracked with
some other things.
--
Regards,
Corey
next prev parent reply other threads:[~2012-09-06 15:35 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-30 18:47 [Qemu-devel] [PATCH 0/7] block: bdrv_reopen() patches Jeff Cody
2012-08-30 18:47 ` [Qemu-devel] [PATCH 1/7] block: correctly set the keep_read_only flag Jeff Cody
2012-09-05 12:47 ` Kevin Wolf
2012-09-05 13:08 ` Jeff Cody
2012-09-05 13:12 ` Kevin Wolf
2012-08-30 18:47 ` [Qemu-devel] [PATCH 2/7] block: Framework for reopening files safely Jeff Cody
2012-09-05 15:09 ` Kevin Wolf
2012-09-05 16:38 ` Jeff Cody
2012-09-11 14:57 ` Jeff Cody
2012-09-11 15:14 ` Kevin Wolf
2012-09-11 15:36 ` Jeff Cody
2012-09-11 15:41 ` Kevin Wolf
2012-08-30 18:47 ` [Qemu-devel] [PATCH 3/7] block: raw-posix image file reopen Jeff Cody
2012-08-30 22:15 ` Eric Blake
2012-08-31 14:42 ` Jeff Cody
2012-08-31 14:49 ` Kevin Wolf
2012-08-31 15:10 ` Jeff Cody
2012-09-05 15:30 ` Kevin Wolf
2012-09-05 16:43 ` Jeff Cody
2012-09-06 9:23 ` Kevin Wolf
2012-09-06 15:34 ` Corey Bryant [this message]
2012-09-07 10:40 ` Kevin Wolf
2012-09-07 14:29 ` Corey Bryant
2012-08-30 18:47 ` [Qemu-devel] [PATCH 4/7] block: raw " Jeff Cody
2012-08-30 18:47 ` [Qemu-devel] [PATCH 5/7] block: qed " Jeff Cody
2012-08-30 18:47 ` [Qemu-devel] [PATCH 6/7] block: qcow2 " Jeff Cody
2012-08-30 18:47 ` [Qemu-devel] [PATCH 7/7] block: qcow " Jeff Cody
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=5048C268.402@linux.vnet.ibm.com \
--to=coreyb@linux.vnet.ibm.com \
--cc=eblake@redhat.com \
--cc=jcody@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=supriyak@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).