[LTP] [PATCH v2] Rewrite process_vm_readv03.c test with new LTP API

[Jan Stancek]

On Wed, Feb 9, 2022 at 11:30 AM Cyril Hrubis <chrubis@suse.cz> wrote:
> > -static void gen_random_arr(int *arr, int arr_sz)
> > +static void create_data_size(int *arr, int arr_sz, int buffsize)
> >  {
> >       long bufsz_left, bufsz_single;
> >       int i;
> >
> > -     bufsz_left = bufsz;
> > +     bufsz_left = buffsize;
> >       for (i = 0; i < arr_sz - 1; i++) {
> > -             bufsz_single = rand() % (bufsz_left / 2) + 1;
> > +             bufsz_single = rand() % ((bufsz_left / 2) + 1);
>
> It was correct before you added the parenthesis, the + 1 was there to
> make sure we do not end up with an empty buffer if rand() returned
> multiple of bufsz_left/2.

I think that was to avoid the case you described below (modulo by zero),
zero iov_len appears allowed, so it may be interesting to let it be tested too.
(if bufsize and nriovecs allow such combination as you pointed out)

>
> Also I guess that this only works reasonably only for bufsize >
> 2^nriovecs otherwise you may end up doing modulo (%) operation by a
> zero which is undefined operation, I guess that the process would end up
> killed with SIGFPE.
>
> Looking at the code we actually depend on the fact that we have two
> iovec sets whose size is the same, and this of course works only if the
> buffer size is large enoug. This is actually quite complicated.
>
> I guess that we will have to change the code to make sure that bufz is
> not consumed until the very end, so maybe:
>
>         for (i = 0; i < arr_sz - 1; i++) {
>                 int mod = MAX(1, (bufz_left-arr_sz)/2);
>                 arr[i] = rand() % mod + 1
>                 bufz_left -= arr[i];
>         }
>
> With that we make sure that bufz_left is large enough as long as the
> bufsize >= arr_size (which is something that has to be so anyways).
>
> But thinking of it again, as long as we allow the iovec_len to be 0 your
> change is actually correct as malloc(0) returns a valid pointer on Linux
> (which is not generally guaranteed). But if we are going to use that
> version we should explicitly check the size == 0 when we allocate the
> iovec buffers and set the iov_base to NULL and iov_len to 0 in that
> case to make it clear that the buffers can have zero size.
>
>