[PATCH 0/5] x86-32: improve atomic64_t functions (v2)
Luca Barbieri
- 386/486 is supported with a custom assembly implementation, the generic
implementation is no longer used/modified
- dropped SSE code
- changed CALL alternative code to use a custom alternative type:
insn parser no longer used
- several implementation improvements
- several formatting/style improvements
- merged 386 support into main patch
This patchset improves the atomic64_t functions on x86-32.
It also includes a testsuite that has been used to test this functionality
and can test any atomic64_t implementation.
It offers the following improvements:
1. Better code due to hand-written assembly (e.g. use of the ZF flag)
2. All atomic64 functions implemented
3. Support for 386/486 due to the ability to alternatively use either
the cmpxchg8b assembly implementation or the 386 cli/popf assembly one
The first patches add functionality to the alternatives system to support
the new atomic64_t code.
A patch that improves cmpxchg64() using that functionality is also included.
To test this code, enable CONFIG_ATOMIC64_SELFTEST, compile for 386 and
boot normally and with "clearcpuid=8".
You should receive a message stating that the atomic64 test passed,
along with the selected configuration.
386/486 SMP is not supported, following existing practice, but the code
is structured to allow to very easily add such support.
Signed-off-by: Luca Barbieri <lu...@luca-barbieri.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
H. Peter Anvin
I wonder if I could ask you to recreate your patchset on top of the
x86/asm branch in the -tip tree. There are some nontrivial changes to
the alternatives mechanism, plus a restructuring of the atomic headers
which both conflict with this patchset.
The -tip tree is available from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
Luca Barbieri
> x86/asm branch in the -tip tree.
Done, resent.
Ingo Molnar
* Luca Barbieri <lu...@luca-barbieri.com> wrote:
> > I wonder if I could ask you to recreate your patchset on top of the
> > x86/asm branch in the -tip tree.
>
> Done, resent.
FYI, it triggered build failures in -tip testing:
lib/atomic64_test.c: In function 'test_atomic64':
lib/atomic64_test.c:116: error: implicit declaration of function 'atomic64_dec_if_positive'
Ingo
Luca Barbieri
>
> lib/atomic64_test.c: In function 'test_atomic64':
> lib/atomic64_test.c:116: error: implicit declaration of function 'atomic64_dec_if_positive'
This was on x86-64 right?
That function is implemented in the generic atomic64 implementation
and my x86-32 version, but not in the x86-64 implementation.
There is a similar problem with the 32-bt atomic_dec_if_positive, that
is implemented by ppc, mips, microblaze and avr32 but not in x86-32
and asm-generic.
Currently the 64-bit version seems unused, while the 32-bit one seems
to be only used by ppc-only drivers (IBM pSeries virtual SCSI and
PlayStation3 drivers).
I'll send a couple of patches to fix this shortly.
Luca Barbieri
functions for x86 and x86-64.
H. Peter Anvin
> Sent patches, both to conditionally perform the test and implement the
> functions for x86 and x86-64.
Yes, and with the test turned on, the kernel crashes immediately on boot
on x86-64.
Some minor investigation reveals the following:
lib/atomic64.c has the wrong return value for atomic64_add_unless().
With "wrong" I mean it is the opposite sense compared to
atomic_add_unless(), not just on x86 but on all architectures.
Accordingly, I have to conclude that lib/atomic64.c is buggy, and that
since your test matches that bug, I will have to conclude that your
x86-32 implementation is also buggy. Thus, please send patches to fix
your test and your 32-bit implementations (and preferrably
lib/atomic64.c too, but I can do that just fine.)
Cc: Paul Mackerras who did the generic atomic64_t implementation for
verification that this is indeed a bug.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
Paul Mackerras
> On 02/26/2010 03:23 AM, Luca Barbieri wrote:
> > Sent patches, both to conditionally perform the test and implement the
> > functions for x86 and x86-64.
>
> Yes, and with the test turned on, the kernel crashes immediately on boot
> on x86-64.
>
> Some minor investigation reveals the following:
>
> lib/atomic64.c has the wrong return value for atomic64_add_unless().
> With "wrong" I mean it is the opposite sense compared to
> atomic_add_unless(), not just on x86 but on all architectures.
>
> Accordingly, I have to conclude that lib/atomic64.c is buggy, and that
> since your test matches that bug, I will have to conclude that your
> x86-32 implementation is also buggy. Thus, please send patches to fix
> your test and your 32-bit implementations (and preferrably
> lib/atomic64.c too, but I can do that just fine.)
>
> Cc: Paul Mackerras who did the generic atomic64_t implementation for
> verification that this is indeed a bug.
Yes, it sure looks like it. *blush*
Paul.
Luca Barbieri
> on x86-64.
>
> Some minor investigation reveals the following:
>
> lib/atomic64.c has the wrong return value for atomic64_add_unless().
> With "wrong" I mean it is the opposite sense compared to
> atomic_add_unless(), not just on x86 but on all architectures.
>
> Accordingly, I have to conclude that lib/atomic64.c is buggy, and that
> since your test matches that bug, I will have to conclude that your
> x86-32 implementation is also buggy. �Thus, please send patches to fix
> your test and your 32-bit implementations (and preferrably
> lib/atomic64.c too, but I can do that just fine.)
You are right: sent a patchset to fix it.
Luca Barbieri
The generic implementation implements it in terms of
atomic64_add_unless and thus does not need a specific fix for it.
Sent another patchset to fix that.