All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Marco Elver <elver@google.com>,
	LKML <linux-kernel@vger.kernel.org>,
	kasan-dev <kasan-dev@googlegroups.com>,
	Ingo Molnar <mingo@kernel.org>,
	Frederic Weisbecker <frederic@kernel.org>,
	Will Deacon <will@kernel.org>,
	Naresh Kamboju <naresh.kamboju@linaro.org>,
	syzbot+23a256029191772c2f02@syzkaller.appspotmail.com,
	syzbot+56078ac0b9071335a745@syzkaller.appspotmail.com,
	syzbot+867130cb240c41f15164@syzkaller.appspotmail.com
Subject: Re: [patch 3/3] tick: Annotate tick_do_timer_cpu data races
Date: Thu, 17 Dec 2020 06:59:55 -0800	[thread overview]
Message-ID: <20201217145955.GP2657@paulmck-ThinkPad-P72> (raw)
In-Reply-To: <20201217104823.GU3040@hirez.programming.kicks-ass.net>

On Thu, Dec 17, 2020 at 11:48:23AM +0100, Peter Zijlstra wrote:
> On Wed, Dec 16, 2020 at 01:19:31PM -0800, Paul E. McKenney wrote:
> > Given that there is no optimization potential, then the main reason to use
> > data_race() instead of *_ONCE() is to prevent KCSAN from considering the
> > accesses when looking for data races.  But that is mostly for debugging
> > accesses, in cases when these accesses are not really part of the
> > concurrent algorithm.
> > 
> > So if I understand the situation correctly, I would be using *ONCE().
> 
> Huh, what, why?
> 
> The code doesn't need READ_ONCE(), it merely wants to tell kasan that
> the race it observes is fine and as to please shut up.
> 
> IOW data_race() is accurate and right.

Other way around.

The code does not need any of the compiler optimizations that might
someday be enabled by data_race().  So why do you need data_race() here?
What do exactly is lost by instead using READ_ONCE()?

							Thanx, Paul

  reply	other threads:[~2020-12-17 15:00 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-06 21:12 [patch 0/3] tick: Annotate and document the intentionaly racy tick_do_timer_cpu Thomas Gleixner
2020-12-06 21:12 ` [patch 1/3] tick: Remove pointless cpu valid check in hotplug code Thomas Gleixner
2020-12-07 11:59   ` Peter Zijlstra
2020-12-07 17:44     ` Thomas Gleixner
2020-12-11 22:21   ` Frederic Weisbecker
2020-12-12  0:16     ` Thomas Gleixner
2020-12-12  1:20       ` Frederic Weisbecker
2020-12-11 22:31   ` Frederic Weisbecker
2020-12-16 10:50   ` [tip: timers/urgent] " tip-bot2 for Thomas Gleixner
2020-12-06 21:12 ` [patch 2/3] tick/sched: Remove bogus boot "safety" check Thomas Gleixner
2020-12-11 22:41   ` Frederic Weisbecker
2020-12-16 10:50   ` [tip: timers/urgent] " tip-bot2 for Thomas Gleixner
2020-12-06 21:12 ` [patch 3/3] tick: Annotate tick_do_timer_cpu data races Thomas Gleixner
2020-12-07 12:09   ` Peter Zijlstra
2020-12-07 17:46     ` Thomas Gleixner
2020-12-07 18:19       ` Marco Elver
2020-12-07 19:43         ` Thomas Gleixner
2020-12-07 19:44         ` Paul E. McKenney
2020-12-07 21:46           ` Thomas Gleixner
2020-12-07 22:38             ` Paul E. McKenney
2020-12-07 22:46               ` Thomas Gleixner
2020-12-07 22:55                 ` Paul E. McKenney
2020-12-08  8:11           ` Peter Zijlstra
2020-12-08 15:03             ` Paul E. McKenney
2020-12-16  0:27               ` Thomas Gleixner
2020-12-16 21:19                 ` Paul E. McKenney
2020-12-16 21:23                   ` Thomas Gleixner
2020-12-16 21:32                     ` Paul E. McKenney
2020-12-17 10:48                   ` Peter Zijlstra
2020-12-17 14:59                     ` Paul E. McKenney [this message]
2020-12-08  8:01         ` Peter Zijlstra
2020-12-07 11:05 ` [patch 0/3] tick: Annotate and document the intentionaly racy tick_do_timer_cpu Marco Elver

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=20201217145955.GP2657@paulmck-ThinkPad-P72 \
    --to=paulmck@kernel.org \
    --cc=elver@google.com \
    --cc=frederic@kernel.org \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=naresh.kamboju@linaro.org \
    --cc=peterz@infradead.org \
    --cc=syzbot+23a256029191772c2f02@syzkaller.appspotmail.com \
    --cc=syzbot+56078ac0b9071335a745@syzkaller.appspotmail.com \
    --cc=syzbot+867130cb240c41f15164@syzkaller.appspotmail.com \
    --cc=tglx@linutronix.de \
    --cc=will@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.