On Sun, Aug 03, 2014 at 12:01:17AM -0400, Pranith Kumar wrote:
> Also dm_cblock_t is uint32_t, but atomic_t changes that to int. You
> should correct that to atomic64_t to preserve original semantics.
atomic_t used to have only 24 bits of range due to the Sparc
implementation holding a lock in one of the bytes. I understand this
limitation was removed during 2.6 and the full 32 bits are now
available.
eg,
https://github.com/jthornber/linux-2.6/commit/37682177af68478fa83429b735fa16913c2fbb2b
> These increments and decrements will still be lost if you do not use
> barriers in presence of concurrent accesses. Please see
> Documentation/memory-barriers.txt.
You do not need to use barriers for plain atomic_inc/dec().
https://github.com/jthornber/linux-2.6/blob/thin-dev/Documentation/atomic_ops.txt#L187
You _do_ need to use a memory barrier for the ops that return a value
(such as atomic_dec_and_test()), But only if there's some other state
that needs synchronising. See the nice example in atomic_ops.txt:
https://github.com/jthornber/linux-2.6/blob/thin-dev/Documentation/atomic_ops.txt#L321
We just trigger a stateless event when the counter hits zero, so the
patch is fine.
- Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
