search for: hub_event

...wrote: > On Thu, Oct 17, 2019 at 8:19 PM Greg Kroah-Hartman > <gregkh at linuxfoundation.org> wrote: > > > > On Thu, Oct 17, 2019 at 07:44:14PM +0200, Andrey Konovalov wrote: > > > This patch adds kcov_remote_start/kcov_remote_stop annotations to the > > > hub_event function, which is responsible for processing events on USB > > > buses, in particular events that happen during USB device enumeration. > > > Each USB bus gets a unique id, which can be used to attach a kcov device > > > to a particular USB bus for coverage collection. &...

On Thu, Oct 17, 2019 at 07:44:14PM +0200, Andrey Konovalov wrote: > This patch adds kcov_remote_start/kcov_remote_stop annotations to the > hub_event function, which is responsible for processing events on USB > buses, in particular events that happen during USB device enumeration. > Each USB bus gets a unique id, which can be used to attach a kcov device > to a particular USB bus for coverage collection. > > Signed-off-by: Andre...

On Tue, Oct 29, 2019 at 05:32:28PM +0100, Andrey Konovalov wrote: > This patch adds kcov_remote_start()/kcov_remote_stop() annotations to the > hub_event() function, which is responsible for processing events on USB > buses, in particular events that happen during USB device enumeration. > Since hub_event() is run in a global background kernel thread (see > Documentation/dev-tools/kcov.rst for details), each USB bus gets a unique > globa...

Hi Andrey, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.4-rc4 next-20191023] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url:

...> - 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, kcov: collect coverage from vhost_worker > > Documentation/dev-tools/kcov.rst | 120 ++++++++ > drivers/usb/core/hub.c | 5 + > drivers/vhost/vhost.c | 6 + > drivers/vhost/vhost.h | 1 + > include/linux/kcov.h | 6...

...parts of the kernel code, provided that those parts > are annotated with kcov_remote_start()/kcov_remote_stop(). > > This allows to collect coverage from two types of kernel background > threads: the global ones, that are spawned during kernel boot and are > always running (e.g. USB hub_event()); and the local ones, that are > spawned when a user interacts with some kernel interface (e.g. vhost > workers). > > To enable collecting coverage from a global background thread, a unique > global handle must be assigned and passed to the corresponding > kcov_remote_start() c...

Previous 2.6.31-rc8 kernel was built on F11 and installed with modules on F12. Current kernel has been built on F12 (2.6.31-0.204.rc9.fc12.x86_64) and installed on F12 before loading under Xen 3.4.1. Dmesg log looks similar to Michael Yuong''s ''rc7.git4''  kernel for F12. Boris. --- On Tue, 9/8/09, Boris Derzhavets <bderzhavets@yahoo.com> wrote: From: Boris

...is annotated with kcov_remote_start > and kcov_remote_stop. Nitpick: () after function names is the common C style. > This allows to collect coverage from two types of kernel background > threads: the global ones, that are spawned during kernel boot and are > always running (e.g. USB hub_event); and the local ones, that are spawned > when a user interacts with some kernel interfaces (e.g. vhost). > > To enable collecting coverage from a global background thread, a unique > global id must be assigned and passed to the corresponding > kcov_remote_start annotation call. Then...

I''m currently working on moving storage services into their own domain and I''ve been looking at blktap2. I''ve been trying to get an image mounted with blktap2 and for some odd reason and tapdisk2 keeps hanging instead of quitting at the end. I haven''t removed any of the storage startup code at this point so everything should be as it normally is in xen-unstable.