Re: [Patch 0/10]: Cleanup online reservations for 2.6.9-rc2-mm4.

From: Stephen C. Tweedie (sct_at_redhat.com)
Date: 09/30/04

  • Next message: Bagalkote, Sreenivas: "[RESEND][PATCH]: megaraid 2.20.4: Fixes a data corruption bug"
    To: Manfred Spraul <manfred@colorfullife.com>
    Date:	30 Sep 2004 18:04:47 +0100
    
    

    Hi,

    On Thu, 2004-09-30 at 17:00, Manfred Spraul wrote:

    > >Locking
    > >is minimised: the impact on the hot path consists of nothing more than
    > >an smp_rmb() before we test sb->s_groups_count. That's a noop on x86,
    > >
    > No, wrong way around:
    > wmb() is empty. rmb() is either lfence or a locked dummy instruction.

    Hmm. But I'm still not sure we can get away with anything
    lighter-weight.

    The basic construct we need to worry about is:

            new_group_table = kmalloc(...);
            memcpy(new_group_table, old_group_table);
            new_group_table[new_group] = foo;
            sbi->s_group_desc = new_group_table;
            /* SMP WRITE BARRIER */
            sbi->s_group_count = new_group_count;

    on the writer side, and

            ngroups = sbi->s_group_count;
            /* SMP READ BARRIER */
            for (i = 0; i < ngroups; i++)
                    gdp = sbi->s_group_desc[i];

    The latter is the worry --- we're doing a read that depends immediately
    on "i" and s_group_desc, but not on sbi->s_group_count. There *IS* a
    comparison between i and s_group_count, though, so the dependency is
    implicit.

    I'm just not familiar enough with the architecture of weakly-ordered
    platforms to know if we can get away with smp_read_barrier_depends() in
    this particular case. If so, we can use that and be done with the extra
    locked op on x86.

    --Stephen

    -
    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/


  • Next message: Bagalkote, Sreenivas: "[RESEND][PATCH]: megaraid 2.20.4: Fixes a data corruption bug"

    Relevant Pages

    • Re: why swap at all?
      ... > Hmm.. ... do we need to worry about the same DoS issues we need to worry about with ... and the even more dangerous half-clued users. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Nvidia drivers and 2.6.x kernel
      ... Works a charm. ... Hmm ... ... that does worry me a little then ... ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)