From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45261) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bO478-0004h1-5q for qemu-devel@nongnu.org; Fri, 15 Jul 2016 10:29:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bO473-0006ba-6c for qemu-devel@nongnu.org; Fri, 15 Jul 2016 10:29:14 -0400 References: <1468017364-25980-1-git-send-email-eblake@redhat.com> <1468017364-25980-2-git-send-email-eblake@redhat.com> <578861C4.2080700@redhat.com> From: Eric Blake Message-ID: <5788F325.6040701@redhat.com> Date: Fri, 15 Jul 2016 08:28:53 -0600 MIME-Version: 1.0 In-Reply-To: <578861C4.2080700@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FXKAXdaQMMWeQs35w33qjC50QLIup5Tk2" Subject: Re: [Qemu-devel] [PATCH v2 1/6] block: Fragment reads to max transfer length List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: kwolf@redhat.com, famz@redhat.com, qemu-block@nongnu.org, Stefan Hajnoczi , Max Reitz This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FXKAXdaQMMWeQs35w33qjC50QLIup5Tk2 From: Eric Blake To: qemu-devel@nongnu.org Cc: kwolf@redhat.com, famz@redhat.com, qemu-block@nongnu.org, Stefan Hajnoczi , Max Reitz Message-ID: <5788F325.6040701@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 1/6] block: Fragment reads to max transfer length References: <1468017364-25980-1-git-send-email-eblake@redhat.com> <1468017364-25980-2-git-send-email-eblake@redhat.com> <578861C4.2080700@redhat.com> In-Reply-To: <578861C4.2080700@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/14/2016 10:08 PM, Eric Blake wrote: > On 07/08/2016 04:35 PM, Eric Blake wrote: >> Drivers should be able to rely on the block layer honoring the >> max transfer length, rather than needing to return -EINVAL >> (iscsi) or manually fragment things (nbd). This patch adds >> the fragmentation in the block layer, after requests have been >> aligned (fragmenting before alignment would lead to multiple >> unaligned requests, rather than just the head and tail). >> >> The return value was previously nebulous on success (sometimes >> zero, sometimes the length read); since we never have a short >> read, and since fragmenting may store yet another positive >> value in 'ret', change the function to always return the >> incoming 'bytes' value on success. >> >> Signed-off-by: Eric Blake >> >> --- >> v2: Fix uninitialized use of 'ret' for an all-zero read beyond eof >=20 > Uggh. Something I did here and not in v1 is now causing 'make > check-qtest' failures. Please don't merge until I've posted v3. Looks like there is at least one caller that expects bdrv_aligned_preadv() to return 0 (not positive) on success; I'm not sure which one(s), as it turned into a lot of code to chase, but a simple tweak to guarantee ret =3D 0 on success solves the failures in 'make check'. v3 coming up soon. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --FXKAXdaQMMWeQs35w33qjC50QLIup5Tk2 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/ iQEcBAEBCAAGBQJXiPMlAAoJEKeha0olJ0NqSfMIAKIwGQZiOmrXSzYJvwLPnnNJ npr+bJjO99wJfHgPdoaJCC/YY8CVOC3pSNs3G3QAAQzXWAC8lMBTD8rO7D71xjvF hUn/77CEGQ0BNfFsOt/rWi0waRg3Q5m7szdQcsY8NWYX6xFzkYd7fSxW0WVr324B T6INf9i5cuemJTjtkLdwKNR3FRZ7FD21i6kBxDDq/7f+lRvV40x+NkcdNXmjvyB9 A/L6SiTggMMoelhUU37Zw31KFvINLbVBYt2D7d0L6IxWkDZ3k8DVAUf8lahFwZKe mRP8WQFr37+VVcZ+xOQ9F1Nbi4EAFssVGdw8kMskoZTX182U2Lf8JgH1ol0t7UU= =eZtA -----END PGP SIGNATURE----- --FXKAXdaQMMWeQs35w33qjC50QLIup5Tk2--