lkml.org 
[lkml]   [2008]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2] clarify usage expectations for cnt32_to_63()
    * Nicolas Pitre (nico@cam.org) wrote:
    > Currently, all existing users of cnt32_to_63() are fine since the CPU
    > architectures where it is used don't do read access reordering, and user
    > mode preemption is disabled already. It is nevertheless a good idea to
    > better elaborate usage requirements wrt preemption, and use an explicit
    > memory barrier on SMP to avoid different CPUs accessing the counter
    > value in the wrong order. On UP a simple compiler barrier is
    > sufficient.
    >
    > Signed-off-by: Nicolas Pitre <nico@marvell.com>
    > ---
    >
    ...
    > @@ -68,9 +77,10 @@ union cnt32_to_63 {
    > */
    > #define cnt32_to_63(cnt_lo) \
    > ({ \
    > - static volatile u32 __m_cnt_hi; \
    > + static u32 __m_cnt_hi; \

    It's important to get the smp_rmb() here, which this patch provides, so
    consider this patch to be acked-by me. The added documentation is needed
    too.

    But I also think that declaring the static u32 __m_cnt_hi here is
    counter-intuitive for developers who wish to use it.

    I'd recommend letting the declaration be done outside of cnt32_to_63 so
    the same variable can be passed as parameter to more than one execution
    site.

    Mathieu


    > union cnt32_to_63 __x; \
    > __x.hi = __m_cnt_hi; \
    > + smp_rmb(); \
    > __x.lo = (cnt_lo); \
    > if (unlikely((s32)(__x.hi ^ __x.lo) < 0)) \
    > __m_cnt_hi = __x.hi = (__x.hi ^ 0x80000000) + (__x.hi >> 31); \

    --
    Mathieu Desnoyers
    OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68


    \
     
     \ /
      Last update: 2008-11-09 07:51    [W:0.049 / U:0.856 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site