linux-kernel - Re: [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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1269971802.5258.524.camel@laptop>
Date:	Tue, 30 Mar 2010 19:56:42 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Rik van Riel <riel@...hat.com>
Cc:	linux-kernel@...r.kernel.org, avi@...hat.com, aarcange@...hat.com,
	akpm@...ux-foundation.org,
	Kent Overstreet <kent.overstreet@...il.com>,
	Ingo Molnar <mingo@...e.hu>, tglx <tglx@...utronix.de>
Subject: Re: [PATCH] increase PREEMPT_BITS to 12 to avoid overflow when
 starting KVM

On Tue, 2010-03-30 at 13:36 -0400, Rik van Riel wrote:
> 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...

Does this even boot? It tramples all over PREEMPT_ACTIVE for x86.

Also, you'll need to convince mingo and tglx too.. taking that many
spinlocks is utter suckage..

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