On Thu, 4 Jun 2020 at 08:00, Marco Elver wrote:
>
> On Wed, 3 Jun 2020 at 21:10, Marco Elver wrote:
> >
> > On Wed, 3 Jun 2020 at 20:16, Peter Zijlstra wrote:
> > >
> > > On Wed, Jun 03, 2020 at 06:07:22PM +0200, Peter Zijlstra wrote:
> > > > On Wed, Jun 03, 2020 at 04:47:54PM +0200, Marco Elver
On Wed, 3 Jun 2020 at 21:10, Marco Elver wrote:
>
> On Wed, 3 Jun 2020 at 20:16, Peter Zijlstra wrote:
> >
> > On Wed, Jun 03, 2020 at 06:07:22PM +0200, Peter Zijlstra wrote:
> > > On Wed, Jun 03, 2020 at 04:47:54PM +0200, Marco Elver wrote:
> >
> > > > With that in mind, you could whitelist "__u
On Wed, 3 Jun 2020 at 20:16, Peter Zijlstra wrote:
>
> On Wed, Jun 03, 2020 at 06:07:22PM +0200, Peter Zijlstra wrote:
> > On Wed, Jun 03, 2020 at 04:47:54PM +0200, Marco Elver wrote:
>
> > > With that in mind, you could whitelist "__ubsan_handle"-prefixed
> > > functions in objtool. Given the __a
On Wed, Jun 03, 2020 at 06:07:22PM +0200, Peter Zijlstra wrote:
> On Wed, Jun 03, 2020 at 04:47:54PM +0200, Marco Elver wrote:
> > With that in mind, you could whitelist "__ubsan_handle"-prefixed
> > functions in objtool. Given the __always_inline+noinstr+__ubsan_handle
> > case is quite rare, it
On Wed, 3 Jun 2020 at 18:07, Peter Zijlstra wrote:
>
> On Wed, Jun 03, 2020 at 04:47:54PM +0200, Marco Elver wrote:
>
> > This is fun: __always_inline functions inlined into
> > __no_sanitize_undefined *do* get instrumented because apparently UBSan
> > passes must run before the optimizer (before
On Wed, Jun 03, 2020 at 04:47:54PM +0200, Marco Elver wrote:
> This is fun: __always_inline functions inlined into
> __no_sanitize_undefined *do* get instrumented because apparently UBSan
> passes must run before the optimizer (before inlining), contrary to
> what [ATM]SAN instrumentation does. Bo
On Wed, 3 Jun 2020 at 15:32, Marco Elver wrote:
>
> On Wed, 3 Jun 2020 at 14:18, Peter Zijlstra wrote:
> >
> > On Wed, Jun 03, 2020 at 02:08:57PM +0200, Marco Elver wrote:
> >
> > > What is the .config you used? I somehow can't reproduce. I've applied
> > > the patches on top of -tip/master.
> >
On Wed, 3 Jun 2020 at 14:18, Peter Zijlstra wrote:
>
> On Wed, Jun 03, 2020 at 02:08:57PM +0200, Marco Elver wrote:
>
> > What is the .config you used? I somehow can't reproduce. I've applied
> > the patches on top of -tip/master.
>
> So tip/master, my patches, your patches, this series.
>
> $ mak
On Wed, Jun 03, 2020 at 02:08:57PM +0200, Marco Elver wrote:
> What is the .config you used? I somehow can't reproduce. I've applied
> the patches on top of -tip/master.
So tip/master, my patches, your patches, this series.
$ make CC=/opt/llvm/bin/clang O=defconfig-build/ -j80 -s bzImage
is wha
On Wed, 3 Jun 2020 at 14:08, Peter Zijlstra wrote:
>
> On Wed, Jun 03, 2020 at 02:00:37PM +0200, Peter Zijlstra wrote:
> > On Wed, Jun 03, 2020 at 01:40:14PM +0200, Peter Zijlstra wrote:
> > > The first patch is a fix for x86/entry, I'm quicky runing out of brown
> > > paper bags again :/
> > >
>
On Wed, Jun 03, 2020 at 02:00:37PM +0200, Peter Zijlstra wrote:
> On Wed, Jun 03, 2020 at 01:40:14PM +0200, Peter Zijlstra wrote:
> > The first patch is a fix for x86/entry, I'm quicky runing out of brown
> > paper bags again :/
> >
> > The rest goes on top of these:
> >
> > https://lkml.kerne
On Wed, Jun 03, 2020 at 01:40:14PM +0200, Peter Zijlstra wrote:
> The first patch is a fix for x86/entry, I'm quicky runing out of brown paper
> bags again :/
>
> The rest goes on top of these:
>
> https://lkml.kernel.org/r/20200602173103.931412...@infradead.org
> https://lkml.kernel.org/r/2
The first patch is a fix for x86/entry, I'm quicky runing out of brown paper
bags again :/
The rest goes on top of these:
https://lkml.kernel.org/r/20200602173103.931412...@infradead.org
https://lkml.kernel.org/r/20200602184409.22142-1-el...@google.com
patches from myself and Marco that ena
13 matches
Mail list logo
