similar to: [PATCH RFC 3/3] vhost, kcov: collect coverage from vhost_worker

On Thu, Oct 17, 2019 at 07:44:15PM +0200, Andrey Konovalov wrote: > This patch adds kcov_remote_start/kcov_remote_stop annotations to the > vhost_worker function, which is responsible for processing vhost works. > Since vhost_worker is spawned when a vhost device instance is created, > the common kcov handle is used for kcov_remote_start/stop annotations. > > Signed-off-by:

On Wed, Oct 23, 2019 at 3:35 PM Andrey Konovalov <andreyknvl at google.com> wrote: > > On Wed, Oct 23, 2019 at 10:36 AM Dmitry Vyukov <dvyukov at google.com> wrote: > > > > On Tue, Oct 22, 2019 at 6:46 PM Andrey Konovalov <andreyknvl at google.com> wrote: > > > > > > This patch adds kcov_remote_start()/kcov_remote_stop() annotations to the >

On Tue, Oct 22, 2019 at 6:46 PM Andrey Konovalov <andreyknvl at google.com> wrote: > > This patch adds kcov_remote_start()/kcov_remote_stop() annotations to the > vhost_worker() function, which is responsible for processing vhost works. > Since vhost_worker() threads are spawned per vhost device instance > the common kcov handle is used for kcov_remote_start()/stop()

On Wed, 23 Oct 2019 17:24:29 +0200 Andrey Konovalov <andreyknvl at google.com> wrote: > This patch adds background thread coverage collection ability to kcov. > > With KCOV_ENABLE coverage is collected only for syscalls that are issued > from the current process. With KCOV_REMOTE_ENABLE it's possible to collect > coverage for arbitrary parts of the kernel code, provided

On Thu, Oct 17, 2019 at 7:44 PM Andrey Konovalov <andreyknvl at google.com> wrote: > > Currently kcov can only collect coverage for syscalls that are issued > from the current process. This patch adds support for KCOV_REMOTE_ENABLE, > that makes it possible to collect coverage for arbitrary parts of the > kernel code, provided that this part is annotated with kcov_remote_start

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

On Thu, Oct 17, 2019 at 09:06:56PM +0200, Andrey Konovalov 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

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-20191025] [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:

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 >

On Wed, Oct 23, 2019 at 5:24 PM Andrey Konovalov <andreyknvl at google.com> wrote: > > This patch adds background thread coverage collection ability to kcov. ... > +static struct kcov_remote *kcov_remote_add(struct kcov *kcov, u64 handle) > +{ > + struct kcov_remote *remote; > + > + if (kcov_remote_find(handle)) > + return ERR_PTR(-EEXIST);

On Tue, Oct 22, 2019 at 6:46 PM Andrey Konovalov <andreyknvl at google.com> wrote: > > This patchset extends kcov to allow collecting coverage from the USB > subsystem and vhost workers. See the first patch description for details > about the kcov extension. The other two patches apply this kcov extension > to USB and vhost. > > These patches have been used to enable

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:

On Wed, 23 Oct 2019 17:24:28 +0200 Andrey Konovalov <andreyknvl at google.com> wrote: > This patchset extends kcov to allow collecting coverage from the USB > subsystem and vhost workers. See the first patch description for details > about the kcov extension. The other two patches apply this kcov extension > to USB and vhost. > > These patches have been used to enable

On Thu, 24 Oct 2019 14:47:31 +0200 Andrey Konovalov <andreyknvl at google.com> wrote: > > is it expected that the new kcov feature will be used elsewhere in the > > kernel? > > > > If the latter, which are the expected subsystems? > > Currently we encountered two cases where this is useful: USB and vhost > workers. Most probably there are more subsystems

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:

When switching from kthreads to vhost_tasks two bugs were added: 1. The vhost worker tasks's now show up as processes so scripts doing ps or ps a would not incorrectly detect the vhost task as another process. 2. kthreads disabled freeze by setting PF_NOFREEZE, but vhost tasks's didn't disable or add support for them. To fix both bugs, this switches the vhost task to be thread in the

If userspace does VHOST_VSOCK_SET_GUEST_CID before VHOST_SET_OWNER we can race where: 1. thread0 calls vhost_transport_send_pkt -> vhost_work_queue 2. thread1 does VHOST_SET_OWNER which calls vhost_worker_create. 3. vhost_worker_create will set the dev->worker pointer before setting the worker->vtsk pointer. 4. thread0's vhost_work_queue will see the dev->worker pointer is set and

If userspace does VHOST_VSOCK_SET_GUEST_CID before VHOST_SET_OWNER we can race where: 1. thread0 calls vhost_transport_send_pkt -> vhost_work_queue 2. thread1 does VHOST_SET_OWNER which calls vhost_worker_create. 3. vhost_worker_create will set the dev->worker pointer before setting the worker->vtsk pointer. 4. thread0's vhost_work_queue will see the dev->worker pointer is set and

On Mon, Jun 05, 2023 at 01:57:30PM -0500, Mike Christie wrote: >If userspace does VHOST_VSOCK_SET_GUEST_CID before VHOST_SET_OWNER we >can race where: >1. thread0 calls vhost_transport_send_pkt -> vhost_work_queue >2. thread1 does VHOST_SET_OWNER which calls vhost_worker_create. >3. vhost_worker_create will set the dev->worker pointer before setting >the worker->vtsk

On Wed, May 31, 2023 at 11:27:12AM -0500, Mike Christie wrote: >On 5/31/23 10:15 AM, Mike Christie wrote: >>>> rcu would work for your case and for what Jason had requested. >>> Yeah, so you already have some patches? >>> >>> Do you want to send it to solve this problem? >>> >> Yeah, I'll break them out and send them later today when I