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

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>] [thread-next>] [day] [month] [year] [list]

Message-ID: <8bd0f97a0906231508s4c115d3dr2848626bc5a28c5e@mail.gmail.com>
Date:	Tue, 23 Jun 2009 18:08:29 -0400
From:	Mike Frysinger <vapier.adi@...il.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/