[LTP] [PATCH v2] recvmsg01: Refactor using new LTP API

[Wei Gao]

On Fri, Apr 28, 2023 at 02:46:48PM +0200, Petr Vorel wrote:
> Hi Wei,
> 
> First, for some reason, with higher number of run "bad file descriptor" will
> fail, returning 0 instead of -1.
> It starts to fail from 200th:
> $ ./recvmsg01 -i 200
> 
> ...
> recvmsg01.c:283: TPASS: invalid iovec count successful
> recvmsg01.c:283: TPASS: rights reception successful
> recvmsg01.c:283: TPASS: invalid MSG_OOB flag set successful
> recvmsg01.c:283: TPASS: invalid MSG_ERRQUEUE flag set successful
> recvmsg01.c:283: TPASS: large cmesg length successful
> recvmsg01.c:276: TFAIL: bad file descriptor ; returned 0 (expected -1), errno 0 (expected 9): SUCCESS (0)
> 
> Summary:
> passed   1999
> failed   1
> broken   0
> skipped  0
> warnings 0
> 
> I also did some review, but I didn't have time to check properly whether subject
> of testing is valid (quite complex test).
> 
Thanks for your careful test.
I spent lot of time to investigat why this happen, finally i found it caused by wrong 
cleanup of the sock fd.
I also put this fix in v3 patch.

> > +static void setup_large_msg_control(int n)
> >  {
> > -	setup2();
> > -	controllen = sizeof(struct cmsghdr) - 1;
> > +	setup_valid_msg_control(n);
> > +	controllen = 128 * BUF_SIZE;
> Any idea why 128? What is this number for?
> >  }
I think this is random select number when this case first introduced.