Re: [GIT PULL] x86/atomic changes for v2.6.35

Re: [GIT PULL] x86/atomic changes for v2.6.35

[Geert Uytterhoeven]

On Tue, May 18, 2010 at 00:45, Ingo Molnar <mingo@elte.hu> wrote:
> Please pull the latest x86-atomic-for-linus git tree from:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-atomic-for-linus
>
>
> out-of-topic modifications in x86-atomic-for-linus:
> ---------------------------------------------------
> lib/Makefile                       # 86a8938: lib: Add self-test for atomic64_t
> lib/atomic64.c                     # 9757789: lib: Fix atomic64_add_unless retu
> lib/atomic64_test.c                # a5c9161: x86, atomic64: In selftest, disti
>                                   # 25a304f: lib: Fix atomic64_inc_not_zero te
>                                   # 9efbcd5: lib: Fix atomic64_add_unless test
>                                   # d7f6de1: x86: Implement atomic[64]_dec_if_
>                                   # 8f4f202: lib: Only test atomic64_dec_if_po
>                                   # 86a8938: lib: Add self-test for atomic64_t

Is having atomic64_t mandatory now?

According to the allmodconfig build logs
(http://kisskb.ellerman.id.au/kisskb/matrix/),
several architectures (at least m68k and mips) don't have it.
Furthermore, the test fails to compile on a few architectures that do have it
(parisc, s390, sh, ...).

<boilerplate>
It's a pity this wasn't raised/resolved between its detection in linux-next and
before it entered mainline...
</boilerplate>

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [GIT PULL] x86/atomic changes for v2.6.35

[H. Peter Anvin]

On 05/19/2010 04:46 AM, Geert Uytterhoeven wrote:
> On Tue, May 18, 2010 at 00:45, Ingo Molnar <mingo@elte.hu> wrote:
>> Please pull the latest x86-atomic-for-linus git tree from:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-atomic-for-linus
>>
>>
>> out-of-topic modifications in x86-atomic-for-linus:
>> ---------------------------------------------------
>> lib/Makefile                       # 86a8938: lib: Add self-test for atomic64_t
>> lib/atomic64.c                     # 9757789: lib: Fix atomic64_add_unless retu
>> lib/atomic64_test.c                # a5c9161: x86, atomic64: In selftest, disti
>>                                   # 25a304f: lib: Fix atomic64_inc_not_zero te
>>                                   # 9efbcd5: lib: Fix atomic64_add_unless test
>>                                   # d7f6de1: x86: Implement atomic[64]_dec_if_
>>                                   # 8f4f202: lib: Only test atomic64_dec_if_po
>>                                   # 86a8938: lib: Add self-test for atomic64_t
> 
> Is having atomic64_t mandatory now?
> 
> According to the allmodconfig build logs
> (http://kisskb.ellerman.id.au/kisskb/matrix/),
> several architectures (at least m68k and mips) don't have it.
> Furthermore, the test fails to compile on a few architectures that do have it
> (parisc, s390, sh, ...).
> 
> <boilerplate>
> It's a pity this wasn't raised/resolved between its detection in linux-next and
> before it entered mainline...
> </boilerplate>
> 

Is having atomic64_t mandatory?  Not yet, I don't think, but it probably
will be soon -- which is why there is a generic implementation
available.  All those architectures just need to select
CONFIG_GENERIC_ATOMIC64 and voilà, problem solved.

As far as your boilerplate is concerned, I think Linus made it clear at
the Kernel Summit that is it not the obligation of x86/ARM/PowerPC to
slow down to not break the smaller architectures; it's the
responsibility of those architecture maintainers to keep up.  Sorry.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [GIT PULL] x86/atomic changes for v2.6.35

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1074 bytes --]

Hi,

On Wed, 19 May 2010 07:24:00 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
>
> On 05/19/2010 04:46 AM, Geert Uytterhoeven wrote:
> > <boilerplate>
> > It's a pity this wasn't raised/resolved between its detection in linux-next and
> > before it entered mainline...
> > </boilerplate>
> 
> As far as your boilerplate is concerned, I think Linus made it clear at
> the Kernel Summit that is it not the obligation of x86/ARM/PowerPC to
> slow down to not break the smaller architectures; it's the
> responsibility of those architecture maintainers to keep up.  Sorry.

I don't think this reply has anything to do with the sentiments expressed
by Geert above.  My interpretation of his comments is just that it is a
pity noone noticed the problem while it was only in linux-next and
reported it widely (like on linux-arch) so something could have been done
before it all Linus' tree.  There was no suggestion of slowing the pace
of development.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [GIT PULL] x86/atomic changes for v2.6.35

[H. Peter Anvin]

On 05/19/2010 07:36 AM, Stephen Rothwell wrote:
> Hi,
> 
> On Wed, 19 May 2010 07:24:00 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
>>
>> On 05/19/2010 04:46 AM, Geert Uytterhoeven wrote:
>>> <boilerplate>
>>> It's a pity this wasn't raised/resolved between its detection in linux-next and
>>> before it entered mainline...
>>> </boilerplate>
>>
>> As far as your boilerplate is concerned, I think Linus made it clear at
>> the Kernel Summit that is it not the obligation of x86/ARM/PowerPC to
>> slow down to not break the smaller architectures; it's the
>> responsibility of those architecture maintainers to keep up.  Sorry.
> 
> I don't think this reply has anything to do with the sentiments expr
> by Geert above.  My interpretation of his comments is just that it is a
> pity noone noticed the problem while it was only in linux-next and
> reported it widely (like on linux-arch) so something could have been done
> before it all Linus' tree.  There was no suggestion of slowing the pace
> of development.

It was discussed on linux-kernel -- note that there is no breakage for
smaller architectures unless you enable the test directly or via randconfig.

The other part is that generic atomic64_t has been available since
middle of 2009, and was *also* discussed extensively on linux-kernel --
in fact, several of the smaller architectures added support at that
time.  That the breakage occurred because of an inconsequential test
rather than real code is thus really nothing but fortunate.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [GIT PULL] x86/atomic changes for v2.6.35

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]

On Wed, 19 May 2010 08:01:35 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
>
> It was discussed on linux-kernel -- note that there is no breakage for
> smaller architectures unless you enable the test directly or via randconfig.

or allmodconfig or allyesconfig.

> The other part is that generic atomic64_t has been available since
> middle of 2009, and was *also* discussed extensively on linux-kernel --
> in fact, several of the smaller architectures added support at that
> time.  That the breakage occurred because of an inconsequential test
> rather than real code is thus really nothing but fortunate.

I don't disagree with any of that (except that an m68k allmodconfig build
may well build fine without the test being built so maybe building the
test needs a dependency).

My point was that I keep hearing the "Linus said it is OK to break the
other architectures" argument brought up where it really is not even
relevant to the conversation.  If anything, I guess Geert was taking a
little dig at me because his problem should have been noticed among my
build results. Unfortunately even I don't check all the build results all
the time (I guess I hope that maintainers may have time to check them out
once in a while).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [GIT PULL] x86/atomic changes for v2.6.35

[Paul Mundt]

On Wed, May 19, 2010 at 07:24:00AM -0700, H. Peter Anvin wrote:
> On 05/19/2010 04:46 AM, Geert Uytterhoeven wrote:
> > On Tue, May 18, 2010 at 00:45, Ingo Molnar <mingo@elte.hu> wrote:
> >> Please pull the latest x86-atomic-for-linus git tree from:
> >>
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-atomic-for-linus
> >>
> >>
> >> out-of-topic modifications in x86-atomic-for-linus:
> >> ---------------------------------------------------
> >> lib/Makefile                       # 86a8938: lib: Add self-test for atomic64_t
> >> lib/atomic64.c                     # 9757789: lib: Fix atomic64_add_unless retu
> >> lib/atomic64_test.c                # a5c9161: x86, atomic64: In selftest, disti
> >>                                   # 25a304f: lib: Fix atomic64_inc_not_zero te
> >>                                   # 9efbcd5: lib: Fix atomic64_add_unless test
> >>                                   # d7f6de1: x86: Implement atomic[64]_dec_if_
> >>                                   # 8f4f202: lib: Only test atomic64_dec_if_po
> >>                                   # 86a8938: lib: Add self-test for atomic64_t
> > 
> > Is having atomic64_t mandatory now?
> > 
> > According to the allmodconfig build logs
> > (http://kisskb.ellerman.id.au/kisskb/matrix/),
> > several architectures (at least m68k and mips) don't have it.
> > Furthermore, the test fails to compile on a few architectures that do have it
> > (parisc, s390, sh, ...).
> > 
> > <boilerplate>
> > It's a pity this wasn't raised/resolved between its detection in linux-next and
> > before it entered mainline...
> > </boilerplate>
> > 
> 
> Is having atomic64_t mandatory?  Not yet, I don't think, but it probably
> will be soon -- which is why there is a generic implementation
> available.  All those architectures just need to select
> CONFIG_GENERIC_ATOMIC64 and voil??, problem solved.
> 
No, the problem isn't solved, you apparently overlooked the part of
Geert's mail that point out that the test fails to build on architecures
that _do_ have atomic64_t. All of arm/parisc/powerpc/sh select
GENERIC_ATOMIC64, suggesting that the test itself was only ever tested on
x86 and never on the generic implementation. While that may be par for
the course these days, it's still pretty poor form.

> As far as your boilerplate is concerned, I think Linus made it clear at
> the Kernel Summit that is it not the obligation of x86/ARM/PowerPC to
> slow down to not break the smaller architectures; it's the
> responsibility of those architecture maintainers to keep up.  Sorry.
> 
This keeping up thing gets thrown around a lot without any real basis.
Most of the GENERIC_ATOMIC64 architectures enabled support for it within
days of it being merged, if they've all been broken now because of an
x86-centric change then it's really not so much of a keeping up issue as
it is an issue of unreviewed and untested crap being merged before anyone
gets a chance to look at it.

The breakage in question isn't even related to the atomic64_t
implementation, it's just some trivial header stuff. It would be nice if
people would spend even a cursory amount of time looking in to these
things before throwing around tired generalizations of how everyone else
needs to "keep up".

Re: [GIT PULL] x86/atomic changes for v2.6.35

[H. Peter Anvin]

On 05/19/2010 09:18 AM, Paul Mundt wrote:
>
> No, the problem isn't solved, you apparently overlooked the part of
> Geert's mail that point out that the test fails to build on architecures
> that _do_ have atomic64_t. All of arm/parisc/powerpc/sh select
> GENERIC_ATOMIC64, suggesting that the test itself was only ever tested on
> x86 and never on the generic implementation. While that may be par for
> the course these days, it's still pretty poor form.
> 

I don't see any atomic64_t issues in the ARM, PowerPC or MIPS builds --
which doesn't mean they're not there, but if so they're obscured by
other errors.  m68k is missing #include <asm-generic/atomic64.h> in
<asm/atomic.h>, and SPARC64 and S390 seems to have issues due to missing
<linux/kernel.h> in atomic64_test.c; the latter is indeed a bug in the
test and yes, should be fixed.

	-hpa