block/gluster.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
On 64-bit platforms, SIZE_MAX is too large for max_pdiscard, which is
int64_t, and the following assertion would be triggered:
qemu-system-x86_64: ../block/io.c:3166: bdrv_co_pdiscard: Assertion
`max_pdiscard >= bs->bl.request_alignment' failed.
Fixes: 0c8022876f ("block: use int64_t instead of int in driver discard handlers")
Cc: qemu-stable@nongnu.org
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
---
block/gluster.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/gluster.c b/block/gluster.c
index 398976bc66..f711bf0bd6 100644
--- a/block/gluster.c
+++ b/block/gluster.c
@@ -891,7 +891,7 @@ out:
static void qemu_gluster_refresh_limits(BlockDriverState *bs, Error **errp)
{
bs->bl.max_transfer = GLUSTER_MAX_TRANSFER;
- bs->bl.max_pdiscard = SIZE_MAX;
+ bs->bl.max_pdiscard = MIN(SIZE_MAX, INT64_MAX);
}
static int qemu_gluster_reopen_prepare(BDRVReopenState *state,
@@ -1304,7 +1304,7 @@ static coroutine_fn int qemu_gluster_co_pdiscard(BlockDriverState *bs,
GlusterAIOCB acb;
BDRVGlusterState *s = bs->opaque;
- assert(bytes <= SIZE_MAX); /* rely on max_pdiscard */
+ assert(bytes <= MIN(SIZE_MAX, INT64_MAX)); /* rely on max_pdiscard */
acb.size = 0;
acb.ret = 0;
--
2.30.2
On Thu, May 12, 2022 at 12:30:48PM +0200, Fabian Ebner wrote: >On 64-bit platforms, SIZE_MAX is too large for max_pdiscard, which is The main problem is that SIZE_MAX for an int64_t is a negative value. >int64_t, and the following assertion would be triggered: >qemu-system-x86_64: ../block/io.c:3166: bdrv_co_pdiscard: Assertion >`max_pdiscard >= bs->bl.request_alignment' failed. > >Fixes: 0c8022876f ("block: use int64_t instead of int in driver discard handlers") >Cc: qemu-stable@nongnu.org >Signed-off-by: Fabian Ebner <f.ebner@proxmox.com> >--- > block/gluster.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > >diff --git a/block/gluster.c b/block/gluster.c >index 398976bc66..f711bf0bd6 100644 >--- a/block/gluster.c >+++ b/block/gluster.c >@@ -891,7 +891,7 @@ out: > static void qemu_gluster_refresh_limits(BlockDriverState *bs, Error **errp) > { > bs->bl.max_transfer = GLUSTER_MAX_TRANSFER; >- bs->bl.max_pdiscard = SIZE_MAX; >+ bs->bl.max_pdiscard = MIN(SIZE_MAX, INT64_MAX); What would be the problem if we use INT64_MAX? (I guess the intention of the original patch was to set the maximum value in drivers that do not have a specific maximum). Or we can set to 0, since in block/io.c we have this code: max_pdiscard = QEMU_ALIGN_DOWN(MIN_NON_ZERO(bs->bl.max_pdiscard, INT64_MAX), align); assert(max_pdiscard >= bs->bl.request_alignment); Where `max_pdiscard` is set to INT64_MAX (and aligned) if bs->bl.max_pdiscard is 0. > } > > static int qemu_gluster_reopen_prepare(BDRVReopenState *state, >@@ -1304,7 +1304,7 @@ static coroutine_fn int qemu_gluster_co_pdiscard(BlockDriverState *bs, > GlusterAIOCB acb; > BDRVGlusterState *s = bs->opaque; > >- assert(bytes <= SIZE_MAX); /* rely on max_pdiscard */ >+ assert(bytes <= MIN(SIZE_MAX, INT64_MAX)); /* rely on max_pdiscard */ Can we use bs->bl.max_pdiscard directly here? Thanks, Stefano
On Thu, May 12, 2022 at 05:44:13PM +0200, Stefano Garzarella wrote: >On Thu, May 12, 2022 at 12:30:48PM +0200, Fabian Ebner wrote: >>On 64-bit platforms, SIZE_MAX is too large for max_pdiscard, which is > >The main problem is that SIZE_MAX for an int64_t is a negative value. > >>int64_t, and the following assertion would be triggered: >>qemu-system-x86_64: ../block/io.c:3166: bdrv_co_pdiscard: Assertion >>`max_pdiscard >= bs->bl.request_alignment' failed. >> >>Fixes: 0c8022876f ("block: use int64_t instead of int in driver discard handlers") >>Cc: qemu-stable@nongnu.org >>Signed-off-by: Fabian Ebner <f.ebner@proxmox.com> >>--- >>block/gluster.c | 4 ++-- >>1 file changed, 2 insertions(+), 2 deletions(-) >> >>diff --git a/block/gluster.c b/block/gluster.c >>index 398976bc66..f711bf0bd6 100644 >>--- a/block/gluster.c >>+++ b/block/gluster.c >>@@ -891,7 +891,7 @@ out: >>static void qemu_gluster_refresh_limits(BlockDriverState *bs, Error **errp) >>{ >> bs->bl.max_transfer = GLUSTER_MAX_TRANSFER; >>- bs->bl.max_pdiscard = SIZE_MAX; >>+ bs->bl.max_pdiscard = MIN(SIZE_MAX, INT64_MAX); > >What would be the problem if we use INT64_MAX? Okay, I just saw Eric's answer to v1 and I think this is right. Please explain it in the commit message and also the initial problem that is SIZE_MAX on a 64-bit platform is a negative number for int64_t, so the assert fails. Thanks, Stefano >(I guess the intention of the original patch was to set the maximum >value in drivers that do not have a specific maximum). > >Or we can set to 0, since in block/io.c we have this code: > > max_pdiscard = QEMU_ALIGN_DOWN(MIN_NON_ZERO(bs->bl.max_pdiscard, INT64_MAX), > align); > assert(max_pdiscard >= bs->bl.request_alignment); > >Where `max_pdiscard` is set to INT64_MAX (and aligned) if >bs->bl.max_pdiscard is 0. > >>} >> >>static int qemu_gluster_reopen_prepare(BDRVReopenState *state, >>@@ -1304,7 +1304,7 @@ static coroutine_fn int qemu_gluster_co_pdiscard(BlockDriverState *bs, >> GlusterAIOCB acb; >> BDRVGlusterState *s = bs->opaque; >> >>- assert(bytes <= SIZE_MAX); /* rely on max_pdiscard */ >>+ assert(bytes <= MIN(SIZE_MAX, INT64_MAX)); /* rely on max_pdiscard */ > >Can we use bs->bl.max_pdiscard directly here? > >Thanks, >Stefano
Am 12.05.22 um 18:05 schrieb Stefano Garzarella: > On Thu, May 12, 2022 at 05:44:13PM +0200, Stefano Garzarella wrote: >> On Thu, May 12, 2022 at 12:30:48PM +0200, Fabian Ebner wrote: >>> On 64-bit platforms, SIZE_MAX is too large for max_pdiscard, which is >> >> The main problem is that SIZE_MAX for an int64_t is a negative value. >> Yes, I should've stated that directly. >>> int64_t, and the following assertion would be triggered: >>> qemu-system-x86_64: ../block/io.c:3166: bdrv_co_pdiscard: Assertion >>> `max_pdiscard >= bs->bl.request_alignment' failed. >>> >>> Fixes: 0c8022876f ("block: use int64_t instead of int in driver >>> discard handlers") >>> Cc: qemu-stable@nongnu.org >>> Signed-off-by: Fabian Ebner <f.ebner@proxmox.com> >>> --- >>> block/gluster.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/block/gluster.c b/block/gluster.c >>> index 398976bc66..f711bf0bd6 100644 >>> --- a/block/gluster.c >>> +++ b/block/gluster.c >>> @@ -891,7 +891,7 @@ out: >>> static void qemu_gluster_refresh_limits(BlockDriverState *bs, Error >>> **errp) >>> { >>> bs->bl.max_transfer = GLUSTER_MAX_TRANSFER; >>> - bs->bl.max_pdiscard = SIZE_MAX; >>> + bs->bl.max_pdiscard = MIN(SIZE_MAX, INT64_MAX); >> >> What would be the problem if we use INT64_MAX? > > Okay, I just saw Eric's answer to v1 and I think this is right. > Sorry for not mentioning the changes from v1. > Please explain it in the commit message and also the initial problem > that is SIZE_MAX on a 64-bit platform is a negative number for int64_t, > so the assert fails. > I'll try and improve the commit message for v3. > Thanks, > Stefano > >> (I guess the intention of the original patch was to set the maximum >> value in drivers that do not have a specific maximum). >> >> Or we can set to 0, since in block/io.c we have this code: >> >> max_pdiscard = QEMU_ALIGN_DOWN(MIN_NON_ZERO(bs->bl.max_pdiscard, >> INT64_MAX), >> align); >> assert(max_pdiscard >= bs->bl.request_alignment); >> >> Where `max_pdiscard` is set to INT64_MAX (and aligned) if >> bs->bl.max_pdiscard is 0. >> >>> } >>> >>> static int qemu_gluster_reopen_prepare(BDRVReopenState *state, >>> @@ -1304,7 +1304,7 @@ static coroutine_fn int >>> qemu_gluster_co_pdiscard(BlockDriverState *bs, >>> GlusterAIOCB acb; >>> BDRVGlusterState *s = bs->opaque; >>> >>> - assert(bytes <= SIZE_MAX); /* rely on max_pdiscard */ >>> + assert(bytes <= MIN(SIZE_MAX, INT64_MAX)); /* rely on >>> max_pdiscard */ >> >> Can we use bs->bl.max_pdiscard directly here? >> Now I'm thinking that the assert is actually for checking that the value can be passed to glfs_discard_async(), which takes a size_t for the argument in question. So maybe it's best to keep assert(bytes <= SIZE_MAX) as is? >> Thanks, >> Stefano > > >
© 2016 - 2024 Red Hat, Inc.