This PR breaks usb fuzzing, since, apparently, the kernel always routes the usb coverage via a kcov remote handle that equals the usb device's bus number (?): For example, each hub_event worker uses the USB bus number as the task instance id. (from the docs).

@xairy, do you remember whether/where we can control the bus numbers of the usb devices we create for fuzzing? Can these be arbitrary uint32 numbers? Or do we really not want it because we e.g. cannot reliably clean up such devices after each executor restart?

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 61.0%. Comparing base (f815599) to head (dc1bf5b).
Report is 279 commits behind head on master.

This PR breaks usb fuzzing, since, apparently, the kernel always routes the usb coverage via a kcov remote handle that equals the usb device's bus number (?): For example, each hub_event worker uses the USB bus number as the task instance id. (from the docs).

@xairy, do you remember whether/where we can control the bus numbers of the usb devices we create for fuzzing? Can these be arbitrary uint32 numbers? Or do we really not want it because we e.g. cannot reliably clean up such devices after each executor restart?

We do not control the USB bus numbers, the dummy_hcd module creates them sequentially starting from 1. We pass dummy_hcd.num=N (N == proc) to the kernel command-line to make dummy_hcd create a bus for each executor. And the kernel USB code uses fixed KCOV handles derived from the bus numbers (see kcov_remote_start_usb).

So yeah, this change will break USB coverage collection.

Ah, that's a pity. Then there's no chance to work around the lost kcov handles bug until the fix reaches the mainline.

Thanks for sharing the details!