From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38888) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1M4p-0001gP-2u for qemu-devel@nongnu.org; Tue, 24 Nov 2015 17:28:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1M4l-0002Ia-MF for qemu-devel@nongnu.org; Tue, 24 Nov 2015 17:28:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34295) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1M4l-0002IW-ET for qemu-devel@nongnu.org; Tue, 24 Nov 2015 17:28:39 -0500 References: <1448388281-18691-1-git-send-email-marcandre.lureau@redhat.com> <1448388281-18691-2-git-send-email-marcandre.lureau@redhat.com> <5654CEEF.1040102@redhat.com> <20151124221929.6284.44169@loki> From: Eric Blake Message-ID: <5654E491.8000203@redhat.com> Date: Tue, 24 Nov 2015 15:28:33 -0700 MIME-Version: 1.0 In-Reply-To: <20151124221929.6284.44169@loki> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="U9NTgs1eBNnROMHV6AL3LsJG0cUVtM5Sb" Subject: Re: [Qemu-devel] [PATCH v2 1/2] qga: flush explicitly when needed List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth , marcandre.lureau@redhat.com, qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --U9NTgs1eBNnROMHV6AL3LsJG0cUVtM5Sb Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/24/2015 03:19 PM, Michael Roth wrote: >> Hmm. This always attempts fseek() on the first write() to a file, eve= n >> 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 tha= t >> 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 suc= h >> 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? >=20 > 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. >=20 > Maybe something like: >=20 > gfh->rw_state =3D RW_STATE_NEW | RW_STATE_READING | RW_STATE_WRITING, s= kip the > fseek()/fflush() on RW_NEW, and only move to RW_STATE_READING/WRITING w= hen > fread()/fwrite(), respectively, actually succeed? Additionally, if guest-file-seek succeeds, reset state to RW_STATE_NEW (any user-triggered seek satisfies the requirement so that we don't need our implicit seek). >=20 > I guess that still leaves the possibility of writes failing after reads= > on non-seekable files. Are such files always directional? Otherwise tha= t > means there are cases where it's impossible to implement the > requirements of the spec. Remember, /dev/tty is commonly opened for both reading and writing - but via separate fds (you read from fd 0, write to fd 1) - and it is the console or terminal emulator that sets up the initial things (you seldom see scripts directly attempting a bi-directional 'exec <> /dev/tty'. I think we'll be okay on that front. Or if we're paranoid, then have guest-file-seek inspect errno - if seek failed due to ESPIPE, then the file is non-seekable, stdio shouldn't be buffering anyways, and we can just blindly force RW_STATE_NEW in that case (the real reason for fflush/fseek between read/write transitions is for seekable files). --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --U9NTgs1eBNnROMHV6AL3LsJG0cUVtM5Sb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWVOSRAAoJEKeha0olJ0Nq07sIAJaJThxE3IGWddCCJ6TCKGkR GlKPumTdBftpqAWpauF6u/z634pW3rgho0bviUnrkLb7fmoev9jeP0i5HMhaD7rk p7XJqOPcmnglulG1/pMt5Flb+FSLRGDEgDRA+mqgt8mO1ZKjorT5A/Z+g6q/lfoc aCMtcW1dU2NPtIrHphNZ3MBucfaw4Pp2pIoQ0cu5CGv/ITq3zuBzDe90EJU6n9sQ cpCYkxJ+w7ytVODCCwFmmkD/6fYicwVe5XhFYkqXP/qQ3015x/J8HWh42rbxAYr+ AbDNG7Ykt9r1rkEv2RAAjpwxwBzj9wRvkAGaH4isZ0UUpo7zdd/MkWAO9ZX0/eQ= =IOir -----END PGP SIGNATURE----- --U9NTgs1eBNnROMHV6AL3LsJG0cUVtM5Sb--