Re: [BLCR-ARM] swp/swpne ARMv7

From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Tue Jan 05 2010 - 08:16:53 PST

  • Next message: Alan Woodland: "Re: [BLCR-ARM] swp/swpne ARMv7"
        I believe you are mistaken in reading the comments to imply "we 
    shouldn['t] be using __kernel_cmpxchg on newer kernels anyway".   That 
    feature became available in 2.6.12 and before that there was no way to 
    perform an atomic operation from user code w/ pre-ARMv6 hardware.  Since 
    2.6.12 this has been the portable way to get an atomic C-A-S.  If there 
    is specific misleading text in the comment, please show me and I'll 
    fix/clarify it.
      You ARE correct that CR_KCODE___kuser_cmpxchg is not defined at build 
    time IF one does separate configuration as the debian packaging 
    apparently does.  That possibility was not considered when this code was 
    first written, and is the root cause of your problem.  One should always 
    be in CR_KCODE___kuser_cmpxchg case for a kernel >= 2.6.12.
      It was my intention that the swp/swpne code only be used for kernel < 
    2.6.12, but probing the kernel for __kuser_cmpxchg was chosen to be a 
    more reliable probe (a distro could back port the feature to an older 
    base kernel version).  The fact that you reach this code is because the 
    separate user/kernel builds have resulted in not probing for 
    If one were to refuse to build for a kernel w/o this feature, then the
       #if defined(CR_KCODE___kuser_cmpxchg)
    would/could effectively become equivalent to
       #if 1
    since a userspace built w/o a corresponding kernel module is "harmless".
      So, I believe the solution to your problem is to force use of the 
    __kuser_cmpxchg path and require (via packaging magic?) that one have 
    kernel >= 2.6.12.
      I am open to suggestions as to how to deal in general with building 
    the ARMuser space w/o configuring the kernel module, while still 
    allowing for the possibility of a pre-2.6.12 kernel.  I am not certain 
    that disallowing pre-2.6.12 kernels would be popular in the ARM community.
      In response to your #2: one COULD write an additional #if case to use 
    ldrex/strex for ARMv6 and ARMv7.  This would gain some efficiency in 
    exchange for portability to older CPUs, but I lack a platform to test 
    correctness of such an implementation.
    Alan Woodland wrote:
    > Hi,
    > I noticed today that BLCR is failing to build on armel on Ubuntu. This
    > problem is reported in [1]. It would seem that ARMv7 no longer
    > includes swp/swpne instructions. It's relatively trivial to
    > conditionally replace this with appropriate ldrex/strex instructions
    > instead though. Before I produce a patch though I have a few
    > questions:
    > 1) CR_KCODE___kuser_cmpxchg clearly isn't defined at build time here.
    > The test doesn't get run because we're only building userspace parts
    > at this point. Is that correct? Are we always expecting to be in the
    > #else oflibcr/arch/arm/cr_atomic.h when building userspace bits? I
    > can't help but feel I've missed something in my reading of this
    > somehow though.
    > 2) Is a 2nd alternative for
    > cri_atomic_inc/cri_atomic_dec_and_test/cri_cmp_swap the correct way to
    > fix this? The comments in the source seem to suggest that using
    > ldrex/strex would be correct and better where they exist. They also
    > imply that we shouldn be using __kernel_cmpxchg on newer kernels
    > anyway though.
    > Thanks,
    > Alan
    > [1]
    > _______________________________________________
    > BLCR-ARM mailing list
    > BLCR-ARM_at_hpcrdm_dot_lbl_dot_gov
    Paul H. Hargrove                          PHHargrove_at_lbl_dot_gov
    Future Technologies Group                 Tel: +1-510-495-2352
    HPC Research Department                   Fax: +1-510-486-6900
    Lawrence Berkeley National Laboratory     

  • Next message: Alan Woodland: "Re: [BLCR-ARM] swp/swpne ARMv7"