Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1405574

Re: [PATCH v4 2/5] locking/rwsem: Protect all writes to owner by WRITE_ONCE

From Jason Low <jason.low2@hpe.com>
Newsgroups linux.kernel
Subject Re: [PATCH v4 2/5] locking/rwsem: Protect all writes to owner by WRITE_ONCE
Date 2016-05-23 20:50 +0200
Message-ID <rC35o-13f-29@gated-at.bofh.it> (permalink)
References (2 earlier) <rAakG-39y-23@gated-at.bofh.it> <rAdsj-54h-25@gated-at.bofh.it> <rAfNn-6pu-13@gated-at.bofh.it> <rAfNn-6pu-11@gated-at.bofh.it> <rBhDs-5HD-11@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Sat, 2016-05-21 at 09:04 -0700, Peter Hurley wrote:
> On 05/18/2016 12:58 PM, Jason Low wrote:
> > It should be fine to use the standard READ_ONCE here, even if it's just
> > for documentation, as it's probably not going to cost anything in
> > practice. It would be better to avoid adding any special macros for this
> > which may just add more complexity.
> 
> See, I don't understand this line of reasoning at all.
> 
> I read this as "it's ok to be non-optimal here where were spinning CPU
> time but not ok to be non-optimal generally elsewhere where it's
> way less important like at init time".

So I think there is a difference between using it during init time and
using it here where we're spinning. During init time, initializing the
owner field locklessly is normal. No other thread should be concurrently
be writing to the field, since the structure is just getting
initialized, so there are no surprises there.

Our access of the owner field in this function is special in that we're
using a bit of "lockless magic" to read and write to a field that gets
concurrently accessed without any serialization. Since we're not taking
the wait_lock in a scenario where we'd normally would take a lock, it
would be good to have this documented.

> And by the way, it's not just "here" but _everywhere_.
> What about reading ->on_cpu locklessly?

Sure, we could also use READ_ONCE when reading ->on_cpu  :)

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH v4 2/5] locking/rwsem: Protect all writes to owner by WRITE_ONCE() Waiman Long <Waiman.Long@hpe.com> - 2016-05-18 03:30 +0200
  Re: [PATCH v4 2/5] locking/rwsem: Protect all writes to owner by  WRITE_ONCE() Davidlohr Bueso <dave@stgolabs.net> - 2016-05-18 16:10 +0200
    Re: [PATCH v4 2/5] locking/rwsem: Protect all writes to owner by  WRITE_ONCE() Jason Low <jason.low2@hpe.com> - 2016-05-18 19:30 +0200
    Re: [PATCH v4 2/5] locking/rwsem: Protect all writes to owner by  WRITE_ONCE Jason Low <jason.low2@hpe.com> - 2016-05-18 19:30 +0200
      Re: [PATCH v4 2/5] locking/rwsem: Protect all writes to owner by  WRITE_ONCE Jason Low <jason.low2@hpe.com> - 2016-05-18 22:00 +0200
        Re: [PATCH v4 2/5] locking/rwsem: Protect all writes to owner by  WRITE_ONCE Jason Low <jason.low2@hpe.com> - 2016-05-20 00:40 +0200
        Re: [PATCH v4 2/5] locking/rwsem: Protect all writes to owner by  WRITE_ONCE Peter Hurley <peter@hurleysoftware.com> - 2016-05-21 18:10 +0200
          Re: [PATCH v4 2/5] locking/rwsem: Protect all writes to owner by  WRITE_ONCE Peter Zijlstra <peterz@infradead.org> - 2016-05-22 12:50 +0200
          Re: [PATCH v4 2/5] locking/rwsem: Protect all writes to owner by  WRITE_ONCE Jason Low <jason.low2@hpe.com> - 2016-05-23 20:50 +0200
            Re: [PATCH v4 2/5] locking/rwsem: Protect all writes to owner by  WRITE_ONCE Davidlohr Bueso <dave@stgolabs.net> - 2016-05-23 21:50 +0200
              Re: [PATCH v4 2/5] locking/rwsem: Protect all writes to owner by  WRITE_ONCE "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-05-23 22:20 +0200
                Re: [PATCH v4 2/5] locking/rwsem: Protect all writes to owner by  WRITE_ONCE Davidlohr Bueso <dave@stgolabs.net> - 2016-05-23 23:10 +0200
            Re: [PATCH v4 2/5] locking/rwsem: Protect all writes to owner by  WRITE_ONCE Waiman Long <waiman.long@hpe.com> - 2016-05-25 03:30 +0200

csiph-web