linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lars-Peter Clausen <lars@metafoo.de>
To: Cosmin Tanislav <demonsingur@gmail.com>
Cc: cosmin.tanislav@analog.com,
	Michael Hennerich <Michael.Hennerich@analog.com>,
	Rob Herring <robh+dt@kernel.org>,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/2] Add ADXL367 driver
Date: Mon, 13 Dec 2021 12:34:19 +0100	[thread overview]
Message-ID: <fbf1bc12-5013-0b09-a6f4-a602f0afbe70@metafoo.de> (raw)
In-Reply-To: <20211207094337.59300-1-cosmin.tanislav@analog.com>

On 12/7/21 10:43 AM, Cosmin Tanislav wrote:
> I have one question that is not actually specific to this driver but would
> help me clear up some issues.
>
> I used mutex_lock and mutex_unlock when accessing anything in driver's
> state that could potentially be written by another process in parallel.
>
> I heard mixed opinions about this. Some people said that it is not
> necessary to lock everywhere because loads and stores for data with size
> smaller or equal than register size would be done in one single atomic
> instruction.
>
> On the other hand, I also heard that this is not true unless WRITE_ONCE
> and READ_ONCE is used.
>
> It felt weird using WRITE_ONCE and READ_ONCE in this driver, so I kept
> using mutexes.
>
> Could I get some opinions on this matter?

What you wrote sums it up very well. READ_ONCE/WRITE_ONCE are required 
for correctness when no lock is used. The compiler is allowed to do all 
sorts of optimizations that could break multi-threading, when 
READ_ONCE/WRITE_ONCE is not used. E.g.

if (x)
   foo->bar = 10;
else
   foo->bar = 20;

Could be implemented as

foo->bar = 20;
if (x)
   foo->bar = 10;

In the absence of multi-threading the result will be the same. But if 
another thread reads foo->bar just at the right time it will read the 
incorrect 20.

For simple things like `foo->bar = x;` it is unlikely that the compiler 
will do anything other than the single store. But it could and the code 
is not correct without the WRITE_ONCE.

Using a mutex is OK, since non of this is performance critical.

  parent reply	other threads:[~2021-12-13 11:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-07  9:43 [PATCH v2 0/2] Add ADXL367 driver Cosmin Tanislav
2021-12-07  9:43 ` [PATCH v2 1/2] dt-bindings: iio: accel: add ADXL367 Cosmin Tanislav
2021-12-15 15:54   ` Rob Herring
2021-12-07  9:43 ` [PATCH v2 2/2] iio: accel: add ADXL367 driver Cosmin Tanislav
2021-12-12 17:04   ` Jonathan Cameron
2021-12-12 19:25     ` Cosmin Tanislav
2021-12-16 12:15       ` Jonathan Cameron
2021-12-13 11:34 ` Lars-Peter Clausen [this message]
2021-12-14 15:50   ` [PATCH v2 0/2] Add " Sa, Nuno

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=fbf1bc12-5013-0b09-a6f4-a602f0afbe70@metafoo.de \
    --to=lars@metafoo.de \
    --cc=Michael.Hennerich@analog.com \
    --cc=cosmin.tanislav@analog.com \
    --cc=demonsingur@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).