[lkml]   [2007]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/24] make atomic_read() behave consistently across all architectures

    On Mon, 10 Sep 2007, Denys Vlasenko wrote:
    > static inline int
    > qla2x00_wait_for_loop_ready(scsi_qla_host_t *ha)
    > {
    > int return_status = QLA_SUCCESS;
    > unsigned long loop_timeout ;
    > scsi_qla_host_t *pha = to_qla_parent(ha);
    > /* wait for 5 min at the max for loop to be ready */
    > loop_timeout = jiffies + (MAX_LOOP_TIMEOUT * HZ);
    > while ((!atomic_read(&pha->loop_down_timer) &&
    > atomic_read(&pha->loop_state) == LOOP_DOWN) ||
    > atomic_read(&pha->loop_state) != LOOP_READY) {
    > if (atomic_read(&pha->loop_state) == LOOP_DEAD) {
    > Is above correct or buggy? Correct, because msleep is a barrier.
    > Is it obvious? No.

    It's *buggy*. But it has nothing to do with any msleep() in the loop, or
    anything else.

    And more importantly, it would be equally buggy even *with* a "volatile"

    Why is this so hard for people to understand? You're all acting like

    The reason it is buggy has absolutely nothing to do with whether the read
    is done or not, it has to do with the fact that the CPU may re-order the
    reads *regardless* of whether the read is done in some specific order by
    the compiler ot not! In effect, there is zero ordering between all those
    three reads, and if you don't have memory barriers (or a lock or other
    serialization), that code is buggy.

    So stop this idiotic discussion thread already. The above kind of code
    needs memory barriers to be non-buggy. The whole "volatile or not"
    discussion is totally idiotic, and pointless, and anybody who doesn't
    understand that by now needs to just shut up and think about it more,
    rather than make this discussion drag out even further.

    The fact is, "volatile" *only* makes things worse. It generates worse
    code, and never fixes any real bugs. This is a *fact*.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-09-10 17:15    [W:0.020 / U:7.748 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site