Re: [BLCR-ARM] swp/swpne ARMv7

PHHargrove_at_lbl_dot_gov

Alan,

    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 
CR_KCODE___kuser_cmpxchg.

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.

-Paul

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] https://bugs.launchpad.net/ubuntu/+source/blcr/+bug/503185
> _______________________________________________
> BLCR-ARM mailing list
> BLCR-ARM_at_hpcrdm_dot_lbl_dot_gov
> https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/blcr-arm
>   

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