On Wed, 20 May 2020 at 05:44, Nathan Chancellor
wrote:
>
> On Tue, May 19, 2020 at 11:16:24PM -0400, Qian Cai wrote:
> > On Tue, May 19, 2020 at 10:47 PM Nathan Chancellor
> > wrote:
> > >
> > > On Tue, May 19, 2020 at 10:28:41PM -0400, Qian Cai wrote:
> > > >
> > > >
> > > > > On May 19, 2020, a
On Tue, May 19, 2020 at 11:16:24PM -0400, Qian Cai wrote:
> On Tue, May 19, 2020 at 10:47 PM Nathan Chancellor
> wrote:
> >
> > On Tue, May 19, 2020 at 10:28:41PM -0400, Qian Cai wrote:
> > >
> > >
> > > > On May 19, 2020, at 6:05 PM, Thomas Gleixner wrote:
> > > >
> > > > Yes, it's unfortunate,
On Tue, May 19, 2020 at 10:47 PM Nathan Chancellor
wrote:
>
> On Tue, May 19, 2020 at 10:28:41PM -0400, Qian Cai wrote:
> >
> >
> > > On May 19, 2020, at 6:05 PM, Thomas Gleixner wrote:
> > >
> > > Yes, it's unfortunate, but we have to stop making major concessions just
> > > because tools are no
On Tue, May 19, 2020 at 10:28:41PM -0400, Qian Cai wrote:
>
>
> > On May 19, 2020, at 6:05 PM, Thomas Gleixner wrote:
> >
> > Yes, it's unfortunate, but we have to stop making major concessions just
> > because tools are not up to the task.
> >
> > We've done that way too much in the past and
> On May 19, 2020, at 6:05 PM, Thomas Gleixner wrote:
>
> Yes, it's unfortunate, but we have to stop making major concessions just
> because tools are not up to the task.
>
> We've done that way too much in the past and this particular problem
> clearly demonstrates that there are limits.
>
Qian Cai writes:
> On Tue, May 19, 2020 at 5:26 PM Marco Elver wrote:
>> The new solution is here:
>> https://lkml.kernel.org/r/20200515150338.190344-1-el...@google.com
>> While it's a little inconvenient that we'll require Clang 11
>> (currently available by building yourself from LLVM repo)
On Tue, May 19, 2020 at 5:26 PM Marco Elver wrote:
>
> On Tue, 19 May 2020 at 23:10, Qian Cai wrote:
> >
> > On Tue, May 12, 2020 at 3:09 PM Peter Zijlstra wrote:
> > >
> > > On Tue, May 12, 2020 at 08:38:39PM +0200, Marco Elver wrote:
> > > > diff --git a/include/linux/compiler.h b/include/linu
On Tue, 19 May 2020 at 23:10, Qian Cai wrote:
>
> On Tue, May 12, 2020 at 3:09 PM Peter Zijlstra wrote:
> >
> > On Tue, May 12, 2020 at 08:38:39PM +0200, Marco Elver wrote:
> > > diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> > > index 741c93c62ecf..e902ca5de811 100644
> > > -
On Tue, May 12, 2020 at 3:09 PM Peter Zijlstra wrote:
>
> On Tue, May 12, 2020 at 08:38:39PM +0200, Marco Elver wrote:
> > diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> > index 741c93c62ecf..e902ca5de811 100644
> > --- a/include/linux/compiler.h
> > +++ b/include/linux/compile
On Tue, May 12, 2020 at 08:38:39PM +0200, Marco Elver wrote:
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index 741c93c62ecf..e902ca5de811 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -224,13 +224,16 @@ void ftrace_likely_update(struct ftrace
If left plain, using __READ_ONCE and __WRITE_ONCE will result in many
false positives with KCSAN due to being instrumented normally. To fix,
we should move the kcsan_check and data_race into __*_ONCE.
Cc: Will Deacon
Cc: Thomas Gleixner
Cc: Paul E. McKenney
Cc: Ingo Molnar
Cc: Peter Zijlstra
11 matches
Mail list logo