lkml.org 
[lkml]   [2007]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/24] make atomic_read() behave consistently across all architectures
Herbert Xu wrote:
> Chris Snook <csnook@redhat.com> wrote:
>> Because atomic operations are generally used for synchronization, which requires
>> volatile behavior. Most such codepaths currently use an inefficient barrier().
>> Some forget to and we get bugs, because people assume that atomic_read()
>> actually reads something, and atomic_write() actually writes something. Worse,
>> these are architecture-specific, even compiler version-specific bugs that are
>> often difficult to track down.
>
> I'm yet to see a single example from the current tree where
> this patch series is the correct solution. So far the only
> example has been a buggy piece of code which has since been
> fixed with a cpu_relax.

Part of the motivation here is to fix heisenbugs. If I knew where they
were, I'd be posting patches for them. Unlike most bugs, where we want
to expose them as obviously as possible, these can be extremely
difficult to track down, and are often due to people assuming that the
atomic_* operations have the same semantics they've historically had.
Remember that until recently, all SMP architectures except s390 (which
very few kernel developers outside of IBM, Red Hat, and SuSE do much
work on) had volatile declarations for atomic_t. Removing the volatile
declarations from i386 and x86_64 may have created heisenbugs that won't
manifest themselves until GCC 6.0 comes out and people start compiling
kernels with -O5. We should have consistent semantics for atomic_*
operations.

The other motivation is to reduce the need for the barriers used to
prevent/fix such problems which clobber all your registers, and instead
force atomic_* operations to behave in the way they're actually used.
After the (resubmitted) patchset is merged, we'll be able to remove a
whole bunch of barriers, shrinking our source and our binaries, and
improving performance.

-- Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-08-15 18:17    [W:1.718 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site