[LTP] [PATCH 1/2] ioctl09: wait for udevd complete the uevent handling

[Li Wang]

Cyril Hrubis <chrubis@suse.cz> wrote:



>
> >  static void verify_ioctl(void)
> >  {
> > +     char cmd[BUFSIZ];
> > +
> > +     sprintf(cmd, "udevadm settle --exit-if-exists=%s", dev_path);
> > +
> >       const char *const cmd_parted_old[] = {"parted", "-s", "test.img",
> >                                             "mklabel", "msdos", "mkpart",
> >                                             "primary", "ext4", "1M",
> "10M",
> > @@ -75,11 +79,13 @@ static void verify_ioctl(void)
> >
> >       loopinfo.lo_flags =  LO_FLAGS_PARTSCAN;
> >       SAFE_IOCTL(dev_fd, LOOP_SET_STATUS, &loopinfo);
> > +     tst_system(cmd);
> >       check_partition(1, true);
> >       check_partition(2, false);
> >
> >       change_partition(cmd_parted_new);
> >       TST_RETRY_FUNC(ioctl(dev_fd, BLKRRPART, 0), TST_RETVAL_EQ0);
> > +     tst_system(cmd);
> >       check_partition(1, true);
> >       check_partition(2, true);
>
> We allready use TST_RETRY_FN_EXP_BACKOFF() in there with 30 second
>

I have to say, for most systems 30 sec is long enough, but we definitely got
sporadically fails in larger-scale automation testing.


timeout isn't that enough? And if it isn't wouldn't simply increasing
> the timeout to a minute or two fix the issue?
>


That should be better, I just have a try on my reproducible system,
but it does not work with enlarged to 180 seconds.

ioctl09.c:52: TPASS: access /dev/loop0p1 succeeds
octl09.c:47: TFAIL: access /sys/block/loop0/loop0p2 fails
Test timeouted, sending SIGKILL!
tst_test.c:1509: TINFO: If you are running on slow machine, try exporting
LTP_TIMEOUT_MUL > 1
tst_test.c:1511: TBROK: Test killed! (timeout?)


Note, the `udevadm settle` uses 180s as default timeout as well,
but it can work, I will look into udevadm.c to see if that does
something additional besides the waiting.

If so, we might need to remove the TST_RETRY_FN_EXP_BACKOFF
from this test.

-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20220420/d83e1a08/attachment.htm>