linux-kernel - [PATCH] increase PREEMPT_BITS to 12 to avoid overflow when starting KVM

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: <20100330133634.2f1bf3d6@cuia.bos.redhat.com>
Date:	Tue, 30 Mar 2010 13:36:34 -0400
From:	Rik van Riel <riel@...hat.com>
To:	linux-kernel@...r.kernel.org
Cc:	peterz@...radead.org, avi@...hat.com, aarcange@...hat.com,
	akpm@...ux-foundation.org,
	Kent Overstreet <kent.overstreet@...il.com>
Subject: [PATCH] increase PREEMPT_BITS to 12 to avoid overflow when starting
 KVM

Increase the PREEMPT_BITS to 12, to deal with a larger number
of locks that can be taken in mm_take_all_locks or other places
where many instances of the same type of lock can be taken.

The overflow of PREEMPT_BITS should be harmless, since it simply
increments the counter into the SOFTIRQ_BITS, and the counter
will be decremented again later.

However, the overflow does lead to backtraces with CONFIG_PREEMPT_DEBUG
enabled.

Signed-off-by: Rik van Riel <riel@...hat.com>
Reported-by: Kent Overstreet <kent.overstreet@...il.com>

---
Kent, does this patch fix the issue you saw?

Peter, I know you do not like this approach. However, I could not
think of a way around mm_take_all_locks. We need to take those locks
and want to track that fact for lock debugging...

diff --git a/include/linux/hardirq.h b/include/linux/hardirq.h
index d5b3876..e74108f 100644
--- a/include/linux/hardirq.h
+++ b/include/linux/hardirq.h
@@ -14,8 +14,8 @@
  * We put the hardirq and softirq counter into the preemption
  * counter. The bitmask has the following meaning:
  *
- * - bits 0-7 are the preemption count (max preemption depth: 256)
- * - bits 8-15 are the softirq count (max # of softirqs: 256)
+ * - bits 0-12 are the preemption count (max preemption depth: 4096)
+ * - bits 13-19 are the softirq count (max # of softirqs: 256)
  *
  * The hardirq count can in theory reach the same as NR_IRQS.
  * In reality, the number of nested IRQS is limited to the stack
@@ -24,16 +24,16 @@
  * hardirq nesting. An arch may choose to give less than 10 bits.
  * m68k expects it to be 8.
  *
- * - bits 16-25 are the hardirq count (max # of nested hardirqs: 1024)
- * - bit 26 is the NMI_MASK
- * - bit 28 is the PREEMPT_ACTIVE flag
+ * - bits 26-29 are the hardirq count (max # of nested hardirqs: 1024)
+ * - bit 30 is the NMI_MASK
+ * - bit 31 is the PREEMPT_ACTIVE flag
  *
- * PREEMPT_MASK: 0x000000ff
- * SOFTIRQ_MASK: 0x0000ff00
- * HARDIRQ_MASK: 0x03ff0000
- *     NMI_MASK: 0x04000000
+ * PREEMPT_MASK: 0x00000fff
+ * SOFTIRQ_MASK: 0x000ff000
+ * HARDIRQ_MASK: 0x3ff00000
+ *     NMI_MASK: 0x40000000
  */
-#define PREEMPT_BITS	8
+#define PREEMPT_BITS	12
 #define SOFTIRQ_BITS	8
 #define NMI_BITS	1
 

--
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/