linux-kernel - Re: 2.6.25.X-rtX compile errors on ARM due to cmpxchg() problems.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Wed, 16 Jul 2008 20:36:53 +0200
From:	"Remy Bohmer" <linux@...mer.net>
To:	"Steven Rostedt" <rostedt@...dmis.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	RT <linux-rt-users@...r.kernel.org>, lvcargnini@...il.com,
	"Thomas Gleixner" <tglx@...utronix.de>
Subject: Re: 2.6.25.X-rtX compile errors on ARM due to cmpxchg() problems.

Hello Steven,

A while ago I already mentioned that 2.6.25 did not compile on ARM.
(e.g. AT91SAM9261-EK)
Today I looked at it again with the latest 2.6.25 kernel with latest RT-patch.

Several errors are gone, but I still I get these warnings on every
file that is being compiled:
-----------------------------------------------------------------
  CC      arch/arm/kernel/asm-offsets.s
In file included from include/linux/rt_lock.h:14,
                 from include/linux/spinlock.h:117,
                 from include/linux/seqlock.h:29,
                 from include/linux/time.h:8,
                 from include/linux/timex.h:57,
                 from include/linux/sched.h:54,
                 from arch/arm/kernel/asm-offsets.c:13:
include/asm/atomic.h:241:1: warning: "cmpxchg" redefined
In file included from include/asm/system.h:378,
                 from include/asm/bitops.h:27,
                 from include/linux/bitops.h:17,
                 from include/linux/kernel.h:15,
                 from include/linux/sched.h:52,
                 from arch/arm/kernel/asm-offsets.c:13:
include/asm-generic/cmpxchg.h:19:1: warning: this is the location of
the previous definition
...
and many more...
...
-----------------------------------------------------------------

I looked at the broken-out series which patches are causing these
warnings and these are the offending patches:
* arm-fix-atomic-cmpxchg.patch
* arm-cmpxchg.patch

When these patches are removed from the Preempt-RT patchset everything
compiles again, without warnings.

But these patches are probably there for a reason, and leaving them
out could break some things. (Although I believe that these patches
are just there because they apply on 2.6.25-RT)

But, Here I need some (RT-mutex-expert) review help.

Because this ARM architecture (ARM <= V5) does not have a real
cmpxchg() assembler
instruction, and the implementation is almost the same as the generic
definition, the generic definition can be used instead.
However, The generic implementation does NOT define __HAVE_ARCH_CMPXCHG.

My questions are:
* What are the results of NOT defining  __HAVE_ARCH_CMPXCHG in
kernel/rtmutex.c ?
* Does the RT-mutex still behave correctly?
* Why is this check in rtmutex.c ? Is it really needed, because there
is always a generic implementation of cmpxchg() these days?

FURTHER: The patch arm-fix-atomic-cmpxchg.patch made the
local_irq_save() a raw_local_irq_save().
Looking at the generic implementation I believe that this code should
also use the raw_* types. I attached a new patch for this to this
mail.

So, attached 3 patches:
* revert-arm-fix-atomic-cmpxchg.patch (reverts the same named patch in
preempt-RT set)
* revert-arm-cmpxchg.patch (reverts the same named patch in preempt-RT set)
* make-generic-cmpxchg-use-raw-intlock-types.patch

Can you clear some things up here? And also repair the RT-patch for
ARM and 2.6.25 ;-) (and newer)

Kind regards,

Remy

View attachment "make-generic-cmpxchg-use-raw-intlock-types.patch" of type "text/x-patch" (1345 bytes)

View attachment "revert-arm-cmpxchg.patch" of type "text/x-patch" (2401 bytes)

View attachment "revert-arm-fix-atomic-cmpxchg.patch" of type "text/x-patch" (1015 bytes)