From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33544) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c9Djm-0003Bk-EN for qemu-devel@nongnu.org; Tue, 22 Nov 2016 11:16:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c9Djh-0005Bx-FM for qemu-devel@nongnu.org; Tue, 22 Nov 2016 11:16:02 -0500 Date: Tue, 22 Nov 2016 17:12:35 +0100 From: Olaf Hering Message-ID: <20161122161235.GA24220@aepfle.de> References: <20161118102452.5779-1-olaf@aepfle.de> <42ca6186-ca47-3c63-d2e0-54f2ed9f4be7@redhat.com> <20161118174108.GF5717@aepfle.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH] xen_disk: convert discard input to byte ranges List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: qemu-block@nongnu.org, Kevin Wolf , Stefano Stabellini , "open list:All patches CC here" , Max Reitz , "open list:X86" , Anthony Perard --jI8keyz6grp/JLjh Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On Fri, Nov 18, Eric Blake wrote: > if (sec_start > (INT64_MAX >> BDRV_SECTOR_BITS) - sec_count) I have looked at this for a while now and cant spot how this would cover all cases. Are you saying there should be just a single overflow check, yours? My change has two: one to check for wrap around and to check against the upper limit. My check happens to work with 0/UINT64_MAX or INT64_MAX/INT64_MAX as input, yours appearently not. Obviously I'm missing something essential. Olaf --jI8keyz6grp/JLjh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlg0bm8ACgkQXUKg+qaYNn6CZwCgwGkp4V5QZWi8yosBJlh3gcRK xgoAoMkbnR2j3xOX10XUynS0UD61l64u =FrXn -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: [Qemu-devel] [PATCH] xen_disk: convert discard input to byte ranges Date: Tue, 22 Nov 2016 17:12:35 +0100 Message-ID: <20161122161235.GA24220@aepfle.de> References: <20161118102452.5779-1-olaf@aepfle.de> <42ca6186-ca47-3c63-d2e0-54f2ed9f4be7@redhat.com> <20161118174108.GF5717@aepfle.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3852944135005486079==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Eric Blake Cc: Kevin Wolf , "open list:X86" , qemu-block@nongnu.org, "open list:All patches CC here" , Max Reitz , Stefano Stabellini , Anthony Perard List-Id: xen-devel@lists.xenproject.org --===============3852944135005486079== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline --jI8keyz6grp/JLjh Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On Fri, Nov 18, Eric Blake wrote: > if (sec_start > (INT64_MAX >> BDRV_SECTOR_BITS) - sec_count) I have looked at this for a while now and cant spot how this would cover all cases. Are you saying there should be just a single overflow check, yours? My change has two: one to check for wrap around and to check against the upper limit. My check happens to work with 0/UINT64_MAX or INT64_MAX/INT64_MAX as input, yours appearently not. Obviously I'm missing something essential. Olaf --jI8keyz6grp/JLjh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlg0bm8ACgkQXUKg+qaYNn6CZwCgwGkp4V5QZWi8yosBJlh3gcRK xgoAoMkbnR2j3xOX10XUynS0UD61l64u =FrXn -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- --===============3852944135005486079== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============3852944135005486079==--