linux-kernel - Re: [RFC 00/13] smp: reduce stack requirements for genapic send_IPI

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: <20080907073620.GC14907@elte.hu>
Date:	Sun, 7 Sep 2008 09:36:20 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Mike Travis <travis@....com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, davej@...emonkey.org.uk,
	David Miller <davem@...emloft.net>,
	Eric Dumazet <dada1@...mosbay.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Jack Steiner <steiner@....com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Jes Sorensen <jes@....com>, "H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC 00/13] smp: reduce stack requirements for genapic
	send_IPI_mask functions

* Mike Travis <travis@....com> wrote:

> [Note: all these changes require some more testing but I wanted to 
> solicit comments before then, hence the "RFC" in the subject line. 
> -thanks! Mike]

these changes are certainly looking very nice.

They do interact with a ton of high-flux topics in -tip, so i'd prefer 
to start integrating/testing this straight away (today-ish), before the 
target moves yet again. Are there any showstoppers that speak against 
that?

The plan would be to not keep this in a single topic but to spread them 
into their closest topic (tip/x86/x2apic, tip/irq/sparseirq etc.) - are 
there any cross-topic dependencies to be careful about? Most of the 
commits seem to be standalone. The debug patch would go into 
tip/cpus4096.

And more generally: how far away are we from being able to introduce 
struct cpumask and hide its implementation from most .c files? That 
would be rather efficient in preventing it from being put on the stack 
spuriously in one of the 30+ thousand Linux kernel source code files. 
Just like we hide the true structure of things like 'struct kmem_cache' 
and force them to always be used as pointers.

	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/