similar to: [PATCH v3 2/3] usb, kcov: collect coverage from hub_event

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

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 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

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 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 09:00:18PM +0200, Andrey Konovalov wrote: > On Thu, Oct 17, 2019 at 8:18 PM Greg Kroah-Hartman > <gregkh at linuxfoundation.org> wrote: > > > > 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

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, 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);

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 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:

mb() typically uses mfence on modern x86, but a micro-benchmark shows that it's 2 to 3 times slower than lock; addl that we use on older CPUs. So we really should use the locked variant everywhere, except that intel manual says that clflush is only ordered by mfence, so we can't. Note: some callers of clflush seems to assume sfence will order it, so there could be existing bugs around

mb() typically uses mfence on modern x86, but a micro-benchmark shows that it's 2 to 3 times slower than lock; addl that we use on older CPUs. So we really should use the locked variant everywhere, except that intel manual says that clflush is only ordered by mfence, so we can't. Note: some callers of clflush seems to assume sfence will order it, so there could be existing bugs around

Hello, I am going to commit a patch below, it fixes several cases when vnconfig(8) fails but returns zero exit status. Are there any objections? http://www.freebsd.org/cgi/query-pr.cgi?pr=45754 Index: vnconfig.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/vnconfig/vnconfig.c,v retrieving revision 1.13.2.6 diff -u -r1.13.2.6 vnconfig.c

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

Hi, Anyone knows who is involved with this page on llvm.org? Which bot is updating it? (it seems stalled right now) Thanks, Mehdi