[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191015162618.prubsbu7xpou5n27@linux-p48b>
Date: Tue, 15 Oct 2019 09:26:18 -0700
From: Davidlohr Bueso <dave@...olabs.net>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Manfred Spraul <manfred@...orfullife.com>,
LKML <linux-kernel@...r.kernel.org>,
Waiman Long <longman@...hat.com>, 1vier1@....de,
Andrew Morton <akpm@...ux-foundation.org>,
Jonathan Corbet <corbet@....net>, parri.andrea@...il.com
Subject: Re: [PATCH 6/6] Documentation/memory-barriers.txt: Clarify cmpxchg()
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
Powered by blists - more mailing lists