when kcov remote thread stop?

[Joey Jiao]

Hi, 

I have some doubts on remote kcov.

So, assume syscall thread A created local kthread B.

kcov_handle is passed from A to B, and kcov_remote_start/kcov_remote_end are put inside thread B function.

Is it possible that A completes execution while B is still not scheduled? In this case, remote coverage won't be collected back, right?

Another doubt is:

If A creates kthread B, and B creates kthread C. Is it possible to collect coverage for both B and C with the same kcov_handle?

THX

Joey

[Dmitry Vyukov]

On Wed, 16 Nov 2022 at 03:28, Joey Jiao <joey....@gmail.com> wrote:
>
> Hi,
> I have some doubts on remote kcov.
>
> So, assume syscall thread A created local kthread B.
> kcov_handle is passed from A to B, and kcov_remote_start/kcov_remote_end are put inside thread B function.
>
> Is it possible that A completes execution while B is still not scheduled? In this case, remote coverage won't be collected back, right?

Hi Joey,

It depends on how you use kcov in the process. I assume you are asking
about the syz-executor use of kcov.

The scenario you described should work. The thread that scheduled work
may finish the syscall and may even exit, remote coverage should still
be collected. In syz-executor we use a separate "remote" kcov object
to collect remote coverage and that object lives for the duration of
the process. The kcov_handle identifies that separate remote kcov
object, so what happens with the thread that issued the syscall does
not matter.

> Another doubt is:
> If A creates kthread B, and B creates kthread C. Is it possible to collect coverage for both B and C with the same kcov_handle?

Yes, this should work as well.
Multiple remote regions can add coverage to the same remote kcov object.

[Tamás Koczka]

Hey!

Disclaimer: I am a Syzkaller user, not a developer, so my answer may not be fully correct, please wait for a more complete answer from the Syzkaller team. Also my answer is for Linux.

> Is it possible that A completes execution while B is still not scheduled?

Yes.

> In this case, remote coverage won't be collected back, right?

Remote coverage is collected per Syzkaller program and not per syscall, so if thread B finishes execution before the Syzkaller program finishes (e.g. a handle is close()'d which causes thread B to run and wait for the result), then remote coverage will be collected, otherwise it won't be collected. Extra coverage is mostly collected here. Note there is an "prog_extra_cover_timeout" which is an additional timeout to wait for extra coverage, but if thread B runs e.g. seconds later after the Syzkaller program finished, then there is a chance that the extra coverage will be missing.

> If A creates kthread B, and B creates kthread C. Is it possible to collect coverage for both B and C with the same kcov_handle?

Yes, that works. (In Linux the kcov_handle basically associates the original thread which called the syscall with every other remote coverage happening between kcov_remote_start/kcov_remote_stop.)

--
You received this message because you are subscribed to the Google Groups "syzkaller" group.
To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/cf6679a1-02fa-47eb-a716-a1dddceacedbn%40googlegroups.com.

[Joey Jiao]

Thanks you all for the detailed answer, helpful.