From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43251) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFU1p-0001sR-8T for qemu-devel@nongnu.org; Tue, 21 Jun 2016 18:20:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFU1n-0003W6-UI for qemu-devel@nongnu.org; Tue, 21 Jun 2016 18:20:17 -0400 References: <1465939839-30097-1-git-send-email-eblake@redhat.com> <1465939839-30097-15-git-send-email-eblake@redhat.com> <20160621135015.GG4520@noname.redhat.com> From: Eric Blake Message-ID: <5769BD97.3040200@redhat.com> Date: Tue, 21 Jun 2016 16:20:07 -0600 MIME-Version: 1.0 In-Reply-To: <20160621135015.GG4520@noname.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fTvTSaUHji5jmUJ6i6iaJ5jcoslulXf5M" Subject: Re: [Qemu-devel] [PATCH v2 14/17] block: Switch transfer length bounds to byte-based List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, Max Reitz , Stefan Hajnoczi , Fam Zheng , Ronnie Sahlberg , Paolo Bonzini , Peter Lieven , "Michael S. Tsirkin" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fTvTSaUHji5jmUJ6i6iaJ5jcoslulXf5M From: Eric Blake To: Kevin Wolf Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, Max Reitz , Stefan Hajnoczi , Fam Zheng , Ronnie Sahlberg , Paolo Bonzini , Peter Lieven , "Michael S. Tsirkin" Message-ID: <5769BD97.3040200@redhat.com> Subject: Re: [PATCH v2 14/17] block: Switch transfer length bounds to byte-based References: <1465939839-30097-1-git-send-email-eblake@redhat.com> <1465939839-30097-15-git-send-email-eblake@redhat.com> <20160621135015.GG4520@noname.redhat.com> In-Reply-To: <20160621135015.GG4520@noname.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/21/2016 07:50 AM, Kevin Wolf wrote: > Am 14.06.2016 um 23:30 hat Eric Blake geschrieben: >> Sector-based limits are awkward to think about; in our on-going >> quest to move to byte-based interfaces, convert max_transfer_length >> and opt_transfer_length. Rename them (dropping the _length suffix) >> so that the compiler will help us catch the change in semantics >> across any rebased code, and improve the documentation. Use unsigned >> values, so that we don't have to worry about negative values and >> so that bit-twiddling is easier; however, we are still constrained >> by 2^31 of signed int in most APIs. >> >> Signed-off-by: Eric Blake >=20 >> @@ -1738,8 +1742,8 @@ static void iscsi_refresh_limits(BlockDriverStat= e *bs, Error **errp) >> } else { >> bs->bl.pwrite_zeroes_alignment =3D iscsilun->block_size; >> } >> - bs->bl.opt_transfer_length =3D >> - sector_limits_lun2qemu(iscsilun->bl.opt_xfer_len, iscsilun); >> + assert(iscsilun->bl.opt_xfer_len < INT_MAX / iscsilun->block_size= ); >> + bs->bl.opt_transfer =3D iscsilun->bl.opt_xfer_len * iscsilun->blo= ck_size; >> } >=20 > iscsilun->bl.opt_xfer_len comes directly from libiscsi, and presumably > from the iscsi server, without being checked or sanitised. I don't thin= k > we can assert a specific range of values for it but must assume that it= > can be any uint32_t. >=20 > We can return an error for a device with a value that we don't like > (even though using the maximum might be just fine), but crashing qemu i= s > not an option. I guess there's two possible problems: if the value is not a power of 2, it affects how we want to use it (we probably ought to raise an error there); and if it is oversized, we can just silently ignore the limit (since we can't hit it). I'll see what I can come up with for v3. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --fTvTSaUHji5jmUJ6i6iaJ5jcoslulXf5M 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/ iQEcBAEBCAAGBQJXab2XAAoJEKeha0olJ0Nqd8oH/j6r/NHS9vZGXBJ8r0zRemRy dq5M6QVq62SmbOddrTJ3OtaB68tHOLpNgenx8tf3kfRhcI8pcrjXcPAeCm4JcTqt 6afY93wNtg+hXQZbpFCJZz1zqPv4aknIgOst+IBfl6UFOOtnxLMR/o4Elft5rudi 2Uy9GNoXw1qavZaUkbpTg+uX9rnsnqpZ4EMPg8vrCCFIHktFF5ubTcQ640Jtg3uT kKbwgOjCgb0BOZhJpjL9X83rvpzfGCg9kpK13bQUlnudmtjbeTTcyDLIZip5MBl+ NgY746jOKhE+m3cByfmoyQ7UBXFEveRCPM88k7b9PKdsiNsu2gdLe4cF4nhj4lo= =Q1vv -----END PGP SIGNATURE----- --fTvTSaUHji5jmUJ6i6iaJ5jcoslulXf5M--