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: <4BB23D64.70502@redhat.com>
Date:	Tue, 30 Mar 2010 14:05:24 -0400
From:	Rik van Riel <riel@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>
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 03/30/2010 01:56 PM, Peter Zijlstra wrote:
> 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.

Awww nuts.  I thought PREEMPT_ACTIVE used the same scheme of
adding shifts, but now I see it is hard coded on x86. Doh!

I'm guessing the best thing to do would be to remove the
PREEMPT_ACTIVE #define on x86 and use the one from hardirq.h?

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

No argument there.  I can't think of an alternative to mm_take_all_locks
though.  Andrea?
--
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/