Mailing List Archive: Linux: Kernel

PREEMPT_ACTIVE too low error with all asm-generic headers for some arches

Index | Next | Previous | View Threaded

vapier.adi at gmail

Jun 23, 2009, 3:08 PM

Post #1 of 9 (329 views)
Permalink

PREEMPT_ACTIVE too low error with all asm-generic headers for some arches

after pulling the latest mainline code, Blackfin started hitting a
build failure like so:
CC arch/blackfin/kernel/asm-offsets.s
In file included from include/linux/interrupt.h:12,
from include/linux/kernel_stat.h:8,
from arch/blackfin/kernel/asm-offsets.c:32:
include/linux/hardirq.h:66:2: error: #error PREEMPT_ACTIVE is too low!
make[1]: *** [arch/blackfin/kernel/asm-offsets.s] Error 1

this is because we've converted to asm-generic for most of our headers
(including hardirq.h). originally we were defining HARDIRQ_BITS
ourselves to 8, but then we dropped that in favor of the
asm-generic/hardirq.h which setup a default of 8. but then they
dropped it in favor of the linux/hardirq.h default handling ... but it
sets it to MAX_HARDIRQ_BITS by default which is 10. which pushes
Blackfin over the edge and into this build error.

if we look at linux/hardirq.h, it makes this claim:
* - bit 28 is the PREEMPT_ACTIVE flag
if that's true, then why are we letting any arch set this define ? a
quick survey shows that half the arches (11) are using 0x10000000 (bit
28) while the other half (10) are using 0x4000000 (bit 26). and then
there is the ia64 oddity which uses bit 30. the exact value here
shouldnt really matter across arches though should it ?

how about adding this to linux/thread_info.h:
#ifndef PREEMPT_ACTIVE
# ifndef PREEMPT_ACTIVE_BIT
# define PREEMPT_ACTIVE_BIT 28
# endif
# define PREEMPT_ACTIVE (1 << PREEMPT_ACTIVE_BIT)
#endif
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

mingo at elte

Jun 24, 2009, 6:13 AM

Post #2 of 9 (306 views)
Permalink

Re: PREEMPT_ACTIVE too low error with all asm-generic headers for some arches [In reply to]

* Mike Frysinger <vapier.adi [at] gmail> wrote:

> after pulling the latest mainline code, Blackfin started hitting a
> build failure like so:
> CC arch/blackfin/kernel/asm-offsets.s
> In file included from include/linux/interrupt.h:12,
> from include/linux/kernel_stat.h:8,
> from arch/blackfin/kernel/asm-offsets.c:32:
> include/linux/hardirq.h:66:2: error: #error PREEMPT_ACTIVE is too low!
> make[1]: *** [arch/blackfin/kernel/asm-offsets.s] Error 1
>
> this is because we've converted to asm-generic for most of our headers
> (including hardirq.h). originally we were defining HARDIRQ_BITS
> ourselves to 8, but then we dropped that in favor of the
> asm-generic/hardirq.h which setup a default of 8. but then they
> dropped it in favor of the linux/hardirq.h default handling ... but it
> sets it to MAX_HARDIRQ_BITS by default which is 10. which pushes
> Blackfin over the edge and into this build error.

hm, you wrote this mail to me but i havent touched asm-generic nor
blackfin in this cycle. The breakage appears to have been caused by
or at around this commit:

From 804387a1af87f66a4b93eee230ba98f8b906b088 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd [at] arndb>
Date: Sun, 14 Jun 2009 22:38:11 +0200
Subject: [PATCH] asm-generic: drop HARDIRQ_BITS definition from hardirq.h

[...]

Reported-by: Mike Frysinger <vapier [at] gentoo>
Acked-by: Steven Rostedt <rostedt [at] goodmis>
Signed-off-by: Arnd Bergmann <arnd [at] arndb>

So i've Cc:-ed those folks too.

> if we look at linux/hardirq.h, it makes this claim:
> * - bit 28 is the PREEMPT_ACTIVE flag
> if that's true, then why are we letting any arch set this define ? a
> quick survey shows that half the arches (11) are using 0x10000000 (bit
> 28) while the other half (10) are using 0x4000000 (bit 26). and then
> there is the ia64 oddity which uses bit 30. the exact value here
> shouldnt really matter across arches though should it ?

Correct - what matters is to have no collision between the fields.

> how about adding this to linux/thread_info.h:
> #ifndef PREEMPT_ACTIVE
> # ifndef PREEMPT_ACTIVE_BIT
> # define PREEMPT_ACTIVE_BIT 28
> # endif
> # define PREEMPT_ACTIVE (1 << PREEMPT_ACTIVE_BIT)
> #endif

Makes sense i guess - but do we really need that level of
#ifdef nesting? PREEMPT_ACTIVE_BIT should be the main control - with
a default to 28 if it's not set. PREEMPT_ACTIVE is then derived off
that, without any #ifdefs.

Anyway ... no objections from me in this area (and your build is
broken so i suspect you want a fix quickly), just please make the
override clean. Btw., why cannot blackfin use the defaults?

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

vapier.adi at gmail

Jun 24, 2009, 6:22 AM

Post #3 of 9 (303 views)
Permalink

Re: PREEMPT_ACTIVE too low error with all asm-generic headers for some arches [In reply to]

On Wed, Jun 24, 2009 at 09:13, Ingo Molnar wrote:
> * Mike Frysinger <vapier.adi [at] gmail> wrote:
>> after pulling the latest mainline code, Blackfin started hitting a
>> build failure like so:
>> CC arch/blackfin/kernel/asm-offsets.s
>> In file included from include/linux/interrupt.h:12,
>> from include/linux/kernel_stat.h:8,
>> from arch/blackfin/kernel/asm-offsets.c:32:
>> include/linux/hardirq.h:66:2: error: #error PREEMPT_ACTIVE is too low!
>> make[1]: *** [arch/blackfin/kernel/asm-offsets.s] Error 1
>>
>> this is because we've converted to asm-generic for most of our headers
>> (including hardirq.h). originally we were defining HARDIRQ_BITS
>> ourselves to 8, but then we dropped that in favor of the
>> asm-generic/hardirq.h which setup a default of 8. but then they
>> dropped it in favor of the linux/hardirq.h default handling ... but it
>> sets it to MAX_HARDIRQ_BITS by default which is 10. which pushes
>> Blackfin over the edge and into this build error.
>
> hm, you wrote this mail to me but i havent touched asm-generic nor
> blackfin in this cycle.

i didnt say you did. you seemed to be the guy who would know about
sane values in hardirq/preempt, i was merely giving background on what
lead me here -- those changes arent wrong in any way.

>> if we look at linux/hardirq.h, it makes this claim:
>> * - bit 28 is the PREEMPT_ACTIVE flag
>> if that's true, then why are we letting any arch set this define ? a
>> quick survey shows that half the arches (11) are using 0x10000000 (bit
>> 28) while the other half (10) are using 0x4000000 (bit 26). and then
>> there is the ia64 oddity which uses bit 30. the exact value here
>> shouldnt really matter across arches though should it ?
>
> Correct - what matters is to have no collision between the fields.
>
>> how about adding this to linux/thread_info.h:
>> #ifndef PREEMPT_ACTIVE
>> # ifndef PREEMPT_ACTIVE_BIT
>> # define PREEMPT_ACTIVE_BIT 28
>> # endif
>> # define PREEMPT_ACTIVE (1 << PREEMPT_ACTIVE_BIT)
>> #endif
>
> Makes sense i guess - but do we really need that level of
> #ifdef nesting? PREEMPT_ACTIVE_BIT should be the main control - with
> a default to 28 if it's not set. PREEMPT_ACTIVE is then derived off
> that, without any #ifdefs.

well, i didnt want to write it like so:
#ifndef PREEMPT_ACTIVE_BIT
# define PREEMPT_ACTIVE_BIT 28
#endif
#ifndef PREEMPT_ACTIVE
# define PREEMPT_ACTIVE (1 << PREEMPT_ACTIVE_BIT)
#endif

because if the arch has defined PREEMPT_ACTIVE but not
PREEMPT_ACTIVE_BIT, then things could go bad. since the only consumer
of PREEMPT_ACTIVE_BIT that i can see is one ia64 assembly file, we can
just avoid the indirection. i wanted to make it clear that this is
indeed defaulting to bit 28 like the comments in hardirq.h say. i
also wanted to avoid having to change any arch files other than my own
(i.e. allow people to be grandfathered in).

i guess we can reformat it as:
#ifndef PREEMPT_ACTIVE_BIT
# define PREEMPT_ACTIVE_BIT 28
#endif
#define PREEMPT_ACTIVE (1 << PREEMPT_ACTIVE_BIT)
which makes me do the footwork of converting everyone over to PREEMPT_ACTIVE_BIT

> Anyway ... no objections from me in this area (and your build is
> broken so i suspect you want a fix quickly), just please make the
> override clean. Btw., why cannot blackfin use the defaults?

Blackfin is using the defaults. the issue i pointed out is that the
defaults set up 10 hardirq bits which ultimately conflict with any
arch (and there are 10 of them) that is using bit 26 for
PREEMPT_ACTIVE. there is no default value for PREEMPT_ACTIVE (yet).
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

arnd at arndb

Jun 24, 2009, 7:02 AM

Post #4 of 9 (308 views)
Permalink

Re: PREEMPT_ACTIVE too low error with all asm-generic headers for some arches [In reply to]

On Wednesday 24 June 2009, Ingo Molnar wrote:
> * Mike Frysinger <vapier.adi [at] gmail> wrote:
>
> > if we look at linux/hardirq.h, it makes this claim:
> > * - bit 28 is the PREEMPT_ACTIVE flag
> > if that's true, then why are we letting any arch set this define ? a
> > quick survey shows that half the arches (11) are using 0x10000000 (bit
> > 28) while the other half (10) are using 0x4000000 (bit 26). and then
> > there is the ia64 oddity which uses bit 30. the exact value here
> > shouldnt really matter across arches though should it ?

actually alpha, arm and avr32 also use bit 30 (0x40000000), there are only
five (or eight, depending on how you count) architectures (blackfin, h8300,
m68k, s390 and sparc) using bit 26.

> Correct - what matters is to have no collision between the fields.
>
> > how about adding this to linux/thread_info.h:
> > #ifndef PREEMPT_ACTIVE
> > # ifndef PREEMPT_ACTIVE_BIT
> > # define PREEMPT_ACTIVE_BIT 28
> > # endif
> > # define PREEMPT_ACTIVE (1 << PREEMPT_ACTIVE_BIT)
> > #endif
>
> Makes sense i guess - but do we really need that level of
> #ifdef nesting? PREEMPT_ACTIVE_BIT should be the main control - with
> a default to 28 if it's not set. PREEMPT_ACTIVE is then derived off
> that, without any #ifdefs.

I think it would fit better into linux/hardirq.h instead of
linux/thread_info.h, because that is where the other bits of
the preempt count are defined.

How would this one work out?

Signed-off-by: Arnd Bergmann <arnd [at] arndb>

--- a/include/linux/hardirq.h
+++ b/include/linux/hardirq.h
@@ -62,6 +62,12 @@
#define HARDIRQ_OFFSET (1UL << HARDIRQ_SHIFT)
#define NMI_OFFSET (1UL << NMI_SHIFT)

+#ifndef PREEMPT_ACTIVE
+#define PREEMPT_ACTIVE_BITS 1
+#define PREEMPT_ACTIVE_SHIFT (NMI_SHIFT + NMI_BITS)
+#define PREEMPT_ACTIVE (__IRQ_MASK(PREEMPT_ACTIVE_BITS) << PREEMPT_SHIFT)
+#endif
+
#if PREEMPT_ACTIVE < (1 << (NMI_SHIFT + NMI_BITS))
#error PREEMPT_ACTIVE is too low!
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

vapier.adi at gmail

Jun 24, 2009, 8:02 AM

Post #5 of 9 (302 views)
Permalink

Re: PREEMPT_ACTIVE too low error with all asm-generic headers for some arches [In reply to]

On Wed, Jun 24, 2009 at 10:02, Arnd Bergmann wrote:
> On Wednesday 24 June 2009, Ingo Molnar wrote:
>> * Mike Frysinger <vapier.adi [at] gmail> wrote:
>> > if we look at linux/hardirq.h, it makes this claim:
>> > * - bit 28 is the PREEMPT_ACTIVE flag
>> > if that's true, then why are we letting any arch set this define ? a
>> > quick survey shows that half the arches (11) are using 0x10000000 (bit
>> > 28) while the other half (10) are using 0x4000000 (bit 26). and then
>> > there is the ia64 oddity which uses bit 30. the exact value here
>> > shouldnt really matter across arches though should it ?
>
> actually alpha, arm and avr32 also use bit 30 (0x40000000), there are only
> five (or eight, depending on how you count) architectures (blackfin, h8300,
> m68k, s390 and sparc) using bit 26.

meh, too many zeros ;)

>> Correct - what matters is to have no collision between the fields.
>>
>> > how about adding this to linux/thread_info.h:
>> > #ifndef PREEMPT_ACTIVE
>> > # ifndef PREEMPT_ACTIVE_BIT
>> > # define PREEMPT_ACTIVE_BIT 28
>> > # endif
>> > # define PREEMPT_ACTIVE (1 << PREEMPT_ACTIVE_BIT)
>> > #endif
>>
>> Makes sense i guess - but do we really need that level of
>> #ifdef nesting? PREEMPT_ACTIVE_BIT should be the main control - with
>> a default to 28 if it's not set. PREEMPT_ACTIVE is then derived off
>> that, without any #ifdefs.
>
> I think it would fit better into linux/hardirq.h instead of
> linux/thread_info.h, because that is where the other bits of
> the preempt count are defined.

agreed

> --- a/include/linux/hardirq.h
> +++ b/include/linux/hardirq.h
> @@ -62,6 +62,12 @@
> #define HARDIRQ_OFFSET (1UL << HARDIRQ_SHIFT)
> #define NMI_OFFSET (1UL << NMI_SHIFT)
>
> +#ifndef PREEMPT_ACTIVE
> +#define PREEMPT_ACTIVE_BITS 1
> +#define PREEMPT_ACTIVE_SHIFT (NMI_SHIFT + NMI_BITS)
> +#define PREEMPT_ACTIVE (__IRQ_MASK(PREEMPT_ACTIVE_BITS) << PREEMPT_SHIFT)

i think you meant "<< PREEMPT_ACTIVE_SHIFT" there. once i make that
change, it builds fine.
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

mingo at elte

Jun 24, 2009, 8:13 AM

Post #6 of 9 (302 views)
Permalink

Re: PREEMPT_ACTIVE too low error with all asm-generic headers for some arches [In reply to]

* Mike Frysinger <vapier.adi [at] gmail> wrote:

> On Wed, Jun 24, 2009 at 10:02, Arnd Bergmann wrote:
> > On Wednesday 24 June 2009, Ingo Molnar wrote:
> >> * Mike Frysinger <vapier.adi [at] gmail> wrote:
> >> > if we look at linux/hardirq.h, it makes this claim:
> >> > �* - bit 28 is the PREEMPT_ACTIVE flag
> >> > if that's true, then why are we letting any arch set this define ? �a
> >> > quick survey shows that half the arches (11) are using 0x10000000 (bit
> >> > 28) while the other half (10) are using 0x4000000 (bit 26). �and then
> >> > there is the ia64 oddity which uses bit 30. �the exact value here
> >> > shouldnt really matter across arches though should it ?
> >
> > actually alpha, arm and avr32 also use bit 30 (0x40000000), there are only
> > five (or eight, depending on how you count) architectures (blackfin, h8300,
> > m68k, s390 and sparc) using bit 26.
>
> meh, too many zeros ;)
>
> >> Correct - what matters is to have no collision between the fields.
> >>
> >> > how about adding this to linux/thread_info.h:
> >> > #ifndef PREEMPT_ACTIVE
> >> > # ifndef PREEMPT_ACTIVE_BIT
> >> > # �define PREEMPT_ACTIVE_BIT 28
> >> > # endif
> >> > # define PREEMPT_ACTIVE (1 << PREEMPT_ACTIVE_BIT)
> >> > #endif
> >>
> >> Makes sense i guess - but do we really need that level of
> >> #ifdef nesting? PREEMPT_ACTIVE_BIT should be the main control - with
> >> a default to 28 if it's not set. PREEMPT_ACTIVE is then derived off
> >> that, without any #ifdefs.
> >
> > I think it would fit better into linux/hardirq.h instead of
> > linux/thread_info.h, because that is where the other bits of
> > the preempt count are defined.
>
> agreed
>
> > --- a/include/linux/hardirq.h
> > +++ b/include/linux/hardirq.h
> > @@ -62,6 +62,12 @@
> > �#define HARDIRQ_OFFSET (1UL << HARDIRQ_SHIFT)
> > �#define NMI_OFFSET � � (1UL << NMI_SHIFT)
> >
> > +#ifndef PREEMPT_ACTIVE
> > +#define PREEMPT_ACTIVE_BITS � �1
> > +#define PREEMPT_ACTIVE_SHIFT � (NMI_SHIFT + NMI_BITS)
> > +#define PREEMPT_ACTIVE (__IRQ_MASK(PREEMPT_ACTIVE_BITS) << PREEMPT_SHIFT)
>
> i think you meant "<< PREEMPT_ACTIVE_SHIFT" there. once i make
> that change, it builds fine.

With that fix:

Acked-by: Ingo Molnar <mingo [at] elte>

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

vapier.adi at gmail

Jun 24, 2009, 3:21 PM

Post #7 of 9 (292 views)
Permalink

Re: PREEMPT_ACTIVE too low error with all asm-generic headers for some arches [In reply to]

On Wed, Jun 24, 2009 at 11:02, Mike Frysinger wrote:
> On Wed, Jun 24, 2009 at 10:02, Arnd Bergmann wrote:
>> --- a/include/linux/hardirq.h
>> +++ b/include/linux/hardirq.h
>> @@ -62,6 +62,12 @@
>> #define HARDIRQ_OFFSET (1UL << HARDIRQ_SHIFT)
>> #define NMI_OFFSET (1UL << NMI_SHIFT)
>>
>> +#ifndef PREEMPT_ACTIVE
>> +#define PREEMPT_ACTIVE_BITS 1
>> +#define PREEMPT_ACTIVE_SHIFT (NMI_SHIFT + NMI_BITS)
>> +#define PREEMPT_ACTIVE (__IRQ_MASK(PREEMPT_ACTIVE_BITS) << PREEMPT_SHIFT)
>
> i think you meant "<< PREEMPT_ACTIVE_SHIFT" there. once i make that
> change, it builds fine.

and like Ingo, with that fix, add my Acked-by

thanks !
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

vapier.adi at gmail

Jul 4, 2009, 3:43 PM

Post #8 of 9 (283 views)
Permalink

Re: PREEMPT_ACTIVE too low error with all asm-generic headers for some arches [In reply to]

On Wed, Jun 24, 2009 at 18:21, Mike Frysinger wrote:
> On Wed, Jun 24, 2009 at 11:02, Mike Frysinger wrote:
>> On Wed, Jun 24, 2009 at 10:02, Arnd Bergmann wrote:
>>> --- a/include/linux/hardirq.h
>>> +++ b/include/linux/hardirq.h
>>> @@ -62,6 +62,12 @@
>>> #define HARDIRQ_OFFSET (1UL << HARDIRQ_SHIFT)
>>> #define NMI_OFFSET (1UL << NMI_SHIFT)
>>>
>>> +#ifndef PREEMPT_ACTIVE
>>> +#define PREEMPT_ACTIVE_BITS 1
>>> +#define PREEMPT_ACTIVE_SHIFT (NMI_SHIFT + NMI_BITS)
>>> +#define PREEMPT_ACTIVE (__IRQ_MASK(PREEMPT_ACTIVE_BITS) << PREEMPT_SHIFT)
>>
>> i think you meant "<< PREEMPT_ACTIVE_SHIFT" there. once i make that
>> change, it builds fine.
>
> and like Ingo, with that fix, add my Acked-by
>
> thanks !

could you push this to Linus ? or should i throw something into the
Blackfin headers in the meantime ?
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

rgetz at blackfin

Jul 7, 2009, 5:41 AM

Post #9 of 9 (269 views)
Permalink

Re: PREEMPT_ACTIVE too low error with all asm-generic headers for some arches [In reply to]

On Sat 4 Jul 2009 18:43, Mike Frysinger pondered:
> On Wed, Jun 24, 2009 at 18:21, Mike Frysinger wrote:
> > On Wed, Jun 24, 2009 at 11:02, Mike Frysinger wrote:
> >> On Wed, Jun 24, 2009 at 10:02, Arnd Bergmann wrote:
> >>> --- a/include/linux/hardirq.h
> >>> +++ b/include/linux/hardirq.h
> >>> @@ -62,6 +62,12 @@
> >>> #define HARDIRQ_OFFSET (1UL << HARDIRQ_SHIFT)
> >>> #define NMI_OFFSET (1UL << NMI_SHIFT)
> >>>
> >>> +#ifndef PREEMPT_ACTIVE
> >>> +#define PREEMPT_ACTIVE_BITS 1
> >>> +#define PREEMPT_ACTIVE_SHIFT (NMI_SHIFT + NMI_BITS)
> >>> +#define PREEMPT_ACTIVE (__IRQ_MASK(PREEMPT_ACTIVE_BITS) << PREEMPT_SHIFT)
> >>
> >> i think you meant "<< PREEMPT_ACTIVE_SHIFT" there. once i make that
> >> change, it builds fine.
> >
> > and like Ingo, with that fix, add my Acked-by
> >
> > thanks !
>
> could you push this to Linus ? or should i throw something into the
> Blackfin headers in the meantime ?

Yeah, this is causing build failures on Linux 2.6.31-rc2 for Blackfin.

In file included from include/linux/interrupt.h:12,
from include/linux/kernel_stat.h:8,
from arch/blackfin/kernel/asm-offsets.c:32:
include/linux/hardirq.h:66:2: error: #error PREEMPT_ACTIVE is too low!
make[1]: *** [arch/blackfin/kernel/asm-offsets.s] Error 1
make: *** [prepare0] Error 2

Which the above patch makes go away...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads