On Tue, Mar 14, 2017 at 4:44 PM, Mark Rutland wrote:
>> > -static __always_inline int atomic_read(const atomic_t *v)
>> > +static __always_inline int arch_atomic_read(const atomic_t *v)
>> > {
>> > - return READ_ONCE((v)->counter);
>> > + return
On Tue, Mar 14, 2017 at 4:44 PM, Mark Rutland wrote:
>> > -static __always_inline int atomic_read(const atomic_t *v)
>> > +static __always_inline int arch_atomic_read(const atomic_t *v)
>> > {
>> > - return READ_ONCE((v)->counter);
>> > + return READ_ONCE_NOCHECK((v)->counter);
>>
>> Should
On Tue, Mar 14, 2017 at 04:32:30PM +0100, Peter Zijlstra wrote:
> On Tue, Mar 14, 2017 at 04:22:52PM +0100, Dmitry Vyukov wrote:
> > -static __always_inline int atomic_read(const atomic_t *v)
> > +static __always_inline int arch_atomic_read(const atomic_t *v)
> > {
> > - return
On Tue, Mar 14, 2017 at 04:32:30PM +0100, Peter Zijlstra wrote:
> On Tue, Mar 14, 2017 at 04:22:52PM +0100, Dmitry Vyukov wrote:
> > -static __always_inline int atomic_read(const atomic_t *v)
> > +static __always_inline int arch_atomic_read(const atomic_t *v)
> > {
> > - return
On Tue, Mar 14, 2017 at 04:22:52PM +0100, Dmitry Vyukov wrote:
> -static __always_inline int atomic_read(const atomic_t *v)
> +static __always_inline int arch_atomic_read(const atomic_t *v)
> {
> - return READ_ONCE((v)->counter);
> + return READ_ONCE_NOCHECK((v)->counter);
Should NOCHEKC
On Tue, Mar 14, 2017 at 04:22:52PM +0100, Dmitry Vyukov wrote:
> -static __always_inline int atomic_read(const atomic_t *v)
> +static __always_inline int arch_atomic_read(const atomic_t *v)
> {
> - return READ_ONCE((v)->counter);
> + return READ_ONCE_NOCHECK((v)->counter);
Should NOCHEKC
On Tue, Mar 14, 2017 at 04:22:52PM +0100, Dmitry Vyukov wrote:
> Any other suggestions?
> - return i + xadd(>counter, i);
> + return i + arch_xadd(>counter, i);
> +#define xadd(ptr, v) \
> +({ \
> +
On Tue, Mar 14, 2017 at 04:22:52PM +0100, Dmitry Vyukov wrote:
> Any other suggestions?
> - return i + xadd(>counter, i);
> + return i + arch_xadd(>counter, i);
> +#define xadd(ptr, v) \
> +({ \
> +
On Wed, Mar 8, 2017 at 6:43 PM, Will Deacon wrote:
> On Wed, Mar 08, 2017 at 03:20:41PM +, Mark Rutland wrote:
>> On Wed, Mar 08, 2017 at 02:42:10PM +0100, Dmitry Vyukov wrote:
>> > I think if we scope compiler atomic builtins to KASAN/KTSAN/KMSAN (and
>> > consequently
On Wed, Mar 8, 2017 at 6:43 PM, Will Deacon wrote:
> On Wed, Mar 08, 2017 at 03:20:41PM +, Mark Rutland wrote:
>> On Wed, Mar 08, 2017 at 02:42:10PM +0100, Dmitry Vyukov wrote:
>> > I think if we scope compiler atomic builtins to KASAN/KTSAN/KMSAN (and
>> > consequently x86/arm64) initially,
On Wed, Mar 08, 2017 at 03:20:41PM +, Mark Rutland wrote:
> On Wed, Mar 08, 2017 at 02:42:10PM +0100, Dmitry Vyukov wrote:
> > I think if we scope compiler atomic builtins to KASAN/KTSAN/KMSAN (and
> > consequently x86/arm64) initially, it becomes more realistic. For the
> > tools we don't
On Wed, Mar 08, 2017 at 03:20:41PM +, Mark Rutland wrote:
> On Wed, Mar 08, 2017 at 02:42:10PM +0100, Dmitry Vyukov wrote:
> > I think if we scope compiler atomic builtins to KASAN/KTSAN/KMSAN (and
> > consequently x86/arm64) initially, it becomes more realistic. For the
> > tools we don't
On Mon, Mar 6, 2017 at 9:35 PM, Peter Zijlstra wrote:
> On Mon, Mar 06, 2017 at 04:20:18PM +, Mark Rutland wrote:
>> > >> So the problem is doing load/stores from asm bits, and GCC
>> > >> (traditionally) doesn't try and interpret APP asm bits.
>> > >>
>> > >> However,
On Mon, Mar 6, 2017 at 9:35 PM, Peter Zijlstra wrote:
> On Mon, Mar 06, 2017 at 04:20:18PM +, Mark Rutland wrote:
>> > >> So the problem is doing load/stores from asm bits, and GCC
>> > >> (traditionally) doesn't try and interpret APP asm bits.
>> > >>
>> > >> However, could we not write a
On Wed, Mar 08, 2017 at 04:45:58PM +0100, Dmitry Vyukov wrote:
> On Wed, Mar 8, 2017 at 4:43 PM, Mark Rutland wrote:
> > On Wed, Mar 08, 2017 at 04:27:11PM +0100, Dmitry Vyukov wrote:
> >> On Wed, Mar 8, 2017 at 4:20 PM, Mark Rutland wrote:
> >> > As
On Wed, Mar 08, 2017 at 04:45:58PM +0100, Dmitry Vyukov wrote:
> On Wed, Mar 8, 2017 at 4:43 PM, Mark Rutland wrote:
> > On Wed, Mar 08, 2017 at 04:27:11PM +0100, Dmitry Vyukov wrote:
> >> On Wed, Mar 8, 2017 at 4:20 PM, Mark Rutland wrote:
> >> > As in my other reply, I'd prefer that we wrapped
On Wed, Mar 8, 2017 at 4:43 PM, Mark Rutland wrote:
> On Wed, Mar 08, 2017 at 04:27:11PM +0100, Dmitry Vyukov wrote:
>> On Wed, Mar 8, 2017 at 4:20 PM, Mark Rutland wrote:
>> > As in my other reply, I'd prefer that we wrapped the (arch-specific)
>> >
On Wed, Mar 8, 2017 at 4:43 PM, Mark Rutland wrote:
> On Wed, Mar 08, 2017 at 04:27:11PM +0100, Dmitry Vyukov wrote:
>> On Wed, Mar 8, 2017 at 4:20 PM, Mark Rutland wrote:
>> > As in my other reply, I'd prefer that we wrapped the (arch-specific)
>> > atomic implementations such that we can
On Wed, Mar 08, 2017 at 04:27:11PM +0100, Dmitry Vyukov wrote:
> On Wed, Mar 8, 2017 at 4:20 PM, Mark Rutland wrote:
> > As in my other reply, I'd prefer that we wrapped the (arch-specific)
> > atomic implementations such that we can instrument them explicitly in a
> > core
On Wed, Mar 08, 2017 at 04:27:11PM +0100, Dmitry Vyukov wrote:
> On Wed, Mar 8, 2017 at 4:20 PM, Mark Rutland wrote:
> > As in my other reply, I'd prefer that we wrapped the (arch-specific)
> > atomic implementations such that we can instrument them explicitly in a
> > core header. That means
Hi,
On Wed, Mar 08, 2017 at 02:42:10PM +0100, Dmitry Vyukov wrote:
> I think if we scope compiler atomic builtins to KASAN/KTSAN/KMSAN (and
> consequently x86/arm64) initially, it becomes more realistic. For the
> tools we don't care about absolute efficiency and this gets rid of
> Will's points
Hi,
On Wed, Mar 08, 2017 at 02:42:10PM +0100, Dmitry Vyukov wrote:
> I think if we scope compiler atomic builtins to KASAN/KTSAN/KMSAN (and
> consequently x86/arm64) initially, it becomes more realistic. For the
> tools we don't care about absolute efficiency and this gets rid of
> Will's points
On Wed, Mar 8, 2017 at 4:20 PM, Mark Rutland wrote:
> Hi,
>
> On Wed, Mar 08, 2017 at 02:42:10PM +0100, Dmitry Vyukov wrote:
>> I think if we scope compiler atomic builtins to KASAN/KTSAN/KMSAN (and
>> consequently x86/arm64) initially, it becomes more realistic. For the
>>
On Wed, Mar 8, 2017 at 4:20 PM, Mark Rutland wrote:
> Hi,
>
> On Wed, Mar 08, 2017 at 02:42:10PM +0100, Dmitry Vyukov wrote:
>> I think if we scope compiler atomic builtins to KASAN/KTSAN/KMSAN (and
>> consequently x86/arm64) initially, it becomes more realistic. For the
>> tools we don't care
On Mon, Mar 06, 2017 at 04:20:18PM +, Mark Rutland wrote:
> > >> So the problem is doing load/stores from asm bits, and GCC
> > >> (traditionally) doesn't try and interpret APP asm bits.
> > >>
> > >> However, could we not write a GCC plugin that does exactly that?
> > >> Something that
On Mon, Mar 06, 2017 at 04:20:18PM +, Mark Rutland wrote:
> > >> So the problem is doing load/stores from asm bits, and GCC
> > >> (traditionally) doesn't try and interpret APP asm bits.
> > >>
> > >> However, could we not write a GCC plugin that does exactly that?
> > >> Something that
On Mon, Mar 06, 2017 at 05:27:44PM +0100, Dmitry Vyukov wrote:
> On Mon, Mar 6, 2017 at 5:20 PM, Mark Rutland wrote:
> > On Mon, Mar 06, 2017 at 03:24:23PM +0100, Dmitry Vyukov wrote:
> >> On Mon, Mar 6, 2017 at 2:01 PM, Peter Zijlstra
> >> wrote:
>
On Mon, Mar 06, 2017 at 05:27:44PM +0100, Dmitry Vyukov wrote:
> On Mon, Mar 6, 2017 at 5:20 PM, Mark Rutland wrote:
> > On Mon, Mar 06, 2017 at 03:24:23PM +0100, Dmitry Vyukov wrote:
> >> On Mon, Mar 6, 2017 at 2:01 PM, Peter Zijlstra
> >> wrote:
> >> > On Mon, Mar 06, 2017 at 01:58:51PM
On 03/06/2017 05:24 PM, Dmitry Vyukov wrote:
> Let me provide more context and design alternatives.
>
> There are also other archs, at least arm64 for now.
> There are also other tools. For KTSAN (race detector) we will
> absolutely need to hook into atomic ops. For KMSAN (uses of unit
> values)
On 03/06/2017 05:24 PM, Dmitry Vyukov wrote:
> Let me provide more context and design alternatives.
>
> There are also other archs, at least arm64 for now.
> There are also other tools. For KTSAN (race detector) we will
> absolutely need to hook into atomic ops. For KMSAN (uses of unit
> values)
On Mon, Mar 6, 2017 at 5:20 PM, Mark Rutland wrote:
> Hi,
>
> [roping in Will, since he loves atomics]
>
> On Mon, Mar 06, 2017 at 03:24:23PM +0100, Dmitry Vyukov wrote:
>> On Mon, Mar 6, 2017 at 2:01 PM, Peter Zijlstra wrote:
>> > On Mon, Mar 06, 2017
On Mon, Mar 6, 2017 at 5:20 PM, Mark Rutland wrote:
> Hi,
>
> [roping in Will, since he loves atomics]
>
> On Mon, Mar 06, 2017 at 03:24:23PM +0100, Dmitry Vyukov wrote:
>> On Mon, Mar 6, 2017 at 2:01 PM, Peter Zijlstra wrote:
>> > On Mon, Mar 06, 2017 at 01:58:51PM +0100, Peter Zijlstra wrote:
Hi,
[roping in Will, since he loves atomics]
On Mon, Mar 06, 2017 at 03:24:23PM +0100, Dmitry Vyukov wrote:
> On Mon, Mar 6, 2017 at 2:01 PM, Peter Zijlstra wrote:
> > On Mon, Mar 06, 2017 at 01:58:51PM +0100, Peter Zijlstra wrote:
> >> On Mon, Mar 06, 2017 at 01:50:47PM
Hi,
[roping in Will, since he loves atomics]
On Mon, Mar 06, 2017 at 03:24:23PM +0100, Dmitry Vyukov wrote:
> On Mon, Mar 6, 2017 at 2:01 PM, Peter Zijlstra wrote:
> > On Mon, Mar 06, 2017 at 01:58:51PM +0100, Peter Zijlstra wrote:
> >> On Mon, Mar 06, 2017 at 01:50:47PM +0100, Dmitry Vyukov
On Mon, Mar 06, 2017 at 04:20:13PM +0100, Peter Zijlstra wrote:
> On Mon, Mar 06, 2017 at 03:24:23PM +0100, Dmitry Vyukov wrote:
> > We could also provide a parallel implementation of atomic ops based on
> > the new compiler builtins (__atomic_load_n and friends):
> >
On Mon, Mar 06, 2017 at 04:20:13PM +0100, Peter Zijlstra wrote:
> On Mon, Mar 06, 2017 at 03:24:23PM +0100, Dmitry Vyukov wrote:
> > We could also provide a parallel implementation of atomic ops based on
> > the new compiler builtins (__atomic_load_n and friends):
> >
On Mon, Mar 06, 2017 at 03:24:23PM +0100, Dmitry Vyukov wrote:
> We could also provide a parallel implementation of atomic ops based on
> the new compiler builtins (__atomic_load_n and friends):
> https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
> and enable it under KSAN. The
On Mon, Mar 06, 2017 at 03:24:23PM +0100, Dmitry Vyukov wrote:
> We could also provide a parallel implementation of atomic ops based on
> the new compiler builtins (__atomic_load_n and friends):
> https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
> and enable it under KSAN. The
On Mon, Mar 06, 2017 at 03:24:23PM +0100, Dmitry Vyukov wrote:
> We could involve compiler (and by compiler I mean clang, because we
> are not going to touch gcc, any volunteers?).
FWIW, clang isn't even close to being a viable compiler for the kernel.
It lacks far too many features, _IF_ you can
On Mon, Mar 06, 2017 at 03:24:23PM +0100, Dmitry Vyukov wrote:
> We could involve compiler (and by compiler I mean clang, because we
> are not going to touch gcc, any volunteers?).
FWIW, clang isn't even close to being a viable compiler for the kernel.
It lacks far too many features, _IF_ you can
On Mon, Mar 6, 2017 at 2:01 PM, Peter Zijlstra wrote:
> On Mon, Mar 06, 2017 at 01:58:51PM +0100, Peter Zijlstra wrote:
>> On Mon, Mar 06, 2017 at 01:50:47PM +0100, Dmitry Vyukov wrote:
>> > On Mon, Mar 6, 2017 at 1:42 PM, Dmitry Vyukov wrote:
>> > >
On Mon, Mar 6, 2017 at 2:01 PM, Peter Zijlstra wrote:
> On Mon, Mar 06, 2017 at 01:58:51PM +0100, Peter Zijlstra wrote:
>> On Mon, Mar 06, 2017 at 01:50:47PM +0100, Dmitry Vyukov wrote:
>> > On Mon, Mar 6, 2017 at 1:42 PM, Dmitry Vyukov wrote:
>> > > KASAN uses compiler instrumentation to
On Mon, Mar 06, 2017 at 01:58:51PM +0100, Peter Zijlstra wrote:
> On Mon, Mar 06, 2017 at 01:50:47PM +0100, Dmitry Vyukov wrote:
> > On Mon, Mar 6, 2017 at 1:42 PM, Dmitry Vyukov wrote:
> > > KASAN uses compiler instrumentation to intercept all memory accesses.
> > > But it
On Mon, Mar 06, 2017 at 01:58:51PM +0100, Peter Zijlstra wrote:
> On Mon, Mar 06, 2017 at 01:50:47PM +0100, Dmitry Vyukov wrote:
> > On Mon, Mar 6, 2017 at 1:42 PM, Dmitry Vyukov wrote:
> > > KASAN uses compiler instrumentation to intercept all memory accesses.
> > > But it does not see memory
On Mon, Mar 06, 2017 at 01:50:47PM +0100, Dmitry Vyukov wrote:
> On Mon, Mar 6, 2017 at 1:42 PM, Dmitry Vyukov wrote:
> > KASAN uses compiler instrumentation to intercept all memory accesses.
> > But it does not see memory accesses done in assembly code.
> > One notable user
On Mon, Mar 06, 2017 at 01:50:47PM +0100, Dmitry Vyukov wrote:
> On Mon, Mar 6, 2017 at 1:42 PM, Dmitry Vyukov wrote:
> > KASAN uses compiler instrumentation to intercept all memory accesses.
> > But it does not see memory accesses done in assembly code.
> > One notable user of assembly code is
KASAN uses compiler instrumentation to intercept all memory accesses.
But it does not see memory accesses done in assembly code.
One notable user of assembly code is atomic operations. Frequently,
for example, an atomic reference decrement is the last access to an
object and a good candidate for a
KASAN uses compiler instrumentation to intercept all memory accesses.
But it does not see memory accesses done in assembly code.
One notable user of assembly code is atomic operations. Frequently,
for example, an atomic reference decrement is the last access to an
object and a good candidate for a
On Mon, Mar 6, 2017 at 1:42 PM, Dmitry Vyukov wrote:
> KASAN uses compiler instrumentation to intercept all memory accesses.
> But it does not see memory accesses done in assembly code.
> One notable user of assembly code is atomic operations. Frequently,
> for example, an
On Mon, Mar 6, 2017 at 1:42 PM, Dmitry Vyukov wrote:
> KASAN uses compiler instrumentation to intercept all memory accesses.
> But it does not see memory accesses done in assembly code.
> One notable user of assembly code is atomic operations. Frequently,
> for example, an atomic reference
50 matches
Mail list logo