From: Davidlohr Bueso <dave@stgolabs.net>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Manfred Spraul <manfred@colorfullife.com>,
LKML <linux-kernel@vger.kernel.org>,
Waiman Long <longman@redhat.com>,
1vier1@web.de, Andrew Morton <akpm@linux-foundation.org>,
Jonathan Corbet <corbet@lwn.net>,
parri.andrea@gmail.com
Subject: Re: [PATCH 6/6] Documentation/memory-barriers.txt: Clarify cmpxchg()
Date: Tue, 15 Oct 2019 09:26:18 -0700 [thread overview]
Message-ID: <20191015162618.prubsbu7xpou5n27@linux-p48b> (raw)
In-Reply-To: <20191015071959.GA2311@hirez.programming.kicks-ass.net>
On Tue, 15 Oct 2019, Peter Zijlstra wrote:
>On Mon, Oct 14, 2019 at 06:26:04PM -0700, Davidlohr Bueso wrote:
>> On Sat, 12 Oct 2019, Manfred Spraul wrote:
>> > Invalid would be:
>> > smp_mb__before_atomic();
>> > atomic_set();
>>
>> fyi I've caught a couple of naughty users:
>>
>> drivers/crypto/cavium/nitrox/nitrox_main.c
>> drivers/gpu/drm/msm/adreno/a5xx_preempt.c
>
>Yes, there's still some of that. Andrea went and killed a buch a while
>ago I think.
I sent these, which just does smp_mb():
https://lore.kernel.org/lkml/20191015161657.10760-1-dave@stgolabs.net
https://lore.kernel.org/lkml/20191015162144.fuyc25tdwvc6ddu3@linux-p48b
Similarly, I was doing some barrier auditing in btrfs code recently
(completely unrelated to these topics) and noted that there are some
cases where we can inverse this exercise. Iow, callers doing atomic
Rmw along with smp_mb(), which we can replace with these upgradable
calls and benefit, for example in x86.
Thanks,
Davidlohr
prev parent reply other threads:[~2019-10-15 16:27 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-12 5:49 [PATCH 0/6] V2: Clarify/standardize memory barriers for ipc Manfred Spraul
2019-10-12 5:49 ` [PATCH 1/6] wake_q: Cleanup + Documentation update Manfred Spraul
2019-10-14 6:34 ` Davidlohr Bueso
2019-10-14 12:04 ` Peter Zijlstra
2019-10-12 5:49 ` [PATCH 2/6] ipc/mqueue.c: Remove duplicated code Manfred Spraul
2019-10-14 6:35 ` Davidlohr Bueso
2019-10-14 12:37 ` Peter Zijlstra
2019-10-12 5:49 ` [PATCH 3/6] ipc/mqueue.c: Update/document memory barriers Manfred Spraul
2019-10-14 6:38 ` Davidlohr Bueso
2019-10-14 12:59 ` Peter Zijlstra
2019-10-14 13:58 ` Peter Zijlstra
2019-10-14 18:06 ` Manfred Spraul
2019-10-12 5:49 ` [PATCH 4/6] ipc/msg.c: Update and document " Manfred Spraul
2019-10-12 5:49 ` [PATCH 5/6] ipc/sem.c: Document and update " Manfred Spraul
2019-10-12 5:49 ` [PATCH 6/6] Documentation/memory-barriers.txt: Clarify cmpxchg() Manfred Spraul
2019-10-14 13:03 ` Peter Zijlstra
2019-10-14 17:49 ` Manfred Spraul
2019-10-14 19:03 ` Davidlohr Bueso
2019-10-15 7:45 ` Peter Zijlstra
2019-10-15 20:31 ` Waiman Long
2019-10-15 1:26 ` Davidlohr Bueso
2019-10-15 7:19 ` Peter Zijlstra
2019-10-15 16:26 ` Davidlohr Bueso [this message]
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=20191015162618.prubsbu7xpou5n27@linux-p48b \
--to=dave@stgolabs.net \
--cc=1vier1@web.de \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=manfred@colorfullife.com \
--cc=parri.andrea@gmail.com \
--cc=peterz@infradead.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