Displaying 20 results from an estimated 11000 matches similar to: "[PATCH v2 0/3] kcov: collect coverage from usb and vhost"
2019 Oct 23
0
[PATCH 0/3] kcov: collect coverage from usb and vhost
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
2019 Oct 23
0
[PATCH v2 0/3] kcov: collect coverage from usb and vhost
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
2019 Oct 17
0
[PATCH RFC 2/3] usb, kcov: collect coverage from hub_event
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
2019 Oct 17
0
[PATCH RFC 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
2019 Oct 23
0
[PATCH 3/3] vhost, kcov: collect coverage from vhost_worker
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
>
2019 Nov 07
0
[PATCH v3 2/3] usb, kcov: collect coverage from hub_event
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
>
2019 Oct 23
0
[PATCH 3/3] vhost, kcov: collect coverage from vhost_worker
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()
2019 Oct 17
0
[PATCH RFC 3/3] vhost, kcov: collect coverage from vhost_worker
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
2019 Oct 17
0
[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:
2019 Oct 23
0
[PATCH v2 1/3] kcov: remote coverage support
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
2019 Oct 24
0
[PATCH v2 1/3] kcov: remote coverage support
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);
2019 Oct 23
0
[PATCH 2/3] usb, kcov: collect coverage from hub_event
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:
2019 Oct 21
0
[PATCH RFC 1/3] kcov: remote coverage support
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
2019 Oct 25
0
[PATCH v2 3/3] vhost, kcov: collect coverage from vhost_worker
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:
2019 Oct 23
0
[PATCH 1/3] kcov: remote coverage support
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:
2020 Jan 24
2
Adding support for LLVM Branch Condition Coverage
+ Vedant
Hi Hal, thanks.
I apologize if my answers aren't as thorough as you would like; what I'm proposing is simply an extension to the existing infrastructure, so it would be enabled automatically as part of code coverage. Mapping of branch regions would be done in CoverageMappingGen and instrumented using the same profiling instrumentation mechanism under
2016 Jan 28
10
[PATCH v5 0/5] x86: faster smp_mb()+documentation tweaks
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
2016 Jan 28
10
[PATCH v5 0/5] x86: faster smp_mb()+documentation tweaks
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
2016 Sep 21
2
-sanitizer-coverage-prune-blocks=true and LibFuzzer
> On Sep 21, 2016, at 9:36 AM, Kostya Serebryany via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> Exciting!
>
> (btw, I'd prefer libfuzzer at googlegroups.com <mailto:libfuzzer at googlegroups.com> for such discussions, please start new topics there)
You mean a LLVM library has a separate mailing-list? Why?
—
Mehdi
>
> I can reproduce this too, but
2016 Sep 21
2
-sanitizer-coverage-prune-blocks=true and LibFuzzer
> On Sep 21, 2016, at 12:56 PM, Kostya Serebryany <kcc at google.com> wrote:
>
>
>
> On Wed, Sep 21, 2016 at 12:32 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:
>
>> On Sep 21, 2016, at 9:36 AM, Kostya Serebryany via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: