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

[Li Wang]

On Wed, Apr 20, 2022 at 8:50 PM Cyril Hrubis <chrubis@suse.cz> wrote:


>
> > 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.
>

That's right, I overlooked that exp backoff time is longer than the set
value.



>
> > 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.
>

Yes, wait actively and confirm event handling is completed.
(`udevadm settle` is the direct way I can think of now)



> 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().
>

Good to know this, I have looked through that but am afraid it can't
fully satisfy our requirements.

Because the wait_for_uevents is only falling into an infinite loop
and returns if detecting the expected UEVENT (which was sent
from the kernel function kobject_uevent_env).

The key point here is, we have to confirm `udevd` completed the UEVENT
handling, otherwise only detecting event exists is not enough, there is
still
potentially get the race condition again if the event queue there.


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