[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 1/2] qga: flush explicitly when needed
From: |
Michael Roth |
Subject: |
Re: [Qemu-devel] [PATCH v2 1/2] qga: flush explicitly when needed |
Date: |
Tue, 24 Nov 2015 16:19:29 -0600 |
User-agent: |
alot/0.3.6 |
Quoting Eric Blake (2015-11-24 14:56:15)
> On 11/24/2015 11:04 AM, address@hidden wrote:
> > From: Marc-André Lureau <address@hidden>
> >
> > According to the specification:
> > http://pubs.opengroup.org/onlinepubs/9699919799/functions/fopen.html
> >
> > "the application shall ensure that output is not directly followed by
> > input without an intervening call to fflush() or to a file positioning
> > function (fseek(), fsetpos(), or rewind()), and input is not directly
> > followed by output without an intervening call to a file positioning
> > function, unless the input operation encounters end-of-file."
> >
> > Without this change, a write() followed by a read() may lose the
> > previously written content, as shown in the following test.
> >
> > Fixes:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1210246
> >
> > Signed-off-by: Marc-André Lureau <address@hidden>
> > ---
> > qga/commands-posix.c | 22 ++++++++++++++++++++++
> > 1 file changed, 22 insertions(+)
> >
> > diff --git a/qga/commands-posix.c b/qga/commands-posix.c
> > index 0ebd473..d0228ce 100644
> > --- a/qga/commands-posix.c
> > +++ b/qga/commands-posix.c
> > @@ -219,6 +219,7 @@ void qmp_guest_set_time(bool has_time, int64_t time_ns,
> > Error **errp)
> > typedef struct GuestFileHandle {
> > uint64_t id;
> > FILE *fh;
> > + bool writing;
> > QTAILQ_ENTRY(GuestFileHandle) next;
> > } GuestFileHandle;
> >
> > @@ -460,6 +461,17 @@ struct GuestFileRead *qmp_guest_file_read(int64_t
> > handle, bool has_count,
> > }
> >
> > fh = gfh->fh;
> > +
> > + /* explicitly flush when switching from writing to reading */
> > + if (gfh->writing) {
> > + int ret = fflush(fh);
> > + if (ret == EOF) {
> > + error_setg_errno(errp, errno, "failed to flush file");
> > + return NULL;
> > + }
> > + gfh->writing = false;
> > + }
> > +
> > buf = g_malloc0(count+1);
> > read_count = fread(buf, 1, count, fh);
> > if (ferror(fh)) {
> > @@ -496,6 +508,16 @@ GuestFileWrite *qmp_guest_file_write(int64_t handle,
> > const char *buf_b64,
> > }
> >
> > fh = gfh->fh;
> > +
> > + if (!gfh->writing) {
> > + int ret = fseek(fh, 0, SEEK_CUR);
> > + if (ret == -1) {
> > + error_setg_errno(errp, errno, "failed to seek file");
> > + return NULL;
> > + }
> > + gfh->writing = true;
> > + }
>
> Hmm. This always attempts fseek() on the first write() to a file, even
> if the file is not also open for read. While guest-file-open is most
> likely used on regular files (and therefore seekable), I'm worried that
> we might have a client that is attempting to use it on terminal files or
> other non-seekable file names. Since the fseek() on first write is
> unconditional, that means we would now fail to let a user write to such
> a file, even if they could previously do so. Should we add more logic
> to only do the fseek() after a previous write (as in a tri-state
> variable of untouched, last written, last read), so that we aren't
> breaking one-pass usage of non-seekable files?
I think that would be prudent. !gfh->writing doesn't imply gfh->reading,
and failed calls to qmp_guest_file_read() should probably not set
gfh->writing to true either.
Maybe something like:
gfh->rw_state = RW_STATE_NEW | RW_STATE_READING | RW_STATE_WRITING, skip the
fseek()/fflush() on RW_NEW, and only move to RW_STATE_READING/WRITING when
fread()/fwrite(), respectively, actually succeed?
I guess that still leaves the possibility of writes failing after reads
on non-seekable files. Are such files always directional? Otherwise that
means there are cases where it's impossible to implement the
requirements of the spec.
>
> --
> Eric Blake eblake redhat com +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>