> -----Original Message-----
> From: fio-owner@xxxxxxxxxxxxxxx <fio-owner@xxxxxxxxxxxxxxx> On Behalf
> Of Stephen Bates
> Sent: Friday, May 08, 2020 8:47 AM
> To: fio@xxxxxxxxxxxxxxx
> Cc: Jens Axboe <axboe@xxxxxxxxx>; David Sloan
> <David.Sloan@xxxxxxxxxxxxx>
> Subject: [BUG] parse.c: val_too_large incorrectly handling overly
> large FIO_OPT_INT values
>
> Hi All
>
> While trying to do some rate limiting in a high performance NVMe
> system we noticed that setting --rate to many values over 4G was
> broken (e.g. 8GB). As we dug into that it seems like the error
> handling for any FIO_OPTS_INT >=4GiB is not working because
> val_too_large in parse.c is conflating large positives uints with
> small negatives units uints and letting large values slide through.
> Tested against the tip of master (b2ed1c4a07c6 at time of writing).
>
> I *would* submit a patch but it is actually a little tricky to keep
> the patch contained in val_too_large and separate the small negative
> number issue from the big positive number issue. So I wondered if
> anyone had any suggestions. I don't really want to propose something
> like adding a FIO_OPTS_UINT if there is an easier fix. We could also
> consider changing val to a signed long long but (I think) breaks the
> case when a ULL is passed in.
...
> You can test this with something like:
>
> ./fio --debug=parse --name=parse_check --rate=8G,8G --size=16k --
> filename /tmp/parse.dat
Fundamentally, this argument needs to support larger than
32-bit values. Persistent memory devices easily exceed that
bandwidth too.
Other arguments like "size" already take large values into an
unsigned long long. So, just changing this for "rate" and
"rate_min" might suffice:
.type = FIO_OPT_INT,
to
.type = FIO_OPT_STR_VAL,
