[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <p2gb647ffbd1004080927r6079414dof04ef128d8ff3bfd@mail.gmail.com>
Date: Thu, 8 Apr 2010 18:27:41 +0200
From: Dmitry Adamushko <dmitry.adamushko@...il.com>
To: Jason Wessel <jason.wessel@...driver.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
kgdb-bugreport@...ts.sourceforge.net,
Will Deacon <will.deacon@....com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Russell King - ARM Linux <linux@....linux.org.uk>,
linux-arm@...r.kernel.org
Subject: Re: [Kgdb-bugreport] [PATCH 4/5] kgdb: Use atomic operators whichuse
barriers
> ---
> From: Jason Wessel <jason.wessel@...driver.com>
> Subject: [PATCH] kgdb: use atomic_inc and atomic_dec instead of atomic_set
>
> Memory barriers should be used for the kgdb cpu synchronization. The
> atomic_set() does not imply a memory barrier.
Hmm, but as far as I can see [ Documentation/memory-barriers.txt and
some actual implementations of atomic_inc/dec() ] atomic_inc/dec()
does not imply memory barriers either.
Either I'm missing the real point of this change and the very category
of "memory barriers" bears another meaning here or the following piece
looks especially dubious...
[...]
* Make sure the above info reaches the primary CPU before
* our cpu_in_kgdb[] flag setting does:
*/
- smp_wmb();
- atomic_set(&cpu_in_kgdb[cpu], 1);
+ atomic_inc(&cpu_in_kgdb[cpu]);
so what ensures the "Make sure the above info reaches..." requirement here?
TIA,
-- Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists