linux-kernel - Re: [RFC/PATCH] i386: handle all exceptions with interrupts off initially

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: <20080910055337.GA9765@elte.hu>
Date:	Wed, 10 Sep 2008 07:53:37 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	heukelum@...tmail.fm, linux-kernel@...r.kernel.org, ak@...e.de
Subject: Re: [RFC/PATCH] i386: handle all exceptions with interrupts off
	initially


* H. Peter Anvin <hpa@...or.com> wrote:

> heukelum@...tmail.fm wrote:
>> From: Alexander van Heukelum <heukelum@...tmail.fm>
>>
>> x86_64 handles all exceptions with interrupts off initially, this
>> bisectable patch set does the same for i386, in (very) small steps.
>> If this is acceptable, it would make further unification of traps_32.c
>> and traps_64.c a lot easier. If it is not... why?
>>
>
> The only reason not to is that one generally doesn't want to disable 
> interrupts unless necessary (bad for latency.) On 64 bits there are 
> stack switches which make disabling interrupts mandatory.  The only 
> pitfall is if there is any code which is likely to take time, but I 
> highly doubt it.

the entry paths here are really short (we enable irqs almost 
immediately) so it's a non-issue in terms of worst-case latencies.

> In other words, it's not something we want to do "just because", but 
> to the extent that it provides real benefit, it makes sense.

this is historically pretty fragile code so bringing the 32-bit and 
64-bit variants more in line sounds like a good reason to me. For 
example we had various long-living irq state annotation bugs (the 
combination of kprobes and lockdep, etc.) that remained unfixed partly 
due to this assymetry.

There will be details i'm sure, but the series looks quite bisectable.

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