<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 20, 2022 at 8:50 PM Cyril Hrubis <<a href="mailto:chrubis@suse.cz">chrubis@suse.cz</a>> wrote:<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
> Note, the `udevadm settle` uses 180s as default timeout as well,<br>
> but it can work, I will look into udevadm.c to see if that does<br>
> something additional besides the waiting.<br>
<br>
I guess that the difference is that when we wait on a socket actively we<br>
return sooner than with the exp backoff. By definition the exp backoff<br>
may wait for twice as long as the udevadm and because of that the test<br>
may actually timeout because we waited just a little bit longer.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">That's right, I overlooked that exp backoff time is longer than the set value.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> If so, we might need to remove the TST_RETRY_FN_EXP_BACKOFF<br>
> from this test.<br>
<br>
That would be valid option, remove the exp backoff and wait activelly.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Yes, wait actively and confirm event handling is completed.</div><div class="gmail_default" style="font-size:small">(`udevadm settle` is the direct way I can think of now)</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Btw we already have an infrastructure for matching kernel event uevents<br>
in the kernel/uevent/ directory. If we split the uevent.h there into a<br>
header and libs/ltpuevent/ we could simply wait for the event by filling<br>
in the uevent_desc structure and calling wait_for_uevents().<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Good to know this, I have looked through that but am afraid it can't</div><div class="gmail_default" style="font-size:small">fully satisfy our requirements. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Because the wait_for_uevents is only falling into an infinite loop</div><div class="gmail_default" style="font-size:small">and returns if detecting the expected UEVENT (which was sent</div><div class="gmail_default" style="font-size:small">from the kernel function kobject_uevent_env).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The key point here is, we have to confirm `udevd` completed the UEVENT</div><div class="gmail_default" style="font-size:small">handling, otherwise only detecting event exists is not enough, there is still</div><div class="gmail_default" style="font-size:small">potentially get the race condition again if the event queue there.</div><br></div><div> </div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>