On 10/14/19 1:49 PM, Manfred Spraul wrote:
> Hello Peter,
>
> On 10/14/19 3:03 PM, Peter Zijlstra wrote:
>> On Sat, Oct 12, 2019 at 07:49:58AM +0200, Manfred Spraul wrote:
>>> The documentation in memory-barriers.txt claims that
>>> smp_mb__{before,after}_atomic() are for atomic ops that do not
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:
On Mon, Oct 14, 2019 at 07:49:56PM +0200, Manfred Spraul wrote:
> From 61c85a56994e32ea393af9debef4cccd9cd24abd Mon Sep 17 00:00:00 2001
> From: Manfred Spraul
> Date: Fri, 11 Oct 2019 10:33:26 +0200
> Subject: [PATCH] Update Documentation for _{acquire|release|relaxed}()
>
> When adding the
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
>
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
Thanks,
Davidlohr
On Mon, 14 Oct 2019, Manfred Spraul wrote:
I've updated the Change description accordingly
I continue to think my memory-barriers.txt change regarding failed
Rmw is still good to have. Unless any strong objections, could you
also add the patch to the series?
Thanks,
Davidlohr
Hello Peter,
On 10/14/19 3:03 PM, Peter Zijlstra wrote:
On Sat, Oct 12, 2019 at 07:49:58AM +0200, Manfred Spraul wrote:
The documentation in memory-barriers.txt claims that
smp_mb__{before,after}_atomic() are for atomic ops that do not return a
value.
This is misleading and doesn't match the
On Sat, Oct 12, 2019 at 07:49:58AM +0200, Manfred Spraul wrote:
> The documentation in memory-barriers.txt claims that
> smp_mb__{before,after}_atomic() are for atomic ops that do not return a
> value.
>
> This is misleading and doesn't match the example in atomic_t.txt,
> and e.g.
The documentation in memory-barriers.txt claims that
smp_mb__{before,after}_atomic() are for atomic ops that do not return a
value.
This is misleading and doesn't match the example in atomic_t.txt,
and e.g. smp_mb__before_atomic() may and is used together with
cmpxchg_relaxed() in the wake_q
9 matches
Mail list logo
