From: Cyril Hrubis <chrubis@suse.cz>
To: Li Wang <liwang@redhat.com>
Cc: LTP List <ltp@lists.linux.it>
Subject: Re: [LTP] [PATCH 1/2] ioctl09: wait for udevd complete the uevent handling
Date: Wed, 20 Apr 2022 14:52:11 +0200 [thread overview]
Message-ID: <YmAB++5hoIjNwMkB@yuki> (raw)
In-Reply-To: <CAEemH2dTCBpynB3wj_8eTVvvJR_V4fGPZNvt_35noqdykKi52g@mail.gmail.com>
Hi!
> 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.
You have to set the test timeout to be four times of this timeout
otherwise it will report that the test had timeouted sporadically.
> 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.
I guess that the difference is that when we wait on a socket actively we
return sooner than with the exp backoff. By definition the exp backoff
may wait for twice as long as the udevadm and because of that the test
may actually timeout because we waited just a little bit longer.
> If so, we might need to remove the TST_RETRY_FN_EXP_BACKOFF
> from this test.
That would be valid option, remove the exp backoff and wait activelly.
Btw we already have an infrastructure for matching kernel event uevents
in the kernel/uevent/ directory. If we split the uevent.h there into a
header and libs/ltpuevent/ we could simply wait for the event by filling
in the uevent_desc structure and calling wait_for_uevents().
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2022-04-20 12:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-20 11:47 [LTP] [PATCH 1/2] ioctl09: wait for udevd complete the uevent handling Li Wang
2022-04-20 11:47 ` [LTP] [PATCH 2/2] mkswap01: wait for the triggered events to complete Li Wang
2022-04-20 12:07 ` Cyril Hrubis
2022-04-20 20:56 ` Petr Vorel
2022-04-21 2:18 ` Li Wang
2022-04-21 6:44 ` Li Wang
2022-04-21 7:47 ` Petr Vorel
2022-04-20 12:05 ` [LTP] [PATCH 1/2] ioctl09: wait for udevd complete the uevent handling Cyril Hrubis
2022-04-20 12:31 ` Li Wang
2022-04-20 12:52 ` Cyril Hrubis [this message]
2022-04-21 6:36 ` Li Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YmAB++5hoIjNwMkB@yuki \
--to=chrubis@suse.cz \
--cc=liwang@redhat.com \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.