All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Dmitry Vyukov <dvyukov@google.com>,
	peterz@infradead.org, mingo@redhat.com, will.deacon@arm.com,
	akpm@linux-foundation.org, kasan-dev@googlegroups.com,
	linux-mm@kvack.org, x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] asm-generic, x86: wrap atomic operations
Date: Tue, 21 Mar 2017 10:41:39 +0000	[thread overview]
Message-ID: <20170321104139.GA22188@leverpostej> (raw)
In-Reply-To: <956a8e10-e03f-a21c-99d9-8a75c2616e0a@virtuozzo.com>

On Tue, Mar 21, 2017 at 12:25:06PM +0300, Andrey Ryabinin wrote:
> On 03/20/2017 08:17 PM, Mark Rutland wrote:
> > Hi,
> > 
> > On Tue, Mar 14, 2017 at 08:24:13PM +0100, Dmitry Vyukov wrote:
> >>  /**
> >> - * atomic_read - read atomic variable
> >> + * arch_atomic_read - read atomic variable
> >>   * @v: pointer of type atomic_t
> >>   *
> >>   * Atomically reads the value of @v.
> >>   */
> >> -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);
> >> +	/*
> >> +	 * We use READ_ONCE_NOCHECK() because atomic_read() contains KASAN
> >> +	 * instrumentation. Double instrumentation is unnecessary.
> >> +	 */
> >> +	return READ_ONCE_NOCHECK((v)->counter);
> >>  }
> > 
> > Just to check, we do this to avoid duplicate reports, right?
> > 
> > If so, double instrumentation isn't solely "unnecessary"; it has a
> > functional difference, and we should explicitly describe that in the
> > comment.
> > 
> > ... or are duplicate reports supressed somehow?
> 
> They are not suppressed yet. But I think we should just switch kasan
> to single shot mode, i.e. report only the first error. Single bug
> quite often has multiple invalid memory accesses causing storm in
> dmesg. Also write OOB might corrupt metadata so the next report will
> print bogus alloc/free stacktraces.
> In most cases we need to look only at the first report, so reporting
> anything after the first is just counterproductive.

FWIW, that sounds sane to me.

Given that, I agree with your comment regarding READ_ONCE{,_NOCHECK}().

If anyone really wants all the reports, we could have a boot-time option
to do that.

Thanks,
Mark.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Dmitry Vyukov <dvyukov@google.com>,
	peterz@infradead.org, mingo@redhat.com, will.deacon@arm.com,
	akpm@linux-foundation.org, kasan-dev@googlegroups.com,
	linux-mm@kvack.org, x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] asm-generic, x86: wrap atomic operations
Date: Tue, 21 Mar 2017 10:41:39 +0000	[thread overview]
Message-ID: <20170321104139.GA22188@leverpostej> (raw)
In-Reply-To: <956a8e10-e03f-a21c-99d9-8a75c2616e0a@virtuozzo.com>

On Tue, Mar 21, 2017 at 12:25:06PM +0300, Andrey Ryabinin wrote:
> On 03/20/2017 08:17 PM, Mark Rutland wrote:
> > Hi,
> > 
> > On Tue, Mar 14, 2017 at 08:24:13PM +0100, Dmitry Vyukov wrote:
> >>  /**
> >> - * atomic_read - read atomic variable
> >> + * arch_atomic_read - read atomic variable
> >>   * @v: pointer of type atomic_t
> >>   *
> >>   * Atomically reads the value of @v.
> >>   */
> >> -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);
> >> +	/*
> >> +	 * We use READ_ONCE_NOCHECK() because atomic_read() contains KASAN
> >> +	 * instrumentation. Double instrumentation is unnecessary.
> >> +	 */
> >> +	return READ_ONCE_NOCHECK((v)->counter);
> >>  }
> > 
> > Just to check, we do this to avoid duplicate reports, right?
> > 
> > If so, double instrumentation isn't solely "unnecessary"; it has a
> > functional difference, and we should explicitly describe that in the
> > comment.
> > 
> > ... or are duplicate reports supressed somehow?
> 
> They are not suppressed yet. But I think we should just switch kasan
> to single shot mode, i.e. report only the first error. Single bug
> quite often has multiple invalid memory accesses causing storm in
> dmesg. Also write OOB might corrupt metadata so the next report will
> print bogus alloc/free stacktraces.
> In most cases we need to look only at the first report, so reporting
> anything after the first is just counterproductive.

FWIW, that sounds sane to me.

Given that, I agree with your comment regarding READ_ONCE{,_NOCHECK}().

If anyone really wants all the reports, we could have a boot-time option
to do that.

Thanks,
Mark.

  reply	other threads:[~2017-03-21 10:42 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-14 19:24 [PATCH 0/3] x86, kasan: add KASAN checks to atomic operations Dmitry Vyukov
2017-03-14 19:24 ` Dmitry Vyukov
2017-03-14 19:24 ` [PATCH 1/3] kasan: allow kasan_check_read/write() to accept pointers to volatiles Dmitry Vyukov
2017-03-14 19:24   ` Dmitry Vyukov
2017-03-14 19:24 ` [PATCH 2/3] asm-generic, x86: wrap atomic operations Dmitry Vyukov
2017-03-14 19:24   ` Dmitry Vyukov
2017-03-20 16:41   ` Andrey Ryabinin
2017-03-20 16:41     ` Andrey Ryabinin
2017-03-20 17:17   ` Mark Rutland
2017-03-20 17:17     ` Mark Rutland
2017-03-21  9:25     ` Andrey Ryabinin
2017-03-21  9:25       ` Andrey Ryabinin
2017-03-21 10:41       ` Mark Rutland [this message]
2017-03-21 10:41         ` Mark Rutland
2017-03-21 18:06         ` Dmitry Vyukov
2017-03-21 18:06           ` Dmitry Vyukov
2017-03-21 21:20           ` Arnd Bergmann
2017-03-21 21:20             ` Arnd Bergmann
2017-03-22 10:42             ` Dmitry Vyukov
2017-03-22 10:42               ` Dmitry Vyukov
2017-03-22 11:30               ` Arnd Bergmann
2017-03-22 11:30                 ` Arnd Bergmann
2017-03-22 12:14                 ` Dmitry Vyukov
2017-03-22 12:14                   ` Dmitry Vyukov
2017-03-22 12:48                   ` Arnd Bergmann
2017-03-22 12:48                     ` Arnd Bergmann
2017-03-24  6:52   ` Ingo Molnar
2017-03-24  6:52     ` Ingo Molnar
2017-03-24  7:14     ` Dmitry Vyukov
2017-03-24  7:14       ` Dmitry Vyukov
2017-03-24  8:39       ` Dmitry Vyukov
2017-03-24  8:39         ` Dmitry Vyukov
2017-03-24 10:57       ` Ingo Molnar
2017-03-24 10:57         ` Ingo Molnar
2017-03-24 12:46         ` Dmitry Vyukov
2017-03-24 12:46           ` Dmitry Vyukov
2017-03-28  7:52           ` Ingo Molnar
2017-03-28  7:52             ` Ingo Molnar
2017-03-28  9:27             ` Peter Zijlstra
2017-03-28  9:27               ` Peter Zijlstra
2017-03-28  9:46               ` Dmitry Vyukov
2017-03-28  9:46                 ` Dmitry Vyukov
2017-03-28  9:51               ` Ingo Molnar
2017-03-28  9:51                 ` Ingo Molnar
2017-03-28  9:56                 ` Dmitry Vyukov
2017-03-28  9:56                   ` Dmitry Vyukov
2017-03-28 10:15                   ` Ingo Molnar
2017-03-28 10:15                     ` Ingo Molnar
2017-03-28 16:29                     ` Dmitry Vyukov
2017-03-28 16:29                       ` Dmitry Vyukov
2017-03-14 19:24 ` [PATCH 3/3] asm-generic: add KASAN instrumentation to " Dmitry Vyukov
2017-03-14 19:24   ` Dmitry Vyukov
2017-03-30 22:30 ` [PATCH 0/3] x86, kasan: add KASAN checks " Andrew Morton
2017-03-30 22:30   ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170321104139.GA22188@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=aryabinin@virtuozzo.com \
    --cc=dvyukov@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=will.deacon@arm.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.