Displaying 3 results from an estimated 3 matches for "common_handl".
Did you mean:
common_handle
2019 Oct 21
0
[PATCH RFC 1/3] kcov: remote coverage support
...Multiple ids can be targeted with the same
> kcov device simultaneously.
>
> Since there might be many local background threads spawned from different
> userspace processes, we can't use a single global id per annotation.
> Instead, the userspace process passes an id through the common_handle
> field of the kcov_remote_arg struct. This id gets saved to the kcov_handle
> field in the current task_struct and needs to be passed to the newly
> spawned threads via custom annotations. Those threads should be in turn
> annotated with kcov_remote_start/kcov_remote_stop.
>
> S...
2019 Oct 23
0
[PATCH 0/3] kcov: collect coverage from usb and vhost
...struct_size to calculate array size in kcov_ioctl().
> - Add a limit on area_size in kcov_remote_arg.
> - Added kcov_disable() helper.
> - Changed encoding of kcov remote handle ids, see the documentation.
> - Added a comment reference for kcov_sequence task_struct field.
> - Change common_handle type to u32.
> - Add checks for handle validity into kcov_ioctl_locked() and
> kcov_remote_start().
> - Updated documentation to reflect the changes.
>
> Andrey Konovalov (3):
> kcov: remote coverage support
> usb, kcov: collect coverage from hub_event
> vhost, kc...
2019 Oct 23
0
[PATCH v2 1/3] kcov: remote coverage support
...e
> sections, that are referenced by those handles.
>
> Since there might be many local background threads spawned from different
> userspace processes, we can't use a single global handle per annotation.
> Instead, the userspace process passes a non-zero handle through the
> common_handle field of the kcov_remote_arg struct. This common handle gets
> saved to the kcov_handle field in the current task_struct and needs to be
> passed to the newly spawned threads via custom annotations. Those threads
> should in turn be annotated with kcov_remote_start()/kcov_remote_stop().
&...