linux-kernel - [RFC 0/4] dynamically allocate arch specific system vectors

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: <20080911152304.GA13655@sgi.com>
Date:	Thu, 11 Sep 2008 10:23:04 -0500
From:	Dean Nelson <dcn@....com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Alan Mayer <ajm@....com>, Ingo Molnar <mingo@...e.hu>,
	jeremy@...p.org, rusty@...tcorp.com.au, suresh.b.siddha@...el.com,
	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Yinghai Lu <Yinghai.lu@....com>
Subject: [RFC 0/4] dynamically allocate arch specific system vectors

On Mon, Aug 11, 2008 at 12:39:22PM -0700, Eric W. Biederman wrote:
>
> Although I am not at all convinced that dynamic allocation of
> the vector number (instead of statically reserving it makes sense).

We (SGI) need somewhere around eight vectors.

There are two kernel modules, sgi-gru and sgi-xp (in drivers/misc), that
each need two vectors. And there's the broadcast assist unit (BAU) that is
involved in tlb shootdown on uv, which currently uses statically reserved
vector 0xf8 (UV_BAU_MESSAGE -- see uv_bau_init()). I know of a debugger that
also uses 0xf8 because it was previously available until UV_BAU_MESSAGE came
along. The BAU would be happy with a dynamically allocated system vector.
We have a couple of other things in the works that also need vectors.

All of these eight or so vectors are only meaningful on SGI uv systems.

We'll go with which ever way you decide on this (dynamically allocated or
statically reserved).

But we really need to get something into 2.6.28. So in order to move forward
I'm submitting the following patchset for comment. This set of four patches
represents my take on Eric's suggested approach to supporting dynamically
allocated system vectors (i.e., __grab_irq_vector()).

Eric, is this what you were thinking of? Or did I miss the mark?

Thanks,
Dean
--
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/