On Wed, Mar 09, Olaf Hering wrote:
> On Wed, Mar 09, Kevin Wolf wrote:
>
> > Removing integer overflow checks without removing the potentially
> > overflowing operation doesn't feel like a particularly good idea,
> > though.
>
> Why does the code use signed ints anyway for sectors and offset?!
On Wed, Mar 09, Olaf Hering wrote:
> Why does the code use signed ints anyway for sectors and offset?!
I have to check mainline (next week), at least this fixes mkfs for me:
+++ xen-4.4.3-testing/tools/qemu-xen-dir-remote/block/raw-posix.c
@@ -792,8 +792,8 @@ static BlockDriverAIOCB *paio_submit
On Wed, Mar 09, Kevin Wolf wrote:
> Removing integer overflow checks without removing the potentially
> overflowing operation doesn't feel like a particularly good idea,
> though.
Why does the code use signed ints anyway for sectors and offset?!
Olaf
Am 09.03.2016 um 15:45 hat Olaf Hering geschrieben:
> On Wed, Mar 09, Paolo Bonzini wrote:
>
> > It probably should range check max_unmap_size and max_io_size against
> > BDRV_REQUEST_MAX_SECTORS, and reject anything bigger than that, though.
>
> Are you sure? Shouldnt the only check be if sect+n
On 09/03/2016 13:11, Olaf Hering wrote:
> What is the purpose of the bdrv_check_request() call in bdrv_co_discard?
>
> It seems a frontend cant possibly know what the limit is in the
> qemu-of-the-day, I found no interface to propagate
> BDRV_REQUEST_MAX_SECTORS into the guest.
It depends on th
What is the purpose of the bdrv_check_request() call in bdrv_co_discard?
It seems a frontend cant possibly know what the limit is in the
qemu-of-the-day, I found no interface to propagate
BDRV_REQUEST_MAX_SECTORS into the guest.
I think to handle nb_sectors > BDRV_REQUEST_MAX_SECTORS bdrv_co_disc
